fluid-work IRC Logs-2013-02-21

Owned by Fluid IRC Log Bot
Last updated: Feb 21, 2013Version comment
9 min read

[10:27:00 CST(-0600)] <alexn> Justin_o: I created the JIRA we were talking about http://issues.fluidproject.org/browse/VP-265

[10:28:28 CST(-0600)] <Justin_o> alexn: thanks

[13:18:36 CST(-0600)] <Justin_o> Bosmon: do you know of a reason why the callback function for a call to fetchResources may not be executed?

[13:18:59 CST(-0600)] <Justin_o> I'm not getting any errors, and looking at the net tab in firebug shows the template was returned

[13:19:13 CST(-0600)] <Bosmon> Justin_o - a bug? : P

[13:19:19 CST(-0600)] <Justin_o> Bosmon: (smile)

[13:19:20 CST(-0600)] <Bosmon> Or perhaps you have another template entry you are waiting for somehow

[13:19:37 CST(-0600)] <Justin_o> Bosmon: what does that mean?

[13:20:36 CST(-0600)] <Bosmon> Perhaps you have another entry in your resources structure

[13:21:34 CST(-0600)] <Justin_o> Bosmon: the really weird part of this is that it is only an issue if I put in a breakpoint. The breakpoint is in a different component, in another file, and that component doesn't fetch templates

[13:23:27 CST(-0600)] <Bosmon> Justin_o - oh, that's perfectly expectable

[13:23:30 CST(-0600)] <Bosmon> This is in Firebug, right?

[13:23:35 CST(-0600)] <Justin_o> Bosmon: yes

[13:23:54 CST(-0600)] <Bosmon> You can expect Firebug to regularly screw up the progress of asynchronous activities if you put in breakpoints

[13:24:04 CST(-0600)] <Bosmon> You've got no alternative but to debug it the other way : P

[13:24:57 CST(-0600)] <Justin_o> (sad)

[13:25:14 CST(-0600)] <Justin_o> oh well.. it's a good thing i've talked to you.. i spent so much time trying to figure out what is going on with this.

[13:25:27 CST(-0600)] <Bosmon> Also you can just move to Chrome

[13:25:34 CST(-0600)] <Bosmon> The interface is less good, but there are fewer anomalies generally

[13:25:38 CST(-0600)] <Justin_o> maybe i should debug in safari (smile)

[13:26:50 CST(-0600)] <Bosmon> The pattern is to always START debugging something in Firebug, until you hit some strange anomaly, and then move to Chrome for less smooth but more robust experience if you get into problems

[13:27:13 CST(-0600)] <Bosmon> For example stack overflows are a complete bastard on Firebug because they will bomb the entire browser if you have it open

[13:27:34 CST(-0600)] <Justin_o> Bosmon: would the recent changes to the framework allow me to bind listeners/events between components. currently component A has an event i need to listen to in component B, but the event is automatically triggered within component A and could fire before component B is instantiated.

[13:27:56 CST(-0600)] <Justin_o> Bosmon: thanks for the tip.. i'll use that workflow

[13:28:58 CST(-0600)] <Bosmon> Justin_o - hopefully this is one of those events that can fire only once

[13:30:39 CST(-0600)] <Justin_o> Bosmon: I would expect it to only fire once, although I've seen cases where it appears to have fired more often (could be a debugging anomaly again, can't remember which browser i saw that in)

[13:30:51 CST(-0600)] <Bosmon> Yes, it will be an anomaly

[13:31:08 CST(-0600)] <Bosmon> In that case, it will be handled by http://issues.fluidproject.org/browse/FLUID-4883 when it is implemented

[13:32:46 CST(-0600)] <Justin_o> Bosmon: that's cool.. so at the moment is there a preferred work around?

[13:33:54 CST(-0600)] <Bosmon> Justin_o - what's the situation?

[13:34:57 CST(-0600)] <Justin_o> the media component will fire a canPlay event.. the controllers need to use this event to make some changes to it's interface. e.g. enable the scrubber..

