fluid-tech IRC Logs-2012-03-22
[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