Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Issue in SimpleChat (and maybe other pods) switching rooms on the fly

Avatar

Level 3
I originally raised the issue (and a fix) in
http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=759&threadid=1413563.
I think it was intended to be fixed in the most recent build, but
looks like it was not. It seems that the key missing piece is to
assign _model = null in the pod's close() method.

7 Replies

Avatar

Former Community Member
Hi Rick,



You dont need to call close() . You need to use logout, then
assign the new url , then login and then call subscribe on
synchronization to get the new data.

Here is the attached code for simpleChat



Thanks

Hironmay Basu

Avatar

Level 3
Hi, Hironmay.



No, that approach doesn't work, unfortunately. While it does
reconnect to the new room URL, the history pane in the chat pod is
cleared but never updated with the history from the new room. As
you may recall from the last discussion, I created a workaround
that involved subclassing SimpleChat, and adding an "unsubscribe"
method, using the attached code.



Rick

Avatar

Former Community Member
Hi Rick,



The example I sent does update the history pane for users
while dynamically switching rooms.

I remember our past conversation , after that we made it so
that you shouldn't call close rather logout and login when going to
a new room. Have you tried the example i sent on chat ?

I am not sure why yo are not able to see the new room history
but i will still run it again.



Thanks

Hironmay Basu

Avatar

Level 3
Hi, Hironmay. I pretty much copied your code exactly. The
only difference is that I am also changing the sharedID as I switch
from room to room.

Avatar

Former Community Member

Hi Rick,

We currently do not support dynamic changing of the sharedID of the collections.What's your use case? Does your  case work with the same sharedID you created already?

Thanks

Hironmay Basu

Avatar

Level 2

Hi, Hironmay.

It's probably not necessary to switch SharedID's but it wasn't entirely clear when/why/what SharedID's did, so I erred on the side of safety...can you explain the usage/purpose of SharedID's?

To support switching SharedID's (if it is something you want to do), you can set the model to "null" as provided in the unsubscribe method implementation in original post.

Thanks,

Rick

Avatar

Former Community Member

Hi Rick,

The sharedID's are the names of collectionNodes used for identifying them on the server for that room. So, collectionNodes should all have unique sharedIDs in a room, if the user doesn't assign, it gets assigned to some default value.

When we do a dynamic switching, we don't want to destroy the entire model and recreate everything and rather resync the messages for the new room. This saves work and other technical complications.

Thanks

Hironmay Basu