[13:35:04 CST(-0600)] <Justin_o> Bosmon: ^

[13:35:36 CST(-0600)] <Bosmon> And why can't you instantiate them before this event?

[13:36:07 CST(-0600)] <Justin_o> Bosmon: wouldn't it need the media component to exist before it can register a listener to one of it's events

[13:36:40 CST(-0600)] <Justin_o> Bosmon: the event is basically a dom event that fires automatically when the video source is able to be played

[13:36:44 CST(-0600)] <Justin_o> browser event

[13:36:58 CST(-0600)] <Bosmon> ok

[13:37:10 CST(-0600)] <Bosmon> I guess our traditional workaround is to make a dedicated "event binding component"

[13:37:22 CST(-0600)] <Bosmon> Which waits until the first moment that both of the things that need to be connected exist

[13:37:31 CST(-0600)] <Bosmon> And then injects a listener from one to the other

[13:40:41 CST(-0600)] <Bosmon> If you could afford to upgrade to current trunk, you could also handle this situation without an extra component by using Luke Skywalker....

[13:46:54 CST(-0600)] <Bosmon> Justin_o^

[13:47:10 CST(-0600)] <Bosmon> Although upgrading the VideoPlayer to the latest framework I expect wouldn't be completely smooth sailing

[13:47:15 CST(-0600)] <Bosmon> It's something that will have to happen quite soon

[13:47:56 CST(-0600)] <jessm> Bosmon: ping

[13:48:20 CST(-0600)] <Bosmon> CATT!

[13:48:36 CST(-0600)] <jessm> Bosmon: ! i am staring at a pad of pirates. might you join me?

[13:48:58 CST(-0600)] <Bosmon> Sure... do you need defending from these PILATES? : P

[13:49:06 CST(-0600)] <Bosmon> I can join you partially since I'm listening to this GPII call with one ear

[13:49:14 CST(-0600)] <Bosmon> And occasionally interfering with it

[13:49:35 CST(-0600)] <jessm> Bosmon: i have felt like a pirate all my life – no defending – http://piratepad.net/3W5dxbXX05

[13:50:04 CST(-0600)] <Bosmon> Good grief

[13:50:09 CST(-0600)] <Bosmon> A WORK PLAN

[13:50:29 CST(-0600)] <Bosmon> Seems that we are somewhat late with it

[13:50:39 CST(-0600)] <jessm> indeed

[13:51:00 CST(-0600)] <jessm> Bosmon: the item I want to call your attention to is related to your fantastic email to list re: framework magic – line 15

[13:51:11 CST(-0600)] <Bosmon> Yes

[13:51:19 CST(-0600)] <Bosmon> I expect to start refactoring UIO at the weekend

[13:51:28 CST(-0600)] <Bosmon> Still blitzing through the Uploader at the moment

[13:52:08 CST(-0600)] <jessm> you are my prince

[13:52:10 CST(-0600)] <jessm> (smile)

[13:52:30 CST(-0600)] <jessm> fantastic. and Justin_o is slaying the VideoPlayer

[13:52:32 CST(-0600)] <Bosmon> Although the initial output of the UIO refactoring will be a component effectively 100% API-compatible with the old one

[13:52:49 CST(-0600)] <Bosmon> Well, I guess that will mostly ALWAYS be the output of the UIO refactoring

[13:53:00 CST(-0600)] <Bosmon> BUt I plan not to do too much with the ants in the first instance

[13:53:36 CST(-0600)] <Bosmon> But the application of "Luke Skywalker options" should make the ants that we DO have a lot easier to work with

[13:53:59 CST(-0600)] <Bosmon> I just took an eye back into the UIO code last night and it was somewhat worse than I remembered : P

[13:54:06 CST(-0600)] <jessm> oh no!

[13:54:08 CST(-0600)] <Bosmon> There really is a whole mini "pseudo-framework" in there...

[13:54:21 CST(-0600)] <Bosmon> That's fine, it just means the results of the refactoring will be a bigger improvement than I thought : )

