fluid-tech IRC Logs-2012-09-06
[15:15:00 CDT(-0500)] <anastasiac> Bosmon, are you there?
[15:28:06 CDT(-0500)] <Bosmon> anastasiac - hi there
[15:28:24 CDT(-0500)] <anastasiac> hey, Bosmon, I have a question about the deferredCall expander
[15:28:35 CDT(-0500)] <Bosmon> Ah, that!
[15:28:40 CDT(-0500)] <Bosmon> I was just surveying it this weekend
[15:28:53 CDT(-0500)] <Bosmon> Wondering whether it should be abolished
[15:29:08 CDT(-0500)] <anastasiac> if the function requires the use of one of the components in the tree (within scope), do I have to make sure that the component has already been instantiated?
[15:29:21 CDT(-0500)] <anastasiac> I'm having a problem with it
[15:29:33 CDT(-0500)] <Bosmon> Yes
[15:29:44 CDT(-0500)] <Bosmon> It would be best not to use it
[15:29:50 CDT(-0500)] <anastasiac> at all?
[15:29:51 CDT(-0500)] <Bosmon> But yes, you will have that issue
[15:30:00 CDT(-0500)] <Bosmon> It is called "extremely early" during instantiation
[15:30:08 CDT(-0500)] <anastasiac> do you have a suggestion for an alternative?
[15:30:13 CDT(-0500)] <Bosmon> And it is most likely that any components it tries to make use of will not exist
[15:30:25 CDT(-0500)] <Bosmon> It depends on what effect you are trying to achieve
[15:30:39 CDT(-0500)] <anastasiac> right. It creates the component, no problem, but then the component gets created again at the time it would have been
[15:31:21 CDT(-0500)] <anastasiac> so I'm trying to set the 'aria-controls' attribute on the videoPlayer language menus
[15:31:34 CDT(-0500)] <anastasiac> this attribute needs to reference the id of the transcript area
[15:31:50 CDT(-0500)] <anastasiac> the language menus and the transcript area are governed by independent components
[15:32:16 CDT(-0500)] <anastasiac> so I need to find a way to get the id from the one component's DOM chunk into the other component
[15:32:30 CDT(-0500)] <anastasiac> without creating inappropriate dependencies between the two
[15:33:17 CDT(-0500)] <Bosmon> You can actually transfer DOM nodes via direct reference via the DOM binder in IoC
[15:33:34 CDT(-0500)] <anastasiac> !!?
[15:33:36 CDT(-0500)] <Bosmon> Depending on whether one component has visibility of the other via IoC resolution, this may already be enough to do what you need
[15:34:07 CDT(-0500)] <anastasiac> the transcript component is definitely in scope of the menu component
[15:34:09 CDT(-0500)] <Bosmon> Simply write an IoC reference to .dom.selectorName
[15:34:16 CDT(-0500)] <anastasiac> !
[15:34:19 CDT(-0500)] <Bosmon> And the relevant DOM node will get injected
[15:34:43 CDT(-0500)] <anastasiac> that could be mighty helpful here
[15:34:51 CDT(-0500)] <anastasiac> thanks!
[15:34:55 CDT(-0500)] <Bosmon> Good luck
[15:35:00 CDT(-0500)] <anastasiac> I'll let you know if it doesn't work
[15:35:24 CDT(-0500)] <Bosmon> Yes, I am assessing the "expander" system rather critically now I am in the middle of the "ginger world" work
[15:35:30 CDT(-0500)] <Bosmon> Currently they are the next thing to get working
[15:35:35 CDT(-0500)] <Bosmon> But I think, only for backwards compatibility
[15:35:37 CDT(-0500)] <anastasiac> good to konw
[15:35:53 CDT(-0500)] <Bosmon> All of these things are very crusty and ancient, and will most likely be replaced by their equivalents in the "model transformation" system
[15:36:13 CDT(-0500)] <Bosmon> After all we can't have TWO wildly different classes of things called "expanders" that do broadly similar jobs
[15:36:28 CDT(-0500)] <Bosmon> Counting "renderer expanders" we would have THREE
[15:36:38 CDT(-0500)] <Bosmon> Even more controversially, I think it will be possible to abolish those too
[15:37:06 CDT(-0500)] <Bosmon> Although it would require a very different way of looking at the rendering process than we currently have
[15:37:31 CDT(-0500)] <Bosmon> yura1 stands to suffer the most from this, as so far by far the world's most prolific user of renderer expanders
[15:38:17 CDT(-0500)] <Bosmon> But all the same, colinclark quite correctly assured us last year that "the renderer expander system needs to be burned to the ground" : P
[15:46:44 CDT(-0500)] <yura1> Bosmon: hi
[15:47:13 CDT(-0500)] <yura1> Bosmon: i need some help with 2 pull requests of mine
[15:47:34 CDT(-0500)] <Bosmon> Hi yura1
[15:48:07 CDT(-0500)] <yura1> Hi
[15:48:52 CDT(-0500)] <Bosmon> 4791 looks good
[15:49:17 CDT(-0500)] <Bosmon> Although we probably don't need a test as elaborate as that one : P
[15:50:00 CDT(-0500)] <yura1> hah
[15:50:10 CDT(-0500)] <Bosmon> I do wonder why you might be removing a listener which doesn't exist, but the fix is certainly fine
[15:50:58 CDT(-0500)] <yura1> Bosmon: right
[15:51:09 CDT(-0500)] <yura1> it is not common
[15:51:48 CDT(-0500)] <Bosmon> FLUID-4790 will require more intensive assessment
[15:51:55 CDT(-0500)] <yura1> yes
[15:52:03 CDT(-0500)] <yura1> but i hope the tests will satisfy
[15:52:12 CDT(-0500)] <Bosmon> Yes
[15:52:20 CDT(-0500)] <Bosmon> They are extremely extensive
[15:53:05 CDT(-0500)] <Bosmon> Is it possible they could all share the same setup code?
[15:53:11 CDT(-0500)] <colinclark> I'm just catching up on the logs here
[15:53:17 CDT(-0500)] <colinclark> what a nice discussion
[15:53:18 CDT(-0500)] <Bosmon> They appear to begin with almost identical configuration
[15:53:21 CDT(-0500)] <colinclark> "Although it would require a very different way of looking at the rendering process than we currently have"
[15:53:24 CDT(-0500)] <colinclark> And
[15:53:37 CDT(-0500)] <colinclark> "extremely extensive" tests
[15:53:42 CDT(-0500)] <yura1> Bosmon: yes possible
[15:53:43 CDT(-0500)] <colinclark> yay
[16:01:50 CDT(-0500)] <anastasiac> Bsomon, fyi: worked like a charm, thanks
[16:18:10 CDT(-0500)] <anastasiac> Bosmon, I take it back: I'm having the same problem I had with deferred call: my component is being instantiated twice
[16:18:53 CDT(-0500)] <anastasiac> it does work, but it has this problem
[16:33:04 CDT(-0500)] <Bosmon> Hi anastasiac - it could only be instantiated twice if you created some kind of pathway for that....
[16:33:10 CDT(-0500)] <Bosmon> Did you label your component as "createOnEvent"?