How do I create a shared container?

[Former Community Member]

I'd like to be able to create a shared container that has shared children. The children should use the same node as the shared container.

I expected to do something like this:

<?xml version="1.0" encoding="utf-8"?>
<Widget xmlns="com.xxx.widget.*" xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:rtc="AfcsNameSpace" xmlns:controls="com.xxx.controls.*" >

    <rtc:WebCamera sharedID="{sharedID}" width="100%" height ="100%"/>
  
</Widget>

I should mention that Widget implements ISessionSubscriber.

What are the best practices in this case?

-sandy

[Former Community Member]

To clarify, they should use the same collection, each with their own set of nodes within the collection.

[Former Community Member]

Hi Sandy,

I'm not sure I'm grasping what you're trying to do - when you say "shared

container", what aspects are you expecting to share?

thanks

nigel

[Former Community Member]

I have a panel that will have shared items in it (We'll call it a SharedPanel). The panel will need to share it's location, visibility, size, etc...

Inside that panel, for instance, I want to put a WebCamera. I'd like the WebCamera to use the NodeCollection that the SharedPanel is using. This way everything will be organized by the collection name of the Panel.

I'm curious about the best practices around this sort of thing.

-sandy

[Former Community Member]

Hi,

For the sharedPanel itself , you can have a collection Node that shares all info like location, visibility etc. For LCCS objects inside the shared panel, you can't directly use the panel's collection node rather you can give it a particular id, it will create the component's model with that shared ID and your ids can preserve the uniqueness.

Thanks

Hironmay Basu

[Former Community Member]

It looks like I was mistaken about the source of my issue. The nodes all get created as I expect, but I'm not getting notification when I change them.

The documentation is a little vague about this. If I change the values in a node, should I expect to get a CollectionNodeEvent.ITEM_RECEIVE event?

Or is that only when the node gets created in the first place?

(Thanks so much for your quick replies.)

[Former Community Member]

Hi,

Can you send a small test code that demonstrates what you are doing and what you are not getting ? That way it will help us in debugging your issue.

Thanks

Hironmay Basu

[Former Community Member]

hey,

It'll take me some time to whittle it down to a piece of code that's easy to share.

But, I have a theory. Currently I have a panel (called Widget) with a WebCamera in it.

When I disable the WebCamera, everything works fine, when I add it to the same node, things stop working.

When the WidgetModel creates the node in the collection, it uses CollectionNode.createNode(). The NodeConfiguration sets the permissions.

When the CameraModel creates the CollectionNode it doesn't use "createNode" it just published to the node. Is it possible that it overwrites my permissions and makes me unable to receive the events?

-sandy

[Former Community Member]

hey,

I've attached my WidgetModel. I'd love if you had the time for you to take a look at it, if not, I completely understand.

Is that enough? Or do you need more context?

-sandy

[Former Community Member]

I will take a look and get back to you soon.

Thanks

Hironmay Basu

[Former Community Member]

Hi Sandy,

The WidgetModel as a component looks good to me . I am still not clear about how CameraModel comes in here. You need to send me the mxml files also where you use this model along with the Camera. I don't see any problem with your standalone model. Also, CameraModel has its own nodes for publishing. Why it will interfere is not clear to me. Whenever you publish on a node, you will get the itemReceive event unless of course you don't have permission to access the node items.

As I said, I need your full list of files to debug the issue.

Thanks

Hironmay Basu

[Former Community Member]

hey Hironmay,

I was hoping that I just had some glaring error and we could minimize the amount of code you'd have to pour through. I'll attach the full project for ya.

The general idea is that it will be something like Adobe Connect, so we'll have widgets that can be dragged around the screen. We'll have a whiteboard widget and a webcam widget. I'm waiting on my custom widgets until I get the rest squared away.

The place where the webcam and the widgetmodel coexist is when a webcam widget is created, they should use the same nodecollection for their data. This is mostly for bookkeeping reasons. When it comes time to cleanup after the widgets it'll be easier if it's all in one place. Is that not the best way to do this sort of thing?

thanks again for all your help, I truly appreciate it

-sandy

whoops, almost forgot to point you to the code that creates the WebCamera, it's in com.telecare.widget.WebcamWidget.mxml

[Former Community Member]

Hi Sandy,

Unfortunately, I don't think you'll be able to structure everything on one

CollectionNode. In theory, we could have built things this way, but we chose

not to. Here are some reasons :

1) CollectionNodes really only have 3 levels of hierarchy (collection, node,

items). Some of the models we've built (say, the chat or whiteboard models)

use multiple nodes. Putting multiple models all on one collectionNode would

mean that you'd have one collection with a ton of nodes, not necessarily

really related.

2) The "unit" of subscription tends to be at the collection level. So if a

"pod" comes or goes, you want the ability to subscribe/unsubscribe to it on

the fly. Putting everything on one collection would likely mean subscribing

to everything at once, whether or not it's on screen.

Now, in theory you could rebuild our models (you have the source) to make

everything share the same collectionNode, but it's not the way things are

built out-of-the-box. I'm not entirely sure if the benefits are as obvious

to me (and I wrote Adobe Connect's pod management =) as you're stating - how

does this help you share the position of the pods? Or make book-keeping

easier? If there aren't multiple sets of pods, then the problem seems about

the same whether there are tons of nodes on one collectionNode, or a few

collectionNodes (each with a few nodes). I'd actually argue the latter is

easier.

let's discuss further - I'm still not sure I understand all that you're

trying to do.

nigel

[Former Community Member]

hey Nigel,

In reason #1, you imply that I'm better off having many small collections rather than one large collections. Is this correct? (Or perhaps, I've misspoken and confused collections and nodes)

The basic unit for subscription is the collection? My reading of the api implied that you subscribe to a node, not to a collection. Interesting.

Reason #2 is exactly why I wanted to have the widget and it's contents share a collection. When a widget comes into existence, it would subscribe to the nodes it needs, but all under the one collection. More importantly, when it came time to destroy that wiget, I could clean up evrything in that one collection. It's really just a trade-off of complexity, I can either store everything for a wiget in one collection and let LCCS manage the complexity, or I can have my WidgetManager manage the complexity. I was just hoping that I could have LCCS manage it because I wouldn't have to write as much code that way.

I think our disconnect comes from the multiple widgets issue. My intent is to create some custom widgets later on. One example is a flashcard, there could be n flashcards on the screen at one time, hence the need for the extra bookkeeping.

Whether the trade-off is worth it or not, I'd like to understand what's going on and I'm not clear on what the issue that I'm seeing is. Why does subscribing to the WebCamera pod, cause the Widget node ( my node ) to stop reporting updates?

Hopefully that clarifies things a little bit.

-sandy