[14:00:10 CDT(-0500)] <Bosmon> JURA has a problem where he wants an IoC-driven component to have a multiplicity governed by how many times its container appears in the DOM

[14:00:51 CDT(-0500)] <Bosmon> Although this is a planned feature for IoC, it is not arriving soon since it depends on a change in the representation of the component tree - the IOC traverser is not prepared to recognise the existence of a vector of components where it expected only a single one

[14:01:06 CDT(-0500)] <Bosmon> So yura's idea was to use a renderer decorator instead

[14:01:28 CDT(-0500)] <Bosmon> This gets around the multiplicity limitation, since the renderer automatically assigns new component names (member names) for every component that it constructs

[14:02:02 CDT(-0500)] <Bosmon> Although of course you don't easily get to see what these names are, in practice there are enough ways of interacting with these components

[14:02:19 CDT(-0500)] <Bosmon> However, an additional problem seems to be that the timing of creating these components needs to be controlled

[14:02:45 CDT(-0500)] <Bosmon> Right now we are debating over the issue of whether simply triggering a rendering operation on the parent with an event is enough to get what yura needs

[14:58:43 CDT(-0500)] <yura> so my thought was to pass the event to a decorator through demands, and then call refreshView of the decorator on that event, Bosmon

[14:59:53 CDT(-0500)] <Bosmon> I see - so the situation is that the container exists already at the time the decorator is constructed, but you don't actually want it to render/be constructed then?

[14:59:59 CDT(-0500)] <Bosmon> Can you describe the situation in more detail, yura?

[15:00:13 CDT(-0500)] <yura> Bosmon: sure

[15:00:21 CDT(-0500)] <yura> so my renderer component has an event

[15:00:46 CDT(-0500)] <yura> it renders itself on init

[15:00:51 CDT(-0500)] <yura> but event fires asynchrnously

[15:01:06 CDT(-0500)] <Bosmon> What does the event mean?

[15:01:12 CDT(-0500)] <Bosmon> Which part of the GUI actually is this?

[15:01:29 CDT(-0500)] <yura> the event fires when data is fetched and template is fetched

[15:03:43 CDT(-0500)] <Bosmon> I see

[15:03:51 CDT(-0500)] <Bosmon> But you have multiple instances of this component? What is the component

[15:04:12 CDT(-0500)] <yura> is it's the control panel with buttons (save, delete, etc)

[15:04:22 CDT(-0500)] <yura> we have 2 of them top and bottom

[15:05:29 CDT(-0500)] <Bosmon> Ah, interesting

[15:05:54 CDT(-0500)] <Bosmon> So yes, I think your event + refresh system sounds good

[15:06:04 CDT(-0500)] <yura> so

[15:06:07 CDT(-0500)] <yura> where i am right now

[15:06:12 CDT(-0500)] <yura> is i pass an event to decorator

[15:06:16 CDT(-0500)] <yura> and only render on event

[15:06:21 CDT(-0500)] <yura> but it fails

[15:06:29 CDT(-0500)] <yura> with

[15:06:29 CDT(-0500)] <yura> Error during rendering - component with id createFromExistingButton which has a queued decorator was not found in the output markup

[15:06:54 CDT(-0500)] <yura> funny thing though is that the options.resources.template is populated

[15:11:16 CDT(-0500)] <yura> Bosmon: ^

[15:14:37 CDT(-0500)] <Bosmon> Perhaps you had better supply a pastie, yura

[15:15:04 CDT(-0500)] <yura> pastie of twhat ?

[15:15:08 CDT(-0500)] <Bosmon> This error occurs when something has asynchronously taken away the markup which the component rendered during phase one

[15:15:10 CDT(-0500)] <Bosmon> Of your code!

[15:15:15 CDT(-0500)] <yura> ok

[15:15:35 CDT(-0500)] <yura> hmm interesting

[15:15:40 CDT(-0500)] <yura> i guess it means my approach is domed

