fluid-work IRC Logs-2013-11-25

[09:13:23 CST(-0600)] <jhung1> /nick jhung

[10:43:46 CST(-0600)] <jhung> danaayotte, vjoanna: I sent you an email with a super rough snapshot of the design I'm working on. Let me know when you have it and we can skype.

[10:46:12 CST(-0600)] <vjoanna> jhung: got it, thanks

[10:47:57 CST(-0600)] <danaayotte> jhung: ok

[11:31:51 CST(-0600)] <michelled> anastasiac: with the prefs framework in the current state, is this still valid? http://issues.fluidproject.org/browse/FLUID-5016

[11:35:16 CST(-0600)] <anastasiac> michelled, I don't know of anything that now addresses this issue, so I'd say yes, it's still something that would be good to have

[11:48:48 CST(-0600)] <michelled> cindyli: if you are looking for something to start on while Justin_o and I finish up planning, you can take a look at the top table of JIRA issues on this page: http://wiki.fluidproject.org/display/fluid/Floe+Iteration+Plan

[11:51:10 CST(-0600)] <cindyli> ok, michelled

[12:00:56 CST(-0600)] <anastasiac> michelled and Justin_o, since you're going through JIRAs, I've created a new one for you http://issues.fluidproject.org/browse/FLUID-5223

[12:08:20 CST(-0600)] <Justin_o> Bosmon: FLUID-5205 and FLUID-5220 have been updated are are ready for you to review again.

[12:28:48 CST(-0600)] <Justin_o> jhung, cindyli, anastasiac: do you have time to chat with michelled and I about FLOE

[12:28:57 CST(-0600)] <anastasiac> sure

[12:29:04 CST(-0600)] <jhung> sure

[12:29:05 CST(-0600)] <cindyli> sure

[12:29:38 CST(-0600)] <Justin_o> jhung: we'll Skype you in

[12:29:43 CST(-0600)] <jhung> ok

[12:41:03 CST(-0600)] <Bosmon> Justin_o - are they still separate?

[14:05:30 CST(-0600)] <Justin_o> sorry.. i'm back now

[14:05:39 CST(-0600)] <Bosmon> Hi Justin_o, it's ok, I have worked it out

[14:05:44 CST(-0600)] <Bosmon> How was the FLOE meeting?

[14:07:00 CST(-0600)] <Justin_o> Bosmon: it was okay.. we still need to work out what the demo will actually be though..

[14:07:10 CST(-0600)] <Justin_o> Bosmon: i think we'll need to do more talking on that

[14:10:18 CST(-0600)] <Bosmon> Hi Justin_o

[14:10:33 CST(-0600)] <Bosmon> I am testing out FLUID-5220 and there is a significant rendering problem with the instructional demos

[14:10:37 CST(-0600)] <Bosmon> I guess this is an issue for anastasiac

[14:11:02 CST(-0600)] <Justin_o> Bosmon: really

[14:11:08 CST(-0600)] <Justin_o> is it the expansion of the panels?

[14:11:11 CST(-0600)] <Bosmon> If I bring up the conditional preferences demo in its initial condition, and then turn the preference to "on", no scrollbar appears and the panel does not adjust its height

[14:11:14 CST(-0600)] <Bosmon> Yes, it is the expansion of the panels

[14:11:40 CST(-0600)] <Justin_o> Bosmon: yes.. i think anastasiac was going to talk to you and maybe vjoanna about that.. can't remember now

[14:11:41 CST(-0600)] <Bosmon> As well as that, there is an unnecessary appearance of a disabed horizonal scrollbar in the panel

[14:11:43 CST(-0600)] <anastasiac> Bosmon, yes, you're right, that's a problem with the instructional demos. I haven't yet figured out a solution for that

[14:13:39 CST(-0600)] <Bosmon> anastasiac - UIO already includes an infrastructure for this, the "onSignificantDOMChange" event which is operated by the "separated panel"

[14:14:08 CST(-0600)] <Bosmon> As well as fixing the CSS for the scrollbars, we should adjust the panel rendering infrastructure to fire this event automatically

[14:14:12 CST(-0600)] <Bosmon> Justin_o ^

[14:14:15 CST(-0600)] <anastasiac> ah, Bosmon, I didn't know about that

[14:14:35 CST(-0600)] <Bosmon> Unfortunately I can't commit the pull in its current form, since the interaction is sort of unusable : P

[14:15:32 CST(-0600)] <Bosmon> It seems it is automatically fired by the updateView method

[14:16:08 CST(-0600)] <Bosmon> Which is itself called by "afterPanelShow" and "onReset"

[14:16:26 CST(-0600)] <Bosmon> Fixing the issue ought to be as simple as binding it to a further rendering event in the hierarchy

[14:16:48 CST(-0600)] <anastasiac> Bosmon, you mean the onSignificantDOMChange is currently being fired?

[14:16:51 CST(-0600)] <Bosmon> I think this would be a good opportunity to refactor the fluid.prefs.separatedPanel.bindEvents method which is very oldfashioned

[14:16:59 CST(-0600)] <Bosmon> anastasiac - it is fired by the two methods I mentioned

[14:17:09 CST(-0600)] <Bosmon> But clearly it needs to be fired on more occasions

[14:17:26 CST(-0600)] <Bosmon> All of this implementation is in the SeparatedPanelPrefsEditor.js which seems in need of a good renovation

[14:17:27 CST(-0600)] <anastasiac> so is this a fix that needs to be carried out in the framework? or is it the instructional demo that needs to listen for the event and do something?

[14:17:38 CST(-0600)] <Bosmon> Of course it must be in the framework : P

[14:17:45 CST(-0600)] <Bosmon> We're not going to expect panel authors to know about this obscure event....

[14:18:01 CST(-0600)] <Justin_o> Bosmon, anastasiac: just on a call at the moment, but i'll check back in with you about the change in a little bit

[14:18:02 CST(-0600)] <anastasiac> ok, that's what I thought, but I wasn't sure - just want to make sure my understanding is correct

[14:18:02 CST(-0600)] <Bosmon> But I'm surprised we haven't run into this issue more often

[14:18:08 CST(-0600)] <anastasiac> you know what they say about "assume"…

[14:29:19 CST(-0600)] <Bosmon> I don't think it's much of an assumption to assume we should deliver things that work : P

[14:34:01 CST(-0600)] <Justin_o> Bosmon: i'm back

[14:34:13 CST(-0600)] <Justin_o> Bosmon: just going to read over the conversation

[14:34:22 CST(-0600)] <Bosmon> Justin_o - I've entered a summary on the FLUID-5220 pull request

[14:34:32 CST(-0600)] <Justin_o> Bosmon: thanks

[14:34:37 CST(-0600)] <Justin_o> i'll read that instead

[14:35:41 CST(-0600)] <Bosmon> When you make your fix, it's ok to just append it to the FLUID-5220 branch to save time

[14:35:49 CST(-0600)] <Bosmon> We can treat this as a "giant integration branch"

[14:36:34 CST(-0600)] <Justin_o> Bosmon: cool thanks.. that'll be easier

[14:36:47 CST(-0600)] <Bosmon> It's actually not all that unrelated to the DOM binding issue in any case

[14:38:03 CST(-0600)] <Justin_o> Bosmon: i take it i just need to fire that event as a result of onDomBind in the case of conditional panel

[14:38:17 CST(-0600)] <Bosmon> Justin_o - that's one possibility, yes

[14:38:39 CST(-0600)] <Justin_o> Bosmon: okay.. and as for the fluid.prefs.separatedPanel.bindEvents function.. you just want that made declarative?

[14:38:45 CST(-0600)] <Bosmon> Justin_o - right

[14:39:01 CST(-0600)] <Bosmon> It should make it easier to bind onto the "extra event" in any case

[14:39:06 CST(-0600)] <Justin_o> okay.. on it.. i'll also try to look into the scrollbar issue.. but not really sure what's up with that

[14:39:06 CST(-0600)] <Bosmon> Since otherwise it is just a dependency risk

[14:39:17 CST(-0600)] <Justin_o> ah okay

[14:39:52 CST(-0600)] <Bosmon> I guess it's reasonable to imagine that "onDomBind" corresponds to all of the remaining cases of a "significant DOM change"

[14:40:01 CST(-0600)] <Bosmon> But that depends on your understanding of the arcthiecture

[14:40:05 CST(-0600)] <Bosmon> architecture

[14:40:40 CST(-0600)] <Justin_o> Bosmon: you mean that onSignificantDomChange would be switched to onDomBind?

[14:40:51 CST(-0600)] <Bosmon> Justin_o - what does that mean?

[14:42:16 CST(-0600)] <Justin_o> Bosmon: i guess i don't fully know what you mean

[14:42:46 CST(-0600)] <Bosmon> Justin_o - well, the "significant DOM change" event was meant to be a reasonably coarse-grained signalling of some DOM change that would cause a major change in layout

[14:43:00 CST(-0600)] <Bosmon> Which we imagine corresponds to an execution of the renderer

[14:43:29 CST(-0600)] <Bosmon> If you're confident that "onDomBind" correlated with all of those, and won't fire unnecessarily too many times, then indeed you should just gear one event to the other

[14:43:33 CST(-0600)] <Bosmon> Using a listener

[14:45:29 CST(-0600)] <Justin_o> Bosmon: ah okay..

[14:45:49 CST(-0600)] <Justin_o> not remove onSignificatnDOMChange and replace it with onDomBind

[14:45:54 CST(-0600)] <Justin_o> both would still exist

[14:46:00 CST(-0600)] <Bosmon> Certainly not

[14:46:01 CST(-0600)] <Bosmon> Yes

[14:46:14 CST(-0600)] <Justin_o> okay. i'll explore that

[14:46:37 CST(-0600)] <Justin_o> i'm going to try to modernize bindEvents first to make sure i don't break thins inadverently

[14:46:58 CST(-0600)] <Bosmon> Justin_o - good plan!

[14:48:00 CST(-0600)]

[14:48:54 CST(-0600)] <Bosmon> Justin_o - that's correct, yes

[14:49:07 CST(-0600)] <Bosmon> You can't force evaluation of a "createOnEvent" component - it is entirely invisible until the event occurs

[14:49:29 CST(-0600)] <Justin_o> Bosmon: okay.. thanks.. so that will resolve to undefined or it won't resolve at all until it is created?

[14:49:47 CST(-0600)] <Bosmon> If there is actually a path component, I believe the framework will even give you an error

[14:49:55 CST(-0600)]

[14:50:08 CST(-0600)]

[14:50:42 CST(-0600)]

[14:50:43 CST(-0600)] <Justin_o> Bosmon: so how would i make use of it.. since i'll need to pass in subcomponents in as arguments to the listeners of others

[14:50:44 CST(-0600)] <Bosmon> fluid.fail("Failed to resolve reference " + ref + " - could not match context with name "

[14:50:44 CST(-0600)] <Bosmon> + context + " from component " + fluid.dumpThat(parentThat), parentThat);

[14:50:54 CST(-0600)] <Justin_o> Bosmon: ah okay

[14:50:59 CST(-0600)] <Justin_o> seen that error before..

[14:51:07 CST(-0600)] <Justin_o> but what is the correct way around it?

[14:51:23 CST(-0600)] <Bosmon> Justin_o - the correct way around it is to properly organise your dependencies

[14:52:04 CST(-0600)] <Justin_o> okay.. so as long as the other component is created before. The resolution will happen at creation time

[14:52:13 CST(-0600)] <Bosmon> Yes

[14:52:30 CST(-0600)] <Justin_o> okay.. i'll just try to sort out the timing of these subcomopnents

[14:52:35 CST(-0600)] <Bosmon> You shouldn't be issuing references to components which you aren't sure exist

[14:52:42 CST(-0600)] <Bosmon> Justin_o - what timing issue are you thinking of in particular?

[14:53:24 CST(-0600)] <Justin_o> Bosmon: looks like these subcomponents are all created at different times and listeners for one will need to call actions on another

[14:53:58 CST(-0600)] <Bosmon> Justin_o - a great reason to sort out the mess in the "bindEvents" method : P

[14:54:23 CST(-0600)] <Justin_o> Bosmon: yes.. it takes advantage of being called after everything is done

[14:54:45 CST(-0600)] <Bosmon> Justin_o - it's acceptable to move all this material into a dedicated "event binding component" if the timing gets too complicated

[14:54:55 CST(-0600)] <Bosmon> And have that component "createOnEvent" after the lastest thing that it refers to

[14:55:12 CST(-0600)] <Bosmon> But it may be possible to factor out this material into parts which can be bound straightforwardly and declaratively

[14:55:25 CST(-0600)] <Bosmon> That is, the contents of this method probably need to be sent out to a number of different locations

[14:55:32 CST(-0600)] <Bosmon> So keeping it all together may not be the right answer

[14:56:52 CST(-0600)] <Justin_o> Bosmon: yes.. trying to break it all out first

[15:33:31 CST(-0600)] <Justin_o> Bosmon: i'm heading out now.. i won't have this done tonight i'll keep looking into it tomorrow..

[15:36:26 CST(-0600)] <Bosmon> Justin_o - cool, good luck