fluid-work IRC Logs-2011-03-17
[09:04:10 CDT(-0500)] <Justin_o> colinclark, anastasiac: I'm wondering what the status of the readme / release notes is
[09:04:19 CDT(-0500)] <Justin_o> i think we started work on that a while back
[09:05:05 CDT(-0500)] <colinclark> oh yes
[09:05:12 CDT(-0500)] <colinclark> I think the ball is in my court on that one
[09:06:29 CDT(-0500)] <anastasiac> colinclark, right - you wanted to make some edits
[09:06:30 CDT(-0500)] <Justin_o> colinclark: okay... any idea when it might be ready...
[09:07:46 CDT(-0500)] <michelled> Justin_o: here's the test quadrants that I was trying to remember yesterday: http://www.betterprojects.net/2010/08/lisa-crispins-test-quadrants.html
[09:08:01 CDT(-0500)] <Justin_o> michelled: thanks
[09:08:18 CDT(-0500)] <colinclark> Justin_o: I want to get to it soon
[09:08:26 CDT(-0500)] <colinclark> I've been stuck with failing tests for a few days now
[09:08:29 CDT(-0500)] <colinclark> got to get through that
[09:08:40 CDT(-0500)] <colinclark> and then I think the UI Options love has to get rolling
[09:08:57 CDT(-0500)] <colinclark> and mlam is waiting on code review
[09:09:02 CDT(-0500)] <colinclark> it's turning out to be one of those weeks
[09:09:04 CDT(-0500)] <colinclark> or two weeks?
[09:09:16 CDT(-0500)] <colinclark> Justin_o: Are we feeling any huge pressure?
[09:10:30 CDT(-0500)] <Justin_o> colinclark: um.. not a huge pressure
[09:10:42 CDT(-0500)] <Justin_o> just wondering, since i was looking through the 1.4 release page
[09:11:23 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Infusion+1.4+Release+Status
[09:11:56 CDT(-0500)] <colinclark> jessm: remember the new README?
[09:12:13 CDT(-0500)] <jessm> colinclark: yeppers
[09:12:19 CDT(-0500)] <jessm> colinclark: yeppers peppers
[09:12:40 CDT(-0500)] <colinclark> Do you think we should go ahead and push anastasiac's nice changes to the two files--the README and a new Release Notes?
[09:12:49 CDT(-0500)] <colinclark> And then perhaps I can do some edits later in the release cycle
[09:13:00 CDT(-0500)] <jessm> anastasiac had a draft that was going to get pushed into a place for editing and then placed onto its proper location
[09:13:07 CDT(-0500)] <jessm> roger that +1
[09:13:09 CDT(-0500)] <colinclark> once these unit tests have capitulated
[09:13:10 CDT(-0500)] <jessm> push n' edit
[09:13:14 CDT(-0500)] <colinclark> ok
[09:13:27 CDT(-0500)] <colinclark> Justin_o: Let's get the changes in now, and I'll edit "whenever"
[09:13:49 CDT(-0500)] <jessm> im happy to edit too, i've been digging into more writing lately and want to keep the flow
[09:14:38 CDT(-0500)] <colinclark> ok
[09:14:43 CDT(-0500)] <colinclark> write on, hemingway
[09:14:52 CDT(-0500)] <jessm> 
[09:14:58 CDT(-0500)] <jessm> not that much good writing
[09:15:20 CDT(-0500)] <Justin_o> colinclark, jessm: sounds good
[09:15:35 CDT(-0500)] <Justin_o> jessm: do you happen to have a github acocunt?
[09:16:04 CDT(-0500)] <jessm> Justin_o: i do not, and i've been thinking it would come to something like this...
[09:16:26 CDT(-0500)] <colinclark> I really want to take a stab at writing about Infusion
[09:16:51 CDT(-0500)] <jessm> colinclark: i'll bring gatorade!
[09:16:57 CDT(-0500)] <Justin_o> jessm: well if you do set one up, let me know and I'll add you to our contributor list on github
[09:17:07 CDT(-0500)] <colinclark> jessm is going to use Github?
[09:17:19 CDT(-0500)] <jessm> Justin_o: i'm not sure i should
[09:17:33 CDT(-0500)] <jessm> Justin_o: can i edit w/o?
[09:17:57 CDT(-0500)] <colinclark> jessm: I don't know that you'd have any trouble with Git
[09:18:03 CDT(-0500)] <colinclark> Has anyone tried a graphical Git client yet?
[09:18:16 CDT(-0500)] <jessm> colinclark: is there a reason i shouldn't use it?
[09:18:20 CDT(-0500)] <colinclark> jessm: Nope
[09:18:27 CDT(-0500)] <colinclark> Other than the fact that I'm still scared of Git
[09:18:52 CDT(-0500)] <jessm> well, i'm appropriately scared of it too
[09:19:11 CDT(-0500)] <jessm> and worry i'll be needy
[09:19:33 CDT(-0500)] <jessm> http://www.syntevo.com/smartgit/index.html
[09:20:12 CDT(-0500)] <Justin_o> jessm, colinclark : this is the best one I've found so far
[09:20:12 CDT(-0500)] <Justin_o> http://www.git-tower.com/
[09:20:18 CDT(-0500)] <Justin_o> it has a 30day free trial
[09:20:49 CDT(-0500)] <jessm> nice
[09:20:51 CDT(-0500)] <colinclark> cool
[09:21:01 CDT(-0500)] <colinclark> why not try it, jessm?
[09:21:56 CDT(-0500)] <Justin_o> I'm still waiting for jameswy to ask them for some free licenses... since he was able to get us some for versions..
[09:24:38 CDT(-0500)] <heidi_> Justin_o looking at column styles... still not understanding lines 153-172 ... i mean why it just applies to those styles, not all
[09:25:10 CDT(-0500)] <Justin_o> heidi_: i'll take a peak
[09:26:22 CDT(-0500)] <heidi_> Justin_o right above it is .fl-layout-linear * too
[09:28:11 CDT(-0500)] <Justin_o> heidi_: you mean why we don't set every style to have width 100% for example
[09:28:22 CDT(-0500)] <Justin_o> or you mean all the flex styles
[09:28:53 CDT(-0500)] <heidi_> Justin_o trying to figure out what teh difference is, do you know?
[09:29:25 CDT(-0500)] <heidi_> so the first part clears everything
[09:29:52 CDT(-0500)] <heidi_> then the second part makes only some stuff 100% width
[09:31:17 CDT(-0500)] <Justin_o> heidi_: when you say stuff.. you mean you are expecting all the container and column styling to have width 100%?
[09:31:18 CDT(-0500)] <heidi_> i also wonder what this does /* Generic container, proxy for other container effects */ .fl-container {}
[09:31:24 CDT(-0500)] <Justin_o> or all elements to have width 100%
[09:31:53 CDT(-0500)] <heidi_> Justin_o trying to figure out why some would be set to 100%, and others not
[09:32:09 CDT(-0500)] <heidi_> and why strip padding...
[09:32:14 CDT(-0500)] <heidi_> and margin auto
[09:33:05 CDT(-0500)] <heidi_> i'm wondering if it's just old, and hasn't included the new col styles
[09:33:17 CDT(-0500)] <Justin_o> heidi_: hmm.. that's possible
[09:33:21 CDT(-0500)] <heidi_> but then, why not put width:100% in the line above with the *
[09:33:23 CDT(-0500)] <Justin_o> we can look through the history of the code
[09:34:22 CDT(-0500)] <Justin_o> heidi_: just to double check if you use * that means any element?
[09:34:43 CDT(-0500)] <heidi_> Justin_o yes, but i wonder if that only works in certain browsers? will read up on it
[09:34:56 CDT(-0500)] <heidi_> still, the two sets of styles are different so... hm
[09:38:17 CDT(-0500)] <Justin_o> heidi_: from what i can see the mobile stuff uses fl-container
[09:39:33 CDT(-0500)] <Justin_o> its also used in the fss test page
[09:39:33 CDT(-0500)] <Justin_o> http://build.fluidproject.org/infusion/tests/framework-tests/fss/html/1.fss.layout.containers.html
[09:39:41 CDT(-0500)] <Justin_o> and labeled as default
[09:40:31 CDT(-0500)] <jessm> k, i've cloned a read-only version of the master for infusion – i'm appropriately frightened to do anything else
[09:40:40 CDT(-0500)] <jessm> i'm not sure about this path for me Justin_o
[09:40:52 CDT(-0500)] <heidi_> Justin_o interesting. so just getting ppl to use an empty style purely for the contextual help
[09:42:00 CDT(-0500)] <Justin_o> jessm: it's up to you.. i don't want to give you extra stress 
[09:42:23 CDT(-0500)] <Justin_o> if you did want to try using git though.. i can talk you through some steps if you like
[09:42:40 CDT(-0500)] <jessm> Justin_o: let's see how far we can take this before something explodes
[09:43:03 CDT(-0500)] <jessm> Justin_o: but let's just focus on the readme.txt file
[09:43:08 CDT(-0500)] <Justin_o> heidi_: looks like it.. i'm not sure.. it could have had some practical purpose that I'm not aware.. maybe it's useful when switching between mobile and desktop themes or something
[09:43:19 CDT(-0500)] <Justin_o> jessm: okay.. makes sense
[09:47:26 CDT(-0500)] <heidi_> Justin_o i think we need a jira for improving comments in all the .css files
[09:48:08 CDT(-0500)] <heidi_> no fl-container in mobile-layout.
[09:48:29 CDT(-0500)] <heidi_> prob just a catch-all or something, not sure...
[09:50:51 CDT(-0500)] <Justin_o> heidi_: hmm.. i saw it in the demos for the mobile layout i think
[10:24:40 CDT(-0500)] <heidi_> Justin_o adding http://issues.fluidproject.org/browse/FLUID-4149 to roadmap
[10:51:56 CDT(-0500)] <colinclark> heidi_: Seems like you really had an impact on Johnny yesterday
[10:52:01 CDT(-0500)] <colinclark> thanks so much for hanging out with him
[10:52:04 CDT(-0500)] <colinclark> He tweeted about it
[10:52:11 CDT(-0500)] <heidi_> my pleasure. yeah i saw that! nice
[10:52:12 CDT(-0500)] <colinclark> and we were chatting by email, and here's what he said:
[10:52:27 CDT(-0500)] <colinclark> "Helpful? Somehow that doesn't begin to describe what went on yesterday. In a perverse kinda way, it was remarkably enlightening. It gave me a much needed context. This just isn't tricky to me. It's tricky for everyone, including you! Before yesterday I was completely embarrassed about not being able to get it. While I still am, in some respects, not learning Javascript by now mainly, I am re-driven."
[10:52:44 CDT(-0500)] <colinclark> I think he saw me banging my head against these broken Uploader tests 
[10:54:06 CDT(-0500)] <heidi_> hahaa... yeah we had to spend some time debugging UIO implementation (ended up being a few minor typos). and also the figuring out which fss classes were available to certain situations was something we spent time discussing... was a really good experience for me as well
[10:54:13 CDT(-0500)] <colinclark> cool
[10:54:16 CDT(-0500)] <colinclark> I'm really glad
[10:54:27 CDT(-0500)] <colinclark> Seems like it'll be a pretty useful deliverable, if we get it
[10:54:30 CDT(-0500)] <heidi_> i could see johnny becoming an fss wiz
[10:54:30 CDT(-0500)] <colinclark> an FSS theme for WP
[10:54:34 CDT(-0500)] <colinclark> that'd be great
[10:54:39 CDT(-0500)] <heidi_> and having really good feedback
[10:55:24 CDT(-0500)] <colinclark> cool
[12:50:05 CDT(-0500)] <heidi_> hey justin_o i think we can close the column jira (fluid-4025) and i'll open a new one for the fl-layout-linear stuff. i'm working on a test page for linearizing now
[12:50:31 CDT(-0500)] <justin_o> heidi_: thanks.. okay will do
[12:50:33 CDT(-0500)] <heidi_> there's def something up with it
[12:50:35 CDT(-0500)] <heidi_> okay thanks
[12:51:15 CDT(-0500)] <justin_o> heidi_: is the page not linearizing for you.. or are you experimenting with why there are only a few column styles with 100% width set?
[12:51:49 CDT(-0500)] <heidi_> justin_o the latter. i think we can use this to test out the absolute position issue as well
[12:52:22 CDT(-0500)] <justin_o> oh for the table scrolling?
[12:53:13 CDT(-0500)] <heidi_> justin_o no for FLUID-2396
[12:55:08 CDT(-0500)] <justin_o> ah i see, that makes sense
[12:57:23 CDT(-0500)] <heidi_> justin_o i've added FLUID-4150 to the roadmap
[12:57:42 CDT(-0500)] <justin_o> heidi_: thanks
[12:57:54 CDT(-0500)] <justin_o> I closed off FLUID-4025
[12:58:01 CDT(-0500)] <heidi_> cool
[12:59:53 CDT(-0500)] <justin_o> heidi_: I just updated the FSS roadmap page with the status of the jiras i'm working on, could you do that as well
[13:00:25 CDT(-0500)] <heidi_> sure
[13:40:10 CDT(-0500)] <jhung> anastasiac: How do you feel about the term "Full featured demo" to describe our marketing demo?
[13:40:33 CDT(-0500)] <jhung> anastasiac: I would like to use "Full-bodied Demo", but I think that's being too cute.
[13:40:34 CDT(-0500)] * anastasiac considers
[13:42:11 CDT(-0500)] <anastasiac> jhung, full-featured sounds pretty good. You might want to mock it up, along with the "Customizing Inline Edit" link, and show it to a couple of people, and ask them what they would expect the links to lead to.
[13:44:17 CDT(-0500)] <jhung> anastasiac: Good point. I'll do that shortly.
[13:58:00 CDT(-0500)] <jhung> anastasiac: "Full-featured" will work only if it's true (i.e. if the demo actually uses all options).
[13:58:15 CDT(-0500)] <jhung> not sure if that will always be true.
[13:58:23 CDT(-0500)] <anastasiac> jhung, probably not in all cases
[13:58:29 CDT(-0500)] <jhung> yeah.
[13:58:32 CDT(-0500)] <anastasiac> so what, then, "most-featured"??
[13:58:38 CDT(-0500)] <anastasiac> "many featured"?
[13:58:51 CDT(-0500)] <anastasiac> "slick demos"?
[13:59:38 CDT(-0500)] * jhung thinking...
[14:50:40 CDT(-0500)] <heidi_> justin_o kinda weird: if i have a div with fl-col-flex4 fl-container-750 and inside 4 divs with fl-col, i'd expect 4 columns within the 750px container, right?
[14:51:23 CDT(-0500)] <heidi_> the cols end up too wide so the 4th one is on the next line
[14:53:04 CDT(-0500)] <justin_o> heidi_: try changing your browser window size
[14:53:11 CDT(-0500)] <justin_o> it might have to do with the sub pixel rounding
[14:53:19 CDT(-0500)] <heidi_> justin_o doesn't do anything
[14:54:09 CDT(-0500)] <justin_o> heidi_: hmm
[14:54:18 CDT(-0500)] <justin_o> what size are each of the fl-cols
[14:54:50 CDT(-0500)] <heidi_> .fl-col-flex4 .fl-col {
[14:54:50 CDT(-0500)] <heidi_> margin-left: 0.25%;
[14:54:50 CDT(-0500)] <heidi_> margin-right: 0.25%;
[14:54:51 CDT(-0500)] <heidi_> padding-left: 0.25%;
[14:54:51 CDT(-0500)] <heidi_> padding-right: 0.25%;
[14:54:51 CDT(-0500)] <heidi_> width: 24%;
[14:54:51 CDT(-0500)] <heidi_> }
[14:54:51 CDT(-0500)] <heidi_> fss-layout.css (line 105)
[14:55:56 CDT(-0500)] <heidi_> finding the fss column stuff confusing...
[14:57:02 CDT(-0500)] <justin_o> heidi_: i usually look at this page for the columns
[14:57:02 CDT(-0500)] <justin_o> http://build.fluidproject.org/infusion/tests/framework-tests/fss/html/2.fss.layout.columns.html
[14:57:33 CDT(-0500)] <heidi_> justin_o yeah but the issue is because of my container width i think?
[14:57:53 CDT(-0500)] <justin_o> yes.. let me try to modify that demo to see if i can recreate your issue
[14:58:34 CDT(-0500)] <heidi_> i added fl-container-750 to the large container and it worked. i wonder if the reset file is essential..
[14:58:44 CDT(-0500)] <heidi_> that would be weird tho
[14:59:41 CDT(-0500)] <justin_o> heidi_: hmm.. not sure.. maybe
[14:59:56 CDT(-0500)] <justin_o> i tried with the test page i sent pointed you too and couldn't reproduce the issue
[15:00:02 CDT(-0500)] <justin_o> which browser are you using by the way
[15:00:04 CDT(-0500)] <justin_o> ?
[15:00:35 CDT(-0500)] <heidi_> justin_o i can't reproduce on test page either. i'll send you my linear test soon tho
[15:00:35 CDT(-0500)] <heidi_> ff
[15:01:02 CDT(-0500)] <justin_o> heidi_: thanks
[15:01:41 CDT(-0500)] <justin_o> heidi_: i have to run, can you e-mail it to me or we can chat some more tomorrow
[15:01:55 CDT(-0500)] <heidi_> justin_o for sure. ttyl!
[15:02:11 CDT(-0500)] <justin_o> heidi_: thanks
[15:02:48 CDT(-0500)] <justin_o> heidi_: if you have any thoughts about the fss issues i e-mailed the list about, could you please reply.. i might have covered all the stuff we had talked about, but if there is anything more it would be good to hear
[15:02:49 CDT(-0500)] <justin_o> thanks
[15:03:00 CDT(-0500)] <heidi_> will do
[15:45:04 CDT(-0500)] <Bosmon> colinclark has asked me to ask about the current state of UIOptions
[15:45:21 CDT(-0500)] <colinclark> Bosmon: Things are going quite well
[15:45:25 CDT(-0500)] <Bosmon> I see a few recent suggestive-looking commits
[15:45:31 CDT(-0500)] <colinclark> michelled and I now have the preview split out into a separate component
[15:45:35 CDT(-0500)] <Bosmon> That's great
[15:45:41 CDT(-0500)] <colinclark> which will make it easy to accommodate James' designs
[15:45:48 CDT(-0500)] <colinclark> two of which have no preview, and the third does
[15:46:47 CDT(-0500)] <colinclark> So, that's a big improvement
[15:47:53 CDT(-0500)] <colinclark> Everything is now nearly all IoC-ified
[15:48:11 CDT(-0500)] <colinclark> we'll probably turn it into a proper rendererComponent next
[15:48:20 CDT(-0500)] <Bosmon> Yes, that looks like a great next step
[15:50:25 CDT(-0500)] <Bosmon> This might start to expose the crucial next issues with "antigens" etc.
[15:50:36 CDT(-0500)] <Bosmon> I notice that right now the component is prepared to start up asynchronously
[15:52:11 CDT(-0500)] <Bosmon> I notice you have applied the "event binding trick" again here
[15:53:07 CDT(-0500)] <Bosmon> This must be one of the framework features which has had the most lightning short interval between being proposed, implemented and universally adopted
[15:54:05 CDT(-0500)] <colinclark> Yeah
[15:54:10 CDT(-0500)] <colinclark> it was not simple, in this case
[15:54:24 CDT(-0500)] <colinclark> So, Preview listens to an event on UI Options
[15:54:32 CDT(-0500)] <Bosmon> I see that preview has this slightly awkward "staggered workflow"
[15:54:39 CDT(-0500)] <Bosmon> What does container.contents() do?
[15:54:55 CDT(-0500)] <colinclark> Container, at the moment, is an iFrame
[15:55:02 CDT(-0500)] <colinclark> (and probably for the foreseeable future)
[15:55:09 CDT(-0500)] <Bosmon> Interesting
[15:55:16 CDT(-0500)] <colinclark> container.contents() returns the iFrame's $(document)
[15:55:20 CDT(-0500)] <Bosmon> So the crucial issue is that this is something we cannot handle with the current DOM binder?
[15:55:30 CDT(-0500)] <colinclark> As far as we can remember, that's right
[15:55:31 CDT(-0500)] <Bosmon> I wonder if it would make more sense to fold this workflow into its DOM binder, if we can
[15:55:39 CDT(-0500)] <colinclark> iFrame awareness?
[15:55:49 CDT(-0500)] <colinclark> It's not a terrible idea
[15:55:55 CDT(-0500)] <Bosmon> Well, it is possible to supply "manual functions" as part of the configuration of the DOM binder
[15:56:03 CDT(-0500)] <colinclark> "Staggered," meaning, it doesn't initialize its dependents until "sometime later?"
[15:56:06 CDT(-0500)] <Bosmon> And now we have IoC, we can probably find better kinds of syntax for doing this
[15:56:18 CDT(-0500)] <Bosmon> Yes, that is what I meant
[15:56:43 CDT(-0500)] <colinclark> yes
[15:56:50 CDT(-0500)] <colinclark> I guess this caused the problem we were seeing, though I don't quite know
[15:57:03 CDT(-0500)] <colinclark> I became so discouraged watching Fish step through framework code in puzzlement
[15:57:04 CDT(-0500)] <Bosmon> What kind of problem was it?
[15:57:11 CDT(-0500)] <colinclark> So
[15:57:26 CDT(-0500)] <colinclark> Preview's updateModel listens to UI Options modelChanged event
[15:57:34 CDT(-0500)] <colinclark> So we created preview.eventBinder to bind them together
[15:57:40 CDT(-0500)] <colinclark> we should push our latest working version so you can see
[15:57:51 CDT(-0500)] <Bosmon> Ok, thanks
[15:58:02 CDT(-0500)]
<colinclark> So, as a child of preview, this eventBinder failed to resolve the firer "
.event.modelChanged"
[15:58:11 CDT(-0500)] <colinclark> but as a child of UI Options, it worked
[15:58:16 CDT(-0500)] <colinclark> let me just commit and push now
[15:58:31 CDT(-0500)] <colinclark> You're looking in my FLUID-4140, right?
[15:59:01 CDT(-0500)] <Bosmon> yes
[15:59:12 CDT(-0500)] <Bosmon> Well, I was actually just looking at the commit
[15:59:21 CDT(-0500)] <Bosmon> Interestingly github didn't really think I was looking at a "branch" as such
[15:59:41 CDT(-0500)] <colinclark> Okay, it's up there
[16:01:10 CDT(-0500)] <colinclark> So, Bosmon, do you have some kind of watch on my repo?
[16:01:16 CDT(-0500)] <Bosmon> I don't
[16:01:18 CDT(-0500)] <colinclark> How did you know so soon?
[16:01:26 CDT(-0500)] <Bosmon> I just periodically glance at the "infusion network diagram"
[16:01:30 CDT(-0500)] <colinclark> ahhh
[16:01:32 CDT(-0500)] <colinclark>
[16:01:37 CDT(-0500)] <Bosmon> Which gives me a fairly clear idea when people have been "up to stuff"
[16:01:41 CDT(-0500)] <Bosmon> You are currently the "salient"
[16:01:51 CDT(-0500)] <colinclark> The network diagram
[16:01:56 CDT(-0500)] <colinclark> Fish's favourite?
[16:02:01 CDT(-0500)] <michelled>
[16:02:24 CDT(-0500)] <colinclark> Bosmon: Another question we're curious about...
[16:02:39 CDT(-0500)] <colinclark> These text field sliders in UI Options had a TODO on them
[16:02:46 CDT(-0500)] <colinclark> to turn them into Renderer Decorators
[16:02:58 CDT(-0500)] <colinclark> As you know, I lost faith in Renderer Decorators quite awhile ago
[16:03:06 CDT(-0500)] <Bosmon> Yes
[16:03:10 CDT(-0500)] <colinclark> but yura_ tells me they now has some more appealing properties
[16:03:15 CDT(-0500)] <Bosmon> It is possible your faith could now be revitalised
[16:03:23 CDT(-0500)] <Bosmon> Yes, renderer decorators are now IoC-aware
[16:03:34 CDT(-0500)] <Bosmon> Which is sort of crucial, for them to be of any use
[16:03:42 CDT(-0500)] <colinclark> That was my issue, yes
[16:05:38 CDT(-0500)]
<Bosmon> So, tell me about the case where you failed to resolve
.event.modelChanged
[16:06:08 CDT(-0500)] <colinclark> ok
[16:06:39 CDT(-0500)] <colinclark> So you can see the demands block for fluid.uiOptions.preview.eventBinder at line 569
[16:06:55 CDT(-0500)] <Bosmon> let me switch to FireFox so line numbers work
[16:07:13 CDT(-0500)] <colinclark> Opera and GitHub don't play nice?
[16:07:24 CDT(-0500)] <Bosmon> Opera isn't even a starter
[16:07:27 CDT(-0500)] <Bosmon> This is in Chrome
[16:07:29 CDT(-0500)] <colinclark> that really sucks
[16:07:32 CDT(-0500)] <colinclark> oh wow
[16:07:35 CDT(-0500)] <colinclark> Chrome!!
[16:07:41 CDT(-0500)] <Bosmon> They have a problem with their CSS in that the line number display is condensed in Chrome
[16:07:48 CDT(-0500)] <colinclark> Crazy
[16:07:49 CDT(-0500)] <Bosmon> That is, it does not actually align with the source code
[16:07:59 CDT(-0500)] <Bosmon> But is, say, about 2% shorter
[16:08:08 CDT(-0500)] <colinclark> So, the left-hand value at line 572
[16:08:14 CDT(-0500)] <colinclark> Just failed to resolve properly
[16:08:24 CDT(-0500)] <Bosmon> ok
[16:08:27 CDT(-0500)] <Bosmon> In what situation?
[16:08:46 CDT(-0500)] <colinclark> When the eventBinder was a component of fluid.uiOptions.preview
[16:09:00 CDT(-0500)] <colinclark> You can see now we have it, not ideally, as a child of fluid.uiOption itself
[16:09:07 CDT(-0500)] <Bosmon> Sooner, rather than later, we need a "demands blocks browser".....
[16:09:25 CDT(-0500)] <colinclark>
[16:11:49 CDT(-0500)] <Bosmon> Well, I notice that fluid.uiOptions.preview contains no call to fluid.initDependents()
[16:11:54 CDT(-0500)] <Bosmon> Was that there, at the time you tried that?
[16:12:09 CDT(-0500)] <Bosmon> Oh I see, it does it later
[16:12:20 CDT(-0500)] <Bosmon> This is the same component we were talking about earlier
[16:13:23 CDT(-0500)] <colinclark>
[16:14:10 CDT(-0500)] <Bosmon> Tell me, how does the "load" function work?
[16:14:53 CDT(-0500)] <Bosmon> Oh... is this a jQuery thing?
[16:14:57 CDT(-0500)] <colinclark> Yeah
[16:15:04 CDT(-0500)] <colinclark> We had to wait for the iFrame to load
[16:15:08 CDT(-0500)] <Bosmon> Oh dear
[16:15:13 CDT(-0500)] <Bosmon> Well, this would be the source of the problems
[16:15:24 CDT(-0500)] <Bosmon> I'd be amazed if this would work at all....
[16:15:31 CDT(-0500)] <Bosmon> initDependents needs to be called synchronously
[16:15:36 CDT(-0500)] <colinclark> ok
[16:15:39 CDT(-0500)] <Bosmon> Otherwise it does not have access to the "trunk instantiator"
[16:15:41 CDT(-0500)] <colinclark> that's what my guess was
[16:15:57 CDT(-0500)] <Bosmon> And instead starts a completely separate instantiation, that does not have any visibility up the tree
[16:16:00 CDT(-0500)] <colinclark> what can we do?
[16:16:13 CDT(-0500)] <colinclark> I mean, we have a workaround, but it's awkward
[16:16:21 CDT(-0500)] <colinclark> arguably, these event binders are workarounds themselves
[16:16:26 CDT(-0500)] <Bosmon> Are they?
[16:16:27 CDT(-0500)] <colinclark> although relatively appealing ones
[16:16:30 CDT(-0500)] <Bosmon> What would you do, ideally?
[16:16:41 CDT(-0500)] <colinclark> Not have to write one at all
[16:16:50 CDT(-0500)] <colinclark> already, it feels highly repetitive
[16:16:56 CDT(-0500)] <colinclark> like any thing that a programmer "just does"
[16:16:58 CDT(-0500)] <colinclark> if that makes sense
[16:17:01 CDT(-0500)] <Bosmon> Yes
[16:17:07 CDT(-0500)] <Bosmon> So what part of this could be automated, do you think?
[16:17:31 CDT(-0500)] <colinclark> Certainly we could condense the basic pattern down to some helper
[16:17:34 CDT(-0500)] <Bosmon> You mean, having to make the special subcomponent?
[16:17:38 CDT(-0500)] <colinclark> yes
[16:17:51 CDT(-0500)] <colinclark> I mean, really we've got a name and some event bindings
[16:17:54 CDT(-0500)] <Bosmon> Well, this is less necessary here, since I guess you are not expecting to advise it with a demands block?
[16:18:01 CDT(-0500)] <colinclark> hmm
[16:18:04 CDT(-0500)] <colinclark> What do you mean?
[16:18:13 CDT(-0500)] <Bosmon> Or would you like to keep the component, and just have a shorter syntax for it?
[16:18:26 CDT(-0500)] <colinclark> I think I might like to advise it with a demands block
[16:18:29 CDT(-0500)] <colinclark> again, say, for testing
[16:18:32 CDT(-0500)] <Bosmon> ok
[16:18:40 CDT(-0500)] <colinclark> I suppose the shortest syntax I can imagine is also achievable
[16:18:50 CDT(-0500)] <Bosmon> What can you imagine?
[16:18:51 CDT(-0500)] <colinclark> fluid.makeEventBinder(name, bindings)
[16:18:57 CDT(-0500)] <Bosmon> Right
[16:19:09 CDT(-0500)] <Bosmon> No problem with that
[16:19:12 CDT(-0500)] <colinclark>
[16:19:19 CDT(-0500)] <colinclark> Shall I go ahead and create such a thing, then?
[16:19:39 CDT(-0500)] <Bosmon> Why not - but what will you do about the scoping of the demands block?
[16:19:50 CDT(-0500)] <colinclark> ah, yes
[16:19:58 CDT(-0500)] <colinclark> that will be necessary, too
[16:20:23 CDT(-0500)] <colinclark> this feels sort of reversely socratic
[16:20:34 CDT(-0500)] <Bosmon> hahaha
[16:20:48 CDT(-0500)] <Bosmon> Surely ALL MEN are Socrates
[16:20:51 CDT(-0500)] <colinclark>
[16:21:07 CDT(-0500)] <colinclark> I guess we're stuck with fluid.makeEventBinder(name, scope, bindings), then
[16:21:12 CDT(-0500)] <Bosmon> Yes
[16:21:18 CDT(-0500)] <Bosmon> And I am not convinced that it is a good idea
[16:21:25 CDT(-0500)] <Bosmon> I think it would negatively impact the readability of the code quite a lot
[16:21:28 CDT(-0500)] <colinclark> it's not going to compress things a whole lot
[16:21:29 CDT(-0500)] <Bosmon> Both by humans, and machines
[16:22:05 CDT(-0500)] <Bosmon> The more ways we create to "hide" demands blocks, for each one, we need to create mechanisms for unpacking them again
[16:22:16 CDT(-0500)] <colinclark> yes, I was thinking exactly that
[16:22:29 CDT(-0500)] <Bosmon> That scheme would also then create an asymmetry
[16:22:43 CDT(-0500)] <Bosmon> Between the person who "makes the event binder for the first time" and the "second person who then write a demands block for it"
[16:22:47 CDT(-0500)] <colinclark> yes
[16:23:26 CDT(-0500)] <colinclark> So, changing the subject slightly, what about this asynchrony?
[16:23:29 CDT(-0500)] <Bosmon> Yes
[16:23:40 CDT(-0500)] <colinclark> It's great that it works
[16:23:42 CDT(-0500)] <colinclark> but it's not ideal
[16:23:46 CDT(-0500)] <Bosmon> The "official" way round that is to inject the instantiator, explicitly
[16:23:50 CDT(-0500)] <colinclark> ah, yes
[16:23:56 CDT(-0500)] <colinclark> Yura resorts to such tricks
[16:24:05 CDT(-0500)] <Bosmon> And to make a special call to "initDependent" for the late component
[16:24:23 CDT(-0500)] <Bosmon> I presume this also exposes the fact that only ONE of your subcomponent is meant to be "late"
[16:24:40 CDT(-0500)] <Bosmon> But in the past, given you made a blanket "late call" to initDependents, the event binder got orphaned too
[16:24:55 CDT(-0500)] <colinclark> Actually, they all need to be late
[16:24:59 CDT(-0500)] <colinclark> hmm
[16:25:02 CDT(-0500)] <colinclark> eek
[16:25:07 CDT(-0500)] <Bosmon> I assume what you really want to happen is the event binder to construct at the usual time, and the enhancer to come late
[16:25:30 CDT(-0500)] <colinclark> well, let me see
[16:25:41 CDT(-0500)] <colinclark> yep, that's true
[16:25:50 CDT(-0500)] <colinclark> the enhancer has to come late because of the iFrame's asynchrony
[16:25:56 CDT(-0500)] <colinclark> okay
[16:26:00 CDT(-0500)] <colinclark> let me do this, then
[16:26:10 CDT(-0500)]
<colinclark> Preview will get a new component--the
[16:26:38 CDT(-0500)] <Bosmon> This then raises the issue of where the configuration goes for the event binder
[16:26:43 CDT(-0500)] <colinclark> indeed
[16:26:43 CDT(-0500)] <Bosmon> Currently we don't have a standard for this
[16:26:46 CDT(-0500)] <Bosmon> But I think we had better make one
[16:26:52 CDT(-0500)] <colinclark> Yura has some convention he uses, doesn't he?
[16:26:59 CDT(-0500)] <colinclark> delayedComponents or something?
[16:27:04 CDT(-0500)] <Bosmon> Yes, he creates a special area called "deferredComponents"
[16:27:06 CDT(-0500)] <colinclark> yes
[16:27:27 CDT(-0500)] <colinclark> with the cost of a bunch of extra code
[16:27:29 CDT(-0500)] <Bosmon> We could go with that
[16:27:47 CDT(-0500)] <colinclark> Ah, that was probably just in the case of Uploader
[16:27:51 CDT(-0500)] <colinclark> I'm fine with it
[16:27:55 CDT(-0500)] <Bosmon> Well, there shouldn't be any more code than the call to initDependent
[16:28:01 CDT(-0500)] <Bosmon> Everything else should just work
[16:28:12 CDT(-0500)] <Bosmon> There is though the crucial issue of a proper mergePolicy for this new area
[16:28:18 CDT(-0500)] <colinclark> how so?
[16:28:22 CDT(-0500)] <Bosmon> Right now you have nothing hazardous in it so it is fine
[16:28:25 CDT(-0500)] <Bosmon> But this may not always be the case
[16:28:38 CDT(-0500)] <Bosmon> We should think whether we want this to be some kind of standard "grade" to help people
[16:28:54 CDT(-0500)] <Bosmon> But opens the wider issue of what we do about asynchrony in general
[16:29:17 CDT(-0500)] <Bosmon> Well, there could be a special grade for "deferredChildren" which has defaults of : {
[16:29:41 CDT(-0500)] <Bosmon> mergePolicy: "deferredComponents: noexpand",
[16:29:45 CDT(-0500)] <Bosmon> components: {
[16:29:52 CDT(-0500)]
<Bosmon> instantiator:
[16:29:53 CDT(-0500)] <Bosmon> }
[16:30:27 CDT(-0500)] <Bosmon> But I guess really this could be somewhat slicker
[16:30:56 CDT(-0500)] <colinclark> I guess we can't assume that deferredComponents have any common lifecycle
[16:31:30 CDT(-0500)] <colinclark> Even then, we should be able to hide this away from users a bit more
[16:31:45 CDT(-0500)] <colinclark> I mean, they don't really want an instantiator component, do they?
[16:31:55 CDT(-0500)] <colinclark> They just want the means to be able to init a dependent later in the game
[16:31:59 CDT(-0500)] <Bosmon> Yes
[16:32:26 CDT(-0500)] <Bosmon> So the slickness I was thinking of is that then, in conjunction with this "grade" there could be a utility which harmonises with it
[16:32:35 CDT(-0500)] <Bosmon> Which simply looks like fluid.initDeferredComponent(name)
[16:32:42 CDT(-0500)] <colinclark> yes
[16:32:47 CDT(-0500)] <colinclark> that would be excellent
[16:32:51 CDT(-0500)] <Bosmon> Sorry, fluid.initDeferredComponent(that, name)
[16:32:54 CDT(-0500)] <Bosmon>
[16:33:05 CDT(-0500)] <colinclark> I inferred the "that"
[16:33:05 CDT(-0500)] <Bosmon> the instantiator still needs to be THERE
[16:33:12 CDT(-0500)] <Bosmon> But the user would not be bothered with it...
[16:33:24 CDT(-0500)] <Bosmon> It would appear in the graded defaults, and would be fished out by the utility
[16:33:37 CDT(-0500)] <colinclark> I would love that
[16:33:46 CDT(-0500)] <colinclark> And it might have caused me to consider
[16:33:56 CDT(-0500)] <colinclark> "when do I need my various subcomponents?"
[16:33:58 CDT(-0500)] <colinclark> a bit more closely
[16:34:21 CDT(-0500)] <Bosmon> Well
[16:34:26 CDT(-0500)] <Bosmon> We could do EVEN BETTER than this
[16:35:07 CDT(-0500)] <Bosmon> We could simply attach an "onEvent" annotation to the deferredComponent's record
[16:35:29 CDT(-0500)] <Bosmon> Which would indicate that its construction should be automatically attached to the firing of a particular event
[16:35:38 CDT(-0500)] <Bosmon> This would pave the way to solving the problem in a more general way also
[16:35:59 CDT(-0500)] <Bosmon> For example, in the case of rendering, where the SAME dependent would actually need to be created multiple times
[16:38:14 CDT(-0500)] <colinclark> we have it working and the tests passing now, which is now
[16:38:16 CDT(-0500)] <colinclark> nice
[16:38:17 CDT(-0500)] <colinclark> now
[16:38:19 CDT(-0500)] <colinclark> whatever
[16:38:24 CDT(-0500)] <colinclark> I might head home shortly
[16:38:25 CDT(-0500)] <Bosmon> Well, the framework is at a point where new facilities like this are very easy to implement
[16:38:27 CDT(-0500)] <colinclark> Darcie's got a bad tooth
[16:38:33 CDT(-0500)] <colinclark> cool
[16:38:39 CDT(-0500)] <colinclark> It's too bad you weren't here
[16:38:43 CDT(-0500)] <colinclark> we could implement it together
[16:38:50 CDT(-0500)] <Bosmon> Yes, it would be mega-cool
[16:38:56 CDT(-0500)] <colinclark> I think Fish's tour through IoC today was good
[16:39:02 CDT(-0500)] <Bosmon> Sorry about the tooth - hope it will be ok
[16:39:09 CDT(-0500)] <Bosmon> I hope she wasn't too traumatised by her debugging experience
[16:39:32 CDT(-0500)] <Bosmon> I think we can put in some better diagnostics for that case too
[16:39:44 CDT(-0500)] <Bosmon> The "instantiator" now allows us to be much more clear about the reasons why things aren't found
[16:40:02 CDT(-0500)] <colinclark> I don't think she was too traumatized
[16:40:08 CDT(-0500)] <colinclark> it was a tough one to debug
[16:40:16 CDT(-0500)] <colinclark> Like most synchrony issues
[16:40:20 CDT(-0500)] <colinclark> it superficially
[16:40:23 CDT(-0500)] <colinclark> "just didn't make sense"
[16:40:37 CDT(-0500)] <Bosmon> Right
[16:40:45 CDT(-0500)] <colinclark> We only went as deep as expandLight()
[16:40:52 CDT(-0500)] <Bosmon> It's one of the crucial reasons why doing things like calling "initDependents" should appear in user code
[16:40:53 CDT(-0500)] <colinclark> next time, she'll get a more in-depth tour
[16:41:02 CDT(-0500)] <colinclark> yes
[16:41:08 CDT(-0500)] <Bosmon> It should never be possible for it to be called "at the wrong time"
[16:41:37 CDT(-0500)] <Bosmon> This is just a sample of the horrid things that could happen should users do "unusual things" during their component construction workflow
[16:41:51 CDT(-0500)] <Bosmon> And why we really don't want them to be writing their own creator functions
[16:50:13 CDT(-0500)] <colinclark> Bosmon: It looks like there is that extra bit of code I was referring to
[16:50:16 CDT(-0500)] <colinclark> that.options.components.uploaderContext = that.options.deferredComponents.uploaderContext;
[16:50:28 CDT(-0500)] <colinclark> Since initDependent() assumes the dependent will actually live in the components block
[16:50:45 CDT(-0500)] <colinclark> so this will be a line of code I can remove soon