[15:15:42 CDT(-0500)] <yura> doomed

[15:17:49 CDT(-0500)] <Bosmon> What have you discovered, yura?

[15:17:57 CDT(-0500)] <Bosmon> DOMED approaches are also good

[15:18:25 CDT(-0500)] <Bosmon> Like for example, the one to El Capitan in Yosemite National Park....

[15:24:10 CDT(-0500)] <yura> well if my decorator renders asynchronously from the parent component , doesnt it mean ti will always be out of date with markup ?

[15:24:47 CDT(-0500)] <yura> Bosmon: ^

[15:25:46 CDT(-0500)] <Bosmon> yura - well having a decorator which was itself a renderer component would always be problematic

[15:26:00 CDT(-0500)] <Bosmon> You should send along your code since I'm not sure I still understand the situation well

[15:26:06 CDT(-0500)] <yura> ok

[15:29:42 CDT(-0500)] <yura> well ok, Bos

[15:29:54 CDT(-0500)] <yura> when i m trying to find a node by id

[15:30:00 CDT(-0500)] <yura> it is looking at id, renderOptions.document

[15:30:10 CDT(-0500)] <yura> sorry inside id, renderOptions.document

[15:30:19 CDT(-0500)] <yura> sorry inside renderOptions.document

[15:30:39 CDT(-0500)] <yura> i m i expecting that the template for the decorator is inserted by that time ?

[15:30:44 CDT(-0500)] <yura> Bosmon: ^

[15:33:00 CDT(-0500)] <Bosmon> yura - I have no idea - show me the code

[15:33:34 CDT(-0500)] <yura> this is my proto tree http://pastie.org/3650134

[15:34:04 CDT(-0500)] <yura> this is the decorator with demands : http://pastie.org/3650140

[15:34:50 CDT(-0500)] <yura> ready is the async event, Bosmon

[15:35:52 CDT(-0500)] <Bosmon> Thanks

[15:36:00 CDT(-0500)] <Bosmon> Let me remind myself how resourceSpecExpanders work....

[15:37:03 CDT(-0500)] <Bosmon> Oh, I see

[15:37:07 CDT(-0500)] <Bosmon> Same issue as in the other channel

[15:37:16 CDT(-0500)] <Bosmon> So you're sure that the template has somehow been "primed" already?

[15:37:38 CDT(-0500)] <yura> yes if i break in pre init for example resourceText is populated

[15:38:04 CDT(-0500)] <Bosmon> ok, cool

[15:38:33 CDT(-0500)] <yura> you can assume that all fastTemplates are primed

[15:38:47 CDT(-0500)] <yura> since that fetchResources call happens waaay in advance in globalSetup

[15:38:49 CDT(-0500)] <yura> Bosmon:

[15:42:08 CDT(-0500)] <Bosmon> Ok

[15:42:11 CDT(-0500)] <Bosmon> Reading through the code

[15:42:22 CDT(-0500)] <Bosmon> Yes, this situation is always going to be problematic, because of the nested renderer components

[15:42:29 CDT(-0500)] <Bosmon> I understand now that it is the whole panel which is the decorator

[15:42:37 CDT(-0500)] <yura> yes

[15:42:42 CDT(-0500)] <Bosmon> But itself also expects to do rendering

[15:43:14 CDT(-0500)] <Bosmon> You are inherently DOMED in this case since you will always end up binding to a container which is destroyed by the first rendering operation

[15:43:26 CDT(-0500)] <Bosmon> Until we have ANTIGENS you will always need to do this kind of thing manually

[15:44:02 CDT(-0500)] <yura> alright

[15:44:06 CDT(-0500)] <yura> it's not the first time

[15:44:06 CDT(-0500)] <yura>

[15:44:17 CDT(-0500)] <yura> just wanted to make sure there's no woodoo i can apply

[15:45:49 CDT(-0500)] <Bosmon> Sadly not ... I guess I need to actually make that JIRA for antigens, as it says in FLUID-3681

Browser not supported