[13:55:28 CST(-0600)] <jessm> such optimism...

[14:04:04 CST(-0600)] <Bosmon> It is a TIME OF OPTIMISSM : P

[14:04:10 CST(-0600)] <Bosmon> Surely you saw my tweet from last night : P

[14:21:14 CST(-0600)] <Justin_o> Bosmon: sorry, catching up

[14:22:57 CST(-0600)] <Justin_o> Bosmon: the problem is that the event is automatically triggered through the browser, so i don't really think that i can do the event binder method.. but i also am not sure i have the time for the big framework upgrade

[14:23:23 CST(-0600)] <Bosmon> Justin_o - surely you don't have to catch the time of the triggering of the event, you just need to catch the time of creation of the component

[14:24:40 CST(-0600)] <Justin_o> Bosmon: yes.. maybe i'll just bind the listeners the other way around..

[14:25:16 CST(-0600)] <Justin_o> Bosmon: meaning that the media component will do the listener binding for the controls component.. kind of strange

[14:25:36 CST(-0600)] <Bosmon> Justin_o - this is why the 3rd party component solution can seem a slightly better design

[14:26:14 CST(-0600)] <Justin_o> Bosmon: but if it has to be created after both anyways, wouldn't i already have access to that event

[14:26:36 CST(-0600)] <Bosmon> Justin_o - you would have access either way

[14:26:47 CST(-0600)] <Bosmon> But it might just seem better from the dependency point of view that seemed to be worrying you

[14:27:02 CST(-0600)] <Bosmon> When you mentioned that the media component would have the responsibility for event binding outside itself

[14:27:04 CST(-0600)] <Justin_o> Bosmon: i guess i'm somewhat confused by what you mean

[14:27:18 CST(-0600)] <Bosmon> "meaning that the media component will do the listener binding for the controls component.. kind of strange"

[14:27:19 CST(-0600)] <Bosmon> You said this

[14:27:23 CST(-0600)] <Justin_o> yes

[14:27:26 CST(-0600)] <Justin_o> that i get (smile)

[14:27:43 CST(-0600)] <Bosmon> SO you could allay some of this strangeness by pushing the binding responsibility into a separate component if you wanted

[14:28:16 CST(-0600)] <Justin_o> Bosmon: right, but i don't see how that would solve the timing problem i'd have of just putting the listener in the controls component

[14:28:25 CST(-0600)] <Bosmon> It doesn't do anything about the timing problem

[14:28:31 CST(-0600)] <Bosmon> It just does something about the dependency problem : P

[14:28:35 CST(-0600)] <Justin_o> Bosmon: (smile)

[14:28:42 CST(-0600)] <Justin_o> okay.. how do i fix the timing problem then

[14:29:04 CST(-0600)] <Bosmon> I mean, it doesn't do anything EXTRA about the timing problem then by putting the listener binding in the media component

[14:29:07 CST(-0600)] <Bosmon> than by

[14:29:48 CST(-0600)] <Justin_o> Bosmon: the media component could at least be guaranteed to register the listener before it fires the event

[14:30:01 CST(-0600)] <Justin_o> where as i couldn't guarantee that otherwise

[14:30:25 CST(-0600)] <Bosmon> Justin_o - I'm just completely puzzled why you can't just bind the listener at the point the media component constructs

[14:30:26 CST(-0600)] <Justin_o> i suppose i could manage the dependency through demands if you'd prefer that

[14:31:18 CST(-0600)] <Justin_o> maybe i'm being too cautious..

[14:31:49 CST(-0600)] <Justin_o> the issue is that i don't really have much control over when that event will fire.. so i'm afraid that i could run into a situation where the listeners are registered after the event is fired

[14:32:11 CST(-0600)] <Bosmon> Justin_o!

[14:32:25 CST(-0600)] <Bosmon> The event can't fire BEFORE the time the media component constructs!

[14:32:31 CST(-0600)] <Bosmon> And it can't fire before construction of it finishes

[14:33:25 CST(-0600)] <Justin_o> Bosmon: i see… so i can just use it's onAttach

[14:33:32 CST(-0600)] <Justin_o> okay.. that makes more sense

[14:46:13 CST(-0600)] <Bosmon> onCreate would be safer

[14:52:57 CST(-0600)] <Justin_o> Bosmon: that wouldn't be too late? since the event is bound in the final init

[14:54:54 CST(-0600)] <Bosmon> Justin_o - it couldn't FIRE during final init, could it

[14:58:13 CST(-0600)] <Justin_o> Bosmon: i'm assuming it's technically possible to fire, and if that's the case then yes.. i think it could.. since it would be triggered by asynchronous processes from the browser

[14:58:22 CST(-0600)] <Justin_o> i could be mistaken of course (smile)

[15:15:10 CST(-0600)] <Bosmon> If it's technically possible for it to fire then, how could you be even sure of ever catching it yourself

[15:15:38 CST(-0600)] <Bosmon> If was indeed triggered by an asynchronous process, it could never fire then

[15:15:43 CST(-0600)] <Bosmon> Because components construct synchronously

[15:16:05 CST(-0600)] <Bosmon> It seems very unlikely that you could receive this event synchronously on the same call stack on which you created the relevant DOM element

[15:16:11 CST(-0600)] <Bosmon> Justin_o ^

[15:17:20 CST(-0600)] <Justin_o> Bosmon: i guess the way it works is that the source elements are added, the MedieElement is called, and then we bind our events to its

[15:17:50 CST(-0600)] <Bosmon> Justin_o - I think you might have a confusion in your mind between "this happens in response to an event" and "this happens asynchronously"

[15:18:03 CST(-0600)] <Bosmon> I did find a few of your test cases for example that were declared asyncTest for some kind of reason like this

[15:18:07 CST(-0600)] <Justin_o> Bosmon: could be.. right now i feel rather confused

[15:18:14 CST(-0600)] <Bosmon> Whereas it was impossible for the events to actually fire asynchronously

[15:18:27 CST(-0600)] <Justin_o> Bosmon: sounds like I'm confused then (smile)

[15:18:50 CST(-0600)] <Bosmon> Right now, for example, all component trees construct synchronously

[15:19:00 CST(-0600)] <Bosmon> Unless there is a particular cause for them to defer, for example am AJAX call

[15:19:21 CST(-0600)] <Bosmon> So you can be absolutely sure that there has not been time for the browser to respond with an asynchronous event right up to the time the last component in a tree constructs

[15:19:53 CST(-0600)] <Justin_o> Bosmon: really

[15:19:59 CST(-0600)] <Bosmon> yes, really (smile)

[15:20:06 CST(-0600)] <Bosmon> We have no ASYNCHRONOUS GINGER WORLD as yet

[15:20:14 CST(-0600)] <Bosmon> The entire construction process is necessarily synchronous

[15:20:18 CST(-0600)] <Bosmon> Even if it is quite involved in many cases

[15:20:19 CST(-0600)] <Justin_o> so you mean that the video won't fire any of it's native events until after all our components have been created

[15:20:23 CST(-0600)] <Bosmon> You are always on the same "call stack"

[15:20:27 CST(-0600)] <Bosmon> Justin_o - that's correct

[15:20:35 CST(-0600)] <Bosmon> If you look down your call stack you will see that it is VERY DEEP

[15:20:37 CST(-0600)] <Justin_o> Bosmon: okay.. so i guess i don't have to worry about that then

[15:20:43 CST(-0600)] <Bosmon> And stretches right back down to the original construction call site

[15:20:51 CST(-0600)] <Justin_o> i'm generally afraid to look at that call stack

[15:21:01 CST(-0600)] <Bosmon> It is healthy to look down from time to time (smile)

[15:21:04 CST(-0600)] <Bosmon> Even if you get dizzy....

[15:21:17 CST(-0600)] <Justin_o> lol