fluid-work IRC Logs-2011-03-21

[08:54:38 CDT(-0500)] <heidi_> Justin_o what do you think of using the !important there? I feel like it's a case where it makes sense to use.
[08:55:10 CDT(-0500)] <Justin_o> heidi_: for linearize?
[08:55:15 CDT(-0500)] <heidi_> yep
[08:55:25 CDT(-0500)] <Justin_o> i'm sort of wondering if we'll have to use it for all of the properties?
[08:55:36 CDT(-0500)] <Justin_o> what do you think?
[08:56:18 CDT(-0500)] <heidi_> Justin_o yeah maybe... will have to test. this is tricky.
[08:56:42 CDT(-0500)] <heidi_> also for aligning... think it'd be like fl-layout-linear fl-layout-linear-left ? or something?
[08:57:10 CDT(-0500)] <heidi_> if it's best practice to align one way maybe the default fl-layout-linear should align
[08:58:29 CDT(-0500)] <Justin_o> heidi_: would we then have a no-align option
[08:58:33 CDT(-0500)] <Justin_o> ?
[08:59:33 CDT(-0500)] <heidi_> Justin_o i don't think we should support no-align since it'd be hard to look at. someone could over-ride that if need be, but we should include best practices... so maybe default left but also include centre and right
[09:14:17 CDT(-0500)] <Justin_o> heidi_: so i guess what you are saying is that we should supported mixed alignment
[09:22:07 CDT(-0500)] <heidi_> Justin_o yeah for sure (cos of RTL langs) and not support no-alignment
[09:26:28 CDT(-0500)] <Justin_o> heidi_: sorry.. i just realized that i miss worded that... i meant to say we shouldn't support a mixed alignment... we should only support either left, right, or centre
[09:27:00 CDT(-0500)] <heidi_> Justin_o yeah, is centre useful to anyone?
[09:28:49 CDT(-0500)] <Justin_o> heidi_: okay.. so i was trying to think if a mixed layout would be useful, and i think i just thought of it
[09:29:03 CDT(-0500)] <Justin_o> so you might want to have headings centred, with the content justified to the left or right
[09:29:30 CDT(-0500)] <heidi_> hmm
[09:37:15 CDT(-0500)] <Justin_o> jameswy: heidi_ and I were talking about linearization options... what do you think about supporting mixed alignments... so the one case i could think of is where you might want to have the headings centred and the content justified to either left or right
[09:37:43 CDT(-0500)] <jameswy> Justin_o, heidi_: Sounds sensible to me.
[09:37:49 CDT(-0500)] <heidi_> Justin_o if jameswy can see that being valuable, sure
[09:38:08 CDT(-0500)] * jameswy sticks up a thumb.
[09:38:29 CDT(-0500)] <heidi_> the parent could have the fl-layout-linear and the chunks you want aligned can have fl-layout-linear-left etc ?
[09:38:51 CDT(-0500)] <heidi_> what about default (i.e. no alignment styles used)... should fl-layout-linear align left say?
[09:41:24 CDT(-0500)] <Justin_o> heidi_: not sure if this is exactly what you're saying, but we'd have something like fl-layout-linear, which would linearize but not change the alignment, then the user could just add the fl-text-align classes to align the items where they want them
[09:41:32 CDT(-0500)] <Justin_o> is that about right?
[09:41:46 CDT(-0500)] <heidi_> ah yes, yep that works
[09:43:45 CDT(-0500)] <Justin_o> heidi_: cool...
[09:44:05 CDT(-0500)] <Justin_o> i guess that doesn't affect whether we will need the !importants or not though eh
[09:45:05 CDT(-0500)] <heidi_> Justin_o just trying to think how they could be bad to have...
[09:45:18 CDT(-0500)] <Justin_o> ah okay
[09:45:50 CDT(-0500)] <heidi_> Justin_o bad if the user wants to override any of them, but not sure why they'd want to both linearize and say float
[09:46:09 CDT(-0500)] <heidi_> could just move the class to the section you want if so
[09:46:44 CDT(-0500)] <heidi_> Justin_o the one extra thing to figure out is the width of the columns - should they be 100% or stay the width they're set to be? i'm thinking the latter
[09:56:09 CDT(-0500)] <Justin_o> heidi_: so just make them all block elements instead
[09:56:16 CDT(-0500)] <Justin_o> and leave their width as whatever
[09:56:20 CDT(-0500)] <heidi_> yep
[09:56:45 CDT(-0500)] <Justin_o> i guess on a mobile device it would be better to have them be 100%,
[09:56:46 CDT(-0500)] <Justin_o> {color}
[09:57:10 CDT(-0500)] <heidi_> Justin_o that could be an extra style, not-default
[09:57:14 CDT(-0500)] <heidi_> in mfss ?
[09:57:19 CDT(-0500)] <Justin_o> i'm wondering how it would look to have 4 stacked columns that 25% on top of each other in a desktop page
[09:58:55 CDT(-0500)] <heidi_> Justin_o i'm picturing that the content of the columns is prob narrow (menus etc) so making the width 100% won't do anything that helpful ... just disorient
[09:59:44 CDT(-0500)] <heidi_> maybe that's too big an assumption but i think regardless it'd still be disorienting. and we could have another style that's like fl-layout-linear-fullwidth or something
[10:02:53 CDT(-0500)] <Justin_o> heidi_: maybe we should do the opposite
[10:03:00 CDT(-0500)] <Justin_o> so have a new option that keeps the width
[10:03:08 CDT(-0500)] <Justin_o> to preserve backwards compatability
[10:03:59 CDT(-0500)] <heidi_> Justin_o yeah good point
[10:04:35 CDT(-0500)] <heidi_> yeah right now it's width:100% !important;
[10:05:31 CDT(-0500)] <Justin_o> heidi_: okay... and we want to try to drop the 100% if possible?
[10:05:36 CDT(-0500)] <Justin_o> sorry.. the !importatn
[10:05:56 CDT(-0500)] <heidi_> Justin_o well you were just suggesting we keep it for default
[10:06:02 CDT(-0500)] <heidi_> for backwards compat
[10:06:39 CDT(-0500)] <Justin_o> sorry.. i mean.. the !important part in particular.. i think we should keep 100% that was a type-o
[10:07:02 CDT(-0500)] <Justin_o> but were you saying we might be able to keep the importants for the linearization.. since it may not make sense to override
[10:07:17 CDT(-0500)] <Justin_o> i guess except for the other option we will provide where the widths will not be changed
[10:07:23 CDT(-0500)] <Justin_o> am i just confusing things
[10:07:35 CDT(-0500)] <Justin_o> i feel a little monday morning fog in my head
[10:07:54 CDT(-0500)] <heidi_> hehe... yeah the importants are tricky, but i think necessary. the width style maybe doesn't have to be tho
[10:09:37 CDT(-0500)] <heidi_> actually yeah it'd need an important too
[10:12:06 CDT(-0500)] <Justin_o> heidi_: thanks.. i think i've got it all now
[10:14:06 CDT(-0500)] <heidi_> Justin_o the 100% width is adding a ton of scrollbars on my test page..hm
[10:14:23 CDT(-0500)] <Justin_o> heidi_: really. something to do with margins or padding ?
[10:15:22 CDT(-0500)] <heidi_> yeah something's up... hm
[10:15:42 CDT(-0500)] <heidi_> we're setting left/right margin to 0... and removing padding doesn't seem right
[10:17:59 CDT(-0500)] <Justin_o> heidi_: hmm
[10:28:23 CDT(-0500)] <jamon> anastasiac: seems like i can do a reinstall with the same database credentials and that might work
[10:28:30 CDT(-0500)] <jamon> will try after standup
[10:45:42 CDT(-0500)] <jamon> anastasiac: http://docs.fluidproject.org/mediawiki/index.php
[10:46:43 CDT(-0500)] <anastasiac> jamon: yay! thanks
[10:47:26 CDT(-0500)] <jamon> anastasiac: our version is 1.16.2, i think that's what you had downloaded? i'll try it again
[10:48:18 CDT(-0500)] <anastasiac> I downloaded the extension version that goes with 1.16.x, which seemed to be 1.4 according to the PHP file, jamon, but I see that mediawiki.org is using 1.3...
[10:49:10 CDT(-0500)] <jamon> anastasiac: works! http://docs.fluidproject.org/mediawiki/index.php/Under_the_Hood
[10:49:14 CDT(-0500)] <jamon> see the source of that page
[10:49:40 CDT(-0500)] <anastasiac> yay!
[10:49:45 CDT(-0500)] <anastasiac> thanks so much, jamon!
[10:49:59 CDT(-0500)] <jamon> i like tracking these things down
[11:48:29 CDT(-0500)] <colinclark> Hey mlam
[11:48:36 CDT(-0500)] <mlam> hi colinclark
[11:48:40 CDT(-0500)] <colinclark> Just checking in about Uploader
[11:48:46 CDT(-0500)] <colinclark> I wasn't fully clear from your email...
[11:48:53 CDT(-0500)] <mlam> Oh ok.
[11:48:57 CDT(-0500)] <colinclark> Antranig's latest changes, from last night...
[11:49:01 CDT(-0500)] <colinclark> Do they still crash in IE?
[11:49:20 CDT(-0500)] <mlam> The uploader changes seem to have broken the HTML5 strategy with the image gallery.
[11:49:27 CDT(-0500)] <colinclark> ok
[11:49:32 CDT(-0500)] <colinclark> Are you making any progress on that?
[11:49:33 CDT(-0500)] <mlam> Yes , it's still broken in IE
[11:49:37 CDT(-0500)] <colinclark> ok
[11:49:43 CDT(-0500)] <mlam> I'm working on it, colinclark
[11:49:50 CDT(-0500)] <colinclark> Ok
[11:49:56 CDT(-0500)] <colinclark> Let me know if you want me to take a look at it
[11:50:11 CDT(-0500)] <mlam> The Uploader.html template was rendering, but not fully on Friday, but it's refusing to render at all at the moment
[11:50:22 CDT(-0500)] <mlam> In IE8 ^^
[11:50:28 CDT(-0500)] <colinclark> ok
[11:52:39 CDT(-0500)] <mlam> Something really strange is happening with events in the HTML5 strategy. Firebug keeps complaining about that.events.afterReady.fire() to not be a function. <-- it shouldn't matter if there's a listener for it or not.
[11:53:33 CDT(-0500)] <mlam> There's also an issue with losing the reference to the currentBatch of the file queue.
[11:55:08 CDT(-0500)] <colinclark> Sounds like the HTML5 strategy isn't getting its events properly from the Uploader via IoC
[11:55:15 CDT(-0500)] <colinclark> losing the reference how?
[11:56:40 CDT(-0500)] <Justin_o> fluid-everyone: we will need to update jquery ui and probably jquery itself for 1.4... since the version of jquery ui we use doesn't support drag and drop http://forum.jquery.com/topic/jquery-ui-does-not-work-on-ie9
[11:57:10 CDT(-0500)] <mlam> From debugging, I see that the the afterReady event is definitely available in the event options from IoC.
[11:58:05 CDT(-0500)] <colinclark> Does it have a fire property, and is it a function?
[11:59:30 CDT(-0500)] <mlam> Shouldn't all events have a fire property? No, there's no listener defined for the afterReady event
[12:01:37 CDT(-0500)] <mlam> It seems like once the remote component gets resolved, the state of the queue doesn't change even after the queue's currentBatch gets instantiated which results in the currentBatch from always being undefined
[12:03:29 CDT(-0500)] <colinclark> mlam: Yes, all events should have a fire() function, but the question is-if you're getting an error about fire() not being defined-does this have one it?
[12:04:04 CDT(-0500)] <colinclark> In other words, is the event somehow getting mangled as part of the process?
[12:08:26 CDT(-0500)] <mlam> colinclark: I'm not sure. How would I know if the event got mangled?
[12:09:09 CDT(-0500)] <colinclark> I'd start by checking to see if it has a fire property, which is a function, at the time when you're seeing this error
[12:11:55 CDT(-0500)] <colinclark> mlam: Okay, so it looks like the queue is not being expanded correctly when running in the Image Gallery
[12:12:24 CDT(-0500)] <colinclark> Stick a breakpoint at the top of the creator function for html5Strategy.remote()
[12:12:51 CDT(-0500)] <colinclark> You'll see that queue is still a blob of JSON--it hasn't been resolved to the actual queue
[12:13:15 CDT(-0500)] <colinclark> So the error we're getting at line 170, where we're referring to the batch, makes sense
[12:13:23 CDT(-0500)] <colinclark> there is no current batch, because we don't have a proper queue
[12:13:33 CDT(-0500)] <colinclark> Is that what you're seeing as well?
[12:13:51 CDT(-0500)] <mlam> yes, that's what i'm seeing
[12:14:12 CDT(-0500)] <mlam> so....why is it still a blob?
[12:14:43 CDT(-0500)] <mlam> that's prob the same for the events. the events are still a blob.
[12:15:02 CDT(-0500)] <mlam> none of the events passed in through IoC of the remote have fire() properties.
[12:15:59 CDT(-0500)] <colinclark> ok
[12:19:26 CDT(-0500)] <colinclark> So, for some reason, IoC is not resolving these things properly
[12:19:29 CDT(-0500)] <colinclark> I don't quite know why yet
[12:22:27 CDT(-0500)] <colinclark> There are some very helpful diagnostics being printed out
[12:22:32 CDT(-0500)] <colinclark> hopefully they contain some clues
[13:16:49 CDT(-0500)] <heidi_> Justin_o check out line 109 of fss-layout
[13:17:00 CDT(-0500)] <heidi_> should add to the list maybe
[14:20:02 CDT(-0500)] <heidi_> justin_o updating the fl-col stuff to fl-layout would be really tricky for preserving backwards compat
[14:20:38 CDT(-0500)] <Bosmon> mlam, colinclark - I am looking at the Uploader now
[14:20:47 CDT(-0500)] <Bosmon> Can you tell me where the "image gallery demo" is?
[14:20:54 CDT(-0500)] <colinclark> Bosmon: Hang on
[14:21:07 CDT(-0500)] <colinclark> Have you caught up on the channel discussion, first?
[14:21:18 CDT(-0500)] <Bosmon> Yes, I have
[14:21:20 CDT(-0500)] <mlam> Bosmon, yura_ is sitting here with me now and he's helped debug/ fix the HTML5 strategy
[14:21:21 CDT(-0500)] <colinclark> ok
[14:21:34 CDT(-0500)] <Bosmon> Ok, cool
[14:21:36 CDT(-0500)] <Bosmon> What state are you at now?
[14:22:05 CDT(-0500)] <Bosmon> So far I restored the demands block that I removed that stopped the "singleFileStrategy" working
[14:22:05 CDT(-0500)] <mlam> We're trying to figure out what's happening with the Flash version of hte uploader
[14:22:15 CDT(-0500)] <Bosmon> Although I'm still not convinced that that is working correctly
[14:22:16 CDT(-0500)] <Bosmon> Ok
[14:22:20 CDT(-0500)] <Bosmon> So the HTML 5 version is fine now?
[14:22:32 CDT(-0500)] <mlam> In the HTML5 version, the remote didn't have an argumentMap defined in the defaults
[14:22:40 CDT(-0500)] <Bosmon> Ok, cool
[14:22:54 CDT(-0500)] <Bosmon> That was a kind of problem I had to fix a few times to get the local part working
[14:23:03 CDT(-0500)] <Bosmon> The Flash stuff may well just be the same
[14:23:15 CDT(-0500)] <colinclark> These argument maps are unpleasant
[14:23:16 CDT(-0500)] <mlam> so that was pretty much it for that....but for flash, something is running recursively , and it's to the point that it's crashing our browser
[14:23:20 CDT(-0500)] <colinclark> why are they necessary, Bosmon?
[14:23:31 CDT(-0500)] <Bosmon> They are necessary so that IoC can tell which argument holds the options
[14:23:52 CDT(-0500)] <Bosmon> Unless it knows that, it is impossible for merge policies to be applied correctly
[14:23:54 CDT(-0500)] <mlam> and because the browser keeps crashing, we're unable to debug.
[14:24:05 CDT(-0500)] <Bosmon> Oh dear
[14:26:32 CDT(-0500)] <colinclark> Bosmon: So in what cases does a developer need to specify an argument map?
[14:26:35 CDT(-0500)] <colinclark> Certain grades?
[14:28:28 CDT(-0500)] <Bosmon> They need to specify an argument map if they have put the "options" argument in a place which is incompatible with the grade they have chosen
[14:28:35 CDT(-0500)] <colinclark> okay
[14:28:37 CDT(-0500)] <colinclark> So, for example
[14:28:43 CDT(-0500)] <colinclark> in the case of a little component, like here
[14:28:49 CDT(-0500)] <colinclark> the options argument is at index 1
[14:28:54 CDT(-0500)] <colinclark> instead of the conventional index 0
[14:28:57 CDT(-0500)] <colinclark> is that right?
[14:29:00 CDT(-0500)] <Bosmon> That's right
[14:29:28 CDT(-0500)] <colinclark> okay, i can dig that
[14:29:32 CDT(-0500)] <colinclark> can i ask another question?
[14:30:06 CDT(-0500)] <Bosmon> Go for it
[14:30:10 CDT(-0500)] <colinclark> Talk me through the code at lines 319-332
[14:30:19 CDT(-0500)] <colinclark> More of this deferredOptions hoop-jumping
[14:30:55 CDT(-0500)] <Bosmon> That is all gone
[14:30:59 CDT(-0500)] <Bosmon> Have you updated to recent trunk?
[14:31:24 CDT(-0500)] <colinclark> hmm
[14:31:26 CDT(-0500)] <colinclark> I thought I had
[14:32:19 CDT(-0500)] <colinclark> ah, great
[14:32:25 CDT(-0500)] <colinclark> yes, i was looking at the wrong repo
[14:32:34 CDT(-0500)] <colinclark> i had looked in on your changes in github
[14:32:43 CDT(-0500)] <colinclark> in the web ui
[14:32:54 CDT(-0500)] <colinclark> and then pulled them into another clone on my system
[14:33:04 CDT(-0500)] <colinclark> and was surprised to see this code again
[14:33:06 CDT(-0500)] <colinclark> duh
[14:34:18 CDT(-0500)] <Bosmon> So, I guess we are today so far debugging the Flash 10 version of IE?
[14:34:32 CDT(-0500)] <colinclark> mlam and yura_: Have you guys already added argumentMap definitions for the Flash strategy?
[14:34:46 CDT(-0500)] <mlam> No, we haven't yet.
[14:34:55 CDT(-0500)] <colinclark> You might try that first
[14:34:59 CDT(-0500)] <colinclark> It needs to be done anyway
[14:35:01 CDT(-0500)] <colinclark> simplify things
[14:35:08 CDT(-0500)] <mlam> right
[14:35:24 CDT(-0500)] <colinclark> there are a few objects that have unconventional arguments
[14:35:34 CDT(-0500)] <colinclark> I like that expression
[14:35:43 CDT(-0500)] <Bosmon>
[14:36:17 CDT(-0500)] <colinclark> Bosmon: Another quick question, while I've got you
[14:36:36 CDT(-0500)] <colinclark> You made a change to the scrollable component
[14:36:42 CDT(-0500)] <colinclark> One which was related to something I struggled with a bit
[14:37:05 CDT(-0500)] <colinclark> It's one of the those components that doesn't quite fit the mould
[14:37:21 CDT(-0500)] <colinclark> Since its main job is to take an element and wrap it in some stuff
[14:37:33 CDT(-0500)] <colinclark> As a result, its "container" isn't really much of a container
[14:37:39 CDT(-0500)] <colinclark> nor does it have a workable DOM Binder
[14:38:08 CDT(-0500)] <Bosmon> Ok
[14:38:11 CDT(-0500)] <colinclark> I chose, for that reason, to just make it a littleComponent and use fluid.container() manually, simply to verify that there was only one of its main argument, "element"
[14:38:16 CDT(-0500)] <Bosmon> it seems I am slightly luckier in my configuration
[14:38:24 CDT(-0500)] <Bosmon> I get an infinite recursion but it does not destroy the browser
[14:38:27 CDT(-0500)] <colinclark> Bosmon: Lucky you
[14:38:37 CDT(-0500)] <Bosmon> So I have been able to break into the loop to see what is up... I'll let you know what I find
[14:39:09 CDT(-0500)] <Bosmon> colinclark - doesn't a standard view component do that too?
[14:42:03 CDT(-0500)] <Bosmon> Ok, so it is stuck in a loop repeatedly implementing swfUploadStrategy.local and swfUploadStrategy.engine
[14:42:10 CDT(-0500)] <Bosmon> Currently not sure WHY
[14:42:29 CDT(-0500)] <Bosmon> As soon as it has finished doing the "eventBinder" of engine, it immediately starts again at local
[14:43:56 CDT(-0500)] <Bosmon> In the instantiator, "engine" and also "flash.10" are having their ids constantly increment
[14:44:06 CDT(-0500)] <Bosmon> The latter of which is extremely strange
[14:44:10 CDT(-0500)] <Bosmon> Everything else is staying fixed
[14:44:42 CDT(-0500)] <Bosmon> It never actually seems to succeed in instantiating "local"
[14:45:04 CDT(-0500)] <Bosmon> Ah, it is a "true recursion".... the call stack is growing indefinitely
[14:46:39 CDT(-0500)] <Bosmon> "engine" and "flash.10" actually seem to come and go
[14:46:42 CDT(-0500)] <Bosmon> Which should be impossible
[14:47:28 CDT(-0500)] <colinclark> mlam: I'd say make a pull request with all the argumentMaps added wherever needed
[14:47:47 CDT(-0500)] <colinclark> Bosmon can push that change the project repo soon
[14:47:52 CDT(-0500)] <Bosmon> Well, if it fixes the problem, it would almost be a loss
[14:48:00 CDT(-0500)] <colinclark> I'm sure it won't
[14:48:06 CDT(-0500)] <Bosmon> We need to ensure that this kind of behaviour by the framework is completely impossible
[14:48:10 CDT(-0500)] <colinclark> it's just necessary for working nightlies on, say, any browser
[14:48:11 CDT(-0500)] <Bosmon> No matter what people do with their argumentMaps
[14:48:26 CDT(-0500)] <Bosmon> ok
[14:48:49 CDT(-0500)] <Bosmon> What do you mean by "any browser"?
[14:48:56 CDT(-0500)] <Bosmon> Isn't the code now working on everything except IE?
[14:49:10 CDT(-0500)] <colinclark> No
[14:49:20 CDT(-0500)] <colinclark> "Everything except IE in demo mode"
[14:55:34 CDT(-0500)] <Bosmon> Ok
[14:55:44 CDT(-0500)] <Bosmon> So it has instantiated 25 SWFUpload "engines"
[14:55:56 CDT(-0500)] <Bosmon> I guess it never actually completely finishes... it gets put into the instantiator map
[14:56:03 CDT(-0500)] <Bosmon> But I guess so far has never been delivered to its parent component
[14:56:14 CDT(-0500)] <Bosmon> Which explains why it is "sometimes seen" and sometimes not
[14:56:36 CDT(-0500)] <colinclark> Wow
[14:56:46 CDT(-0500)] <colinclark> The last thing the world needs is SWFUpload instances
[14:57:12 CDT(-0500)] <Bosmon> creator function swfUploadStrategy.engine has never yet returned...
[14:58:53 CDT(-0500)] <Bosmon> Oh interesting
[14:58:57 CDT(-0500)] <Bosmon> Looks like one of the invokers is involved
[14:59:32 CDT(-0500)] <Bosmon> The eventBinder
[15:03:29 CDT(-0500)] <mlam> colinclark: sorry , was just trying a few things out here. i'll make the pull request for the HTML5 fix soon.
[15:03:38 CDT(-0500)] <colinclark> no worries
[15:03:48 CDT(-0500)] <colinclark> don't let me distract you from trying interesting things out
[15:04:04 CDT(-0500)] <mlam> Bosmon: how did you manage to break into the infinite loop??
[15:06:02 CDT(-0500)] <Bosmon> I guess I am just "lucky"
[15:06:05 CDT(-0500)] <Bosmon> On my system
[15:06:11 CDT(-0500)] <Bosmon> I mean, who knows why IE decides to crash
[15:06:21 CDT(-0500)] <Bosmon> I think the fact that it fills its console log so slowly gave me a chance to break into it
[15:09:08 CDT(-0500)] <mlam> We turned off all the progressive enhancement code so that SWFUpload is always running so we can better debug in FF and it still managed to crash the browser.
[15:13:13 CDT(-0500)] <Bosmon> Ok
[15:13:16 CDT(-0500)] <Bosmon> I have found the issue
[15:13:32 CDT(-0500)] <Bosmon> Although not yet quite the reason why the framework does not catch it
[15:13:41 CDT(-0500)] <mlam> What's the issue?
[15:13:47 CDT(-0500)] <Bosmon> There are mutually recursive references between swfupload engine, and local
[15:14:01 CDT(-0500)]

[15:14:22 CDT(-0500)]

<Bosmon> Correspondingly, "engine" declares an invoker named eventBinder, which makes a demand of its own for

Unknown macro: {swfUpload}

.local

[15:14:23 CDT(-0500)] <mlam> right
[15:14:44 CDT(-0500)] <Bosmon> What SHOULD happen is that the framework should halt instantly
[15:14:57 CDT(-0500)] <Bosmon> And inform you of the mutual recursion...
[15:15:18 CDT(-0500)] <Bosmon> But this looks like a case I have not yet caught
[15:18:07 CDT(-0500)] <Bosmon> Ok, so I will try to distill a test case out of this situation...
[15:18:53 CDT(-0500)] <mlam> Bosmon: so assuming the framework caught this, are you suggesting that the SWFUpload implementation needs refactoring?
[15:19:03 CDT(-0500)] <Bosmon> Yes, that's right
[15:19:21 CDT(-0500)] <Bosmon> Once I fix the framework, it will halt immediately in this case, warning you of the problem
[15:19:24 CDT(-0500)] <Justin_o> anastasiac: have you seen the confluence docs.. they have links at the bottom of the page http://confluence.atlassian.com/display/JIRA041/Single+Level+Group+By+Report
[15:19:33 CDT(-0500)] <Justin_o> that's an example
[15:19:33 CDT(-0500)] <Bosmon> This only ever worked before "by accident"
[15:20:20 CDT(-0500)] <anastasiac> Justin_o, thanks
[15:21:09 CDT(-0500)] <Bosmon> The implementation is pretty awful in any case.... there is no reason for the "eventBinder" to have a reference upstairs to the "local" component
[15:21:14 CDT(-0500)] <Bosmon> This should all be being done via events
[15:21:59 CDT(-0500)] <colinclark> Bosmon: That's correct
[15:22:19 CDT(-0500)] <colinclark> If I remember, I made a change like that to the HTML5Strategy
[15:22:31 CDT(-0500)] <colinclark> and at least made mental note that it needed to be done similarly in the Flash version
[15:22:44 CDT(-0500)] <colinclark> I should probably look again to see if there's enough overlap there now to get rid of some code
[15:23:02 CDT(-0500)] <colinclark> mlam or Bosmon: Either of you should feel free to go ahead and make that change
[15:24:40 CDT(-0500)] <justin_o_> fluid-everyone: for this interested, here's a pie chart of our issues by component http://issues.fluidproject.org/secure/ConfigureReport.jspa?atl_token=hLyns-VDmh&amp;projectOrFilterId=project-10001&amp;statistictype=components&amp;selectedProjectId=10001&amp;reportKey=com.atlassian.jira.plugin.system.reports%3Apie-report&amp;Next=Next
[15:24:53 CDT(-0500)] <Bosmon> It's pretty hilarious... of course, in the IE debugger, every stack frame except "resolveEnvironmentImpl" comes up as JScript anonymous function
[15:25:02 CDT(-0500)] <jessm> justin_o_: wow, cool
[15:25:15 CDT(-0500)] <Bosmon> So resolveEnvironmentImpl marks out the only visible point in the recursion
[15:25:24 CDT(-0500)] <Bosmon> Which, down one leg, takes 18 stack frames, and down the other, takes 23
[15:26:01 CDT(-0500)] <Bosmon> 41 stack frames for the complete recursion....
[15:26:20 CDT(-0500)] <anastasiac> Justin_o, interesting - can it be limited to unresolved issues only?
[15:26:21 CDT(-0500)] <colinclark> eek
[15:26:35 CDT(-0500)] <colinclark> Check out the big fat blue Uploader slice
[15:26:44 CDT(-0500)] <colinclark> I'm sure half of them are variants on "Flash sucks"
[15:27:23 CDT(-0500)] <Bosmon> That's incredible
[15:27:31 CDT(-0500)] <Bosmon> How could there possibly be 529 Uploader issues?
[15:28:07 CDT(-0500)] <colinclark> We should make it 530 by filing a ticket for the issue you're working on
[15:28:40 CDT(-0500)] <Bosmon> Wait
[15:28:49 CDT(-0500)] <Bosmon> This chart is not ignoring closed issues, Justin_o
[15:29:38 CDT(-0500)] <Justin_o> Bosmon, anastasiac i'll see if i can limit it
[15:32:28 CDT(-0500)] <justin_o_> Bosmon, anastasiac: couldn't see a quick way to do that, but here's the chart for resolution
[15:32:29 CDT(-0500)] <justin_o_> http://issues.fluidproject.org/secure/ConfigureReport.jspa?atl_token=hLyns-VDmh&amp;projectOrFilterId=project-10001&amp;statistictype=resolution&amp;selectedProjectId=10001&amp;reportKey=com.atlassian.jira.plugin.system.reports%3Apie-report&amp;Next=Next
[15:32:46 CDT(-0500)] <Justin_o> 192 duplicates
[15:33:08 CDT(-0500)] <Justin_o> thankfully the vast majority have been fixed
[15:33:36 CDT(-0500)] <mlam> A handful of JIRAs should be closed once the uploader's error handler goes in
[15:43:03 CDT(-0500)] <colinclark> anastasiac: Super excited about our doc sprint
[15:43:14 CDT(-0500)] <colinclark> I sent a response saying that I'd signed up for a few things--probably too many things
[15:43:26 CDT(-0500)] <anastasiac> excellent, colinclark!
[15:43:35 CDT(-0500)] <colinclark> I added one topic: "IoC: Why it's useful and how it helps"
[15:43:45 CDT(-0500)] <colinclark> Though, now that I look at the page, it sort of says
[15:43:51 CDT(-0500)] <colinclark> "IoC: Why it's useful and how it helps Colin"
[15:43:55 CDT(-0500)] <Bosmon>
[15:43:56 CDT(-0500)] <anastasiac> LOL
[15:43:57 CDT(-0500)] <colinclark> which is entirely opposite my point
[15:44:06 CDT(-0500)] <Bosmon> If it even helps one person, surely that is a start
[15:44:15 CDT(-0500)] <Bosmon> I doubt if it could help, if it didn't help Colin
[15:44:48 CDT(-0500)] <colinclark> So, I've signed up for Progressive Enhancement and the IoC doc
[15:45:03 CDT(-0500)] <colinclark> I unsigned myself from Model Transformation, just in case anyone else wants to take a stab at it
[15:45:07 CDT(-0500)] <justin_o_> fluid-everyone: I think we should switch to using this report instead of the bug parade e-mails
[15:45:08 CDT(-0500)] <justin_o_> http://issues.fluidproject.org/secure/ConfigureReport.jspa?atl_token=hLyns-VDmh&amp;filterid=10128&amp;mapper=components&amp;selectedProjectId=10001&amp;reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&amp;Next=Next
[15:45:09 CDT(-0500)] <colinclark> I can imagine Bosmon and I might want to collaborate on it
[15:45:16 CDT(-0500)] <colinclark> since it connects to Expanders as well
[15:45:23 CDT(-0500)] <justin_o_> it will be easier than trying to manage all of the updates
[15:45:26 CDT(-0500)] <colinclark> but others should feel free to take a stab at it
[15:45:28 CDT(-0500)] <Bosmon> Oh colinclark, btw, I wanted to surface one of the issues with IoC from before, was that I discovered that "progressiveEnhancement" was not creating a genuine component
[15:45:38 CDT(-0500)] <colinclark> anastasiac: I also strongly encouraged everyone to participate in the sprint
[15:45:39 CDT(-0500)] <michelled> justin_o_: sounds like a good plan to me
[15:45:44 CDT(-0500)] <colinclark> Hopefully that's subtle enough
[15:45:46 CDT(-0500)] <anastasiac> justin_o_, that looks great, it should certainly save you some effor!
[15:46:04 CDT(-0500)] <colinclark> justin_o_: This is wicked!
[15:46:07 CDT(-0500)] <mlam> Bosmon: could you push my HTML5 fix ? https://github.com/mlam/infusion/tree/FLUID-4154
[15:46:17 CDT(-0500)] <justin_o_> thanks all.. anastasiac i'll update the docs
[15:46:34 CDT(-0500)] <Bosmon> Thanks, mlam
[15:46:37 CDT(-0500)] <colinclark> Bosmon: okay, lay it on me
[15:46:46 CDT(-0500)] <colinclark> or once you've pushed mlam's fix
[15:47:05 CDT(-0500)] <colinclark> Bosmon: You'll be around to contribute to the sprint on Thurs./Fri.?
[15:47:09 CDT(-0500)] <mlam> Thanks Bosmon
[15:47:13 CDT(-0500)] <Bosmon> colinclark - so I guess there was some time at which it was considered desirable for progressiveEnhancement to be "framework free"?
[15:47:18 CDT(-0500)] <Bosmon> colinclark: yes, I'll be there
[15:47:21 CDT(-0500)] <colinclark> great
[15:47:32 CDT(-0500)] <colinclark> Well, I don't know if that was ever the case
[15:47:48 CDT(-0500)] <colinclark> I think perhaps I just actually just took your "everything is a component" argument too far
[15:47:50 CDT(-0500)] <Bosmon> It used to have a comment in it
[15:47:54 CDT(-0500)] <colinclark> ah
[15:47:55 CDT(-0500)] <colinclark> okay
[15:48:02 CDT(-0500)] <Bosmon> Saying "change this to fluid.each once this is merged with the framework"
[15:48:12 CDT(-0500)] <colinclark> wow, no
[15:48:14 CDT(-0500)] <Bosmon> So I was wondering whether that was related to the fact that it didn't call any component init function
[15:48:17 CDT(-0500)] <colinclark> fluid.makeArray()?
[15:48:20 CDT(-0500)] <colinclark> maybe?
[15:48:21 CDT(-0500)] <Bosmon> Oh yes
[15:48:24 CDT(-0500)] <Bosmon> fluid.makeArray
[15:48:33 CDT(-0500)] <colinclark> let me just look at the changes and remind myself what was there
[15:48:38 CDT(-0500)] <colinclark> I did indeed see your change
[15:49:05 CDT(-0500)] <Bosmon> Anyway.... there's a crucial issue now, that you just CAN'T get away without calling framework init, in the same way you can't get away without an argument map in the case of a mismatch
[15:49:18 CDT(-0500)] <Bosmon> It means that "general free functions" are no longer suitable things to appear in IoC trees
[15:49:31 CDT(-0500)] <Bosmon> Even if they return things that are components, they actually need to BE components too
[15:49:33 CDT(-0500)] <Bosmon> If you see what I mean
[15:49:40 CDT(-0500)] <colinclark> yes
[15:49:54 CDT(-0500)] <Bosmon> This is a classic instance of the kind of thing we were talking about last week... about "why we don't want people to write their own creator functions"
[15:50:00 CDT(-0500)] <colinclark> There was a time when you were arguing that anything with a typeTag was a component
[15:50:02 CDT(-0500)] <Bosmon> Since they might "do something else" when asked to construct a component
[15:50:22 CDT(-0500)] <Bosmon> Well, I still argue that
[15:50:33 CDT(-0500)] <colinclark> You might find a more nuanced way to do so
[15:50:52 CDT(-0500)] <Bosmon> But "not everything which returns a component, is a component"
[15:50:52 CDT(-0500)] <colinclark> I mean, if I look at this code and try to infer what its creator intended
[15:51:19 CDT(-0500)] <colinclark> it seems to me that this was assumed to just be "a function that does stuff"
[15:51:50 CDT(-0500)] <colinclark> but I guess it's really how it ended up being used in practice that is more interesting
[15:52:52 CDT(-0500)] <colinclark> So I guess the point here, Bosmon...
[15:53:03 CDT(-0500)] <colinclark> is that if we intend for something to be used within an IoC tree
[15:53:06 CDT(-0500)] <colinclark> make it a real component
[15:53:11 CDT(-0500)] <Bosmon> yes, that's right
[15:53:18 CDT(-0500)] <colinclark> In other words, declare its defaults
[15:53:19 CDT(-0500)] <Bosmon> It needn't RETURN a component
[15:53:21 CDT(-0500)] <colinclark> including a grade
[15:53:25 CDT(-0500)] <Bosmon> But it needs to INITIALISE like one
[15:53:33 CDT(-0500)] <colinclark> interesitng
[15:53:36 CDT(-0500)] <colinclark> so the return type doesn't matter
[15:53:47 CDT(-0500)] <colinclark> but, from the outside, it needs to look like a component
[15:53:49 CDT(-0500)] <Bosmon> Right
[15:53:55 CDT(-0500)] <colinclark> far out
[15:53:57 CDT(-0500)] <Bosmon> I am thinking of a declarative way to deal with return values too
[15:54:10 CDT(-0500)] <Bosmon> It should be possible for example to reduce "fluid.uploader" itself to become fully declarative
[15:54:50 CDT(-0500)] <Bosmon> It should be possible to define "input maps" and "output maps" explaining which of the things in "options" need to go onto the "that", and when finishing, what, if something other than "that" is returned, what it is
[15:56:11 CDT(-0500)] <Bosmon> It's fine for a creator function to return "null", or some different component
[15:56:24 CDT(-0500)] <Bosmon> In theory it's fine for it just to return a value too, so long as that is not something unexpected to its creator
[15:56:48 CDT(-0500)] <Bosmon> But it definitely needs to make a call to one of the framework init functions, like initLittleComponent or initView etc. with the expected arguments
[15:57:09 CDT(-0500)] <Bosmon> That is, arguments which reflect the argumentMap it has declared, and the correct name for the component
[15:57:15 CDT(-0500)] <colinclark> okay
[15:58:10 CDT(-0500)] <Bosmon> Also, related to this, there are particularly bad results if code in the creator function tries to look inside its "options" argument
[15:58:23 CDT(-0500)] <Bosmon> This is something that we recognised as a sort of "bad practice" but in the past we could generally get away with it
[15:58:44 CDT(-0500)] <Bosmon> Now, there is no longer any expectation that you will see anything intelligible when looking at "options"
[15:58:54 CDT(-0500)] <colinclark> yeah, it was always pretty bad practice
[15:59:01 CDT(-0500)] <Bosmon> The only use you should make of options is by looking at "that.options" after options merging has finished
[15:59:03 CDT(-0500)] <colinclark> I guess perhaps I've done it once or twice in wacky cases
[16:17:34 CDT(-0500)] <justin_o_> anastasiac: i've updated this page http://wiki.fluidproject.org/display/fluid/Release+Process+-+Bug+Parade
[16:17:44 CDT(-0500)] <justin_o_> with the changes for bug parade
[16:17:53 CDT(-0500)] <colinclark> michelled: You were asking about a bug in UIO
[16:17:54 CDT(-0500)] <justin_o_> and a bit about recruiting testers
[16:18:26 CDT(-0500)] <anastasiac> justin_o, thanks - looks good
[16:18:37 CDT(-0500)] <justin_o_> anastasiac: thanks
[16:18:50 CDT(-0500)] <michelled> yes, colinclark - basically when we rerender UI Options the preview disappears
[16:19:14 CDT(-0500)] <colinclark> right
[16:19:33 CDT(-0500)] <colinclark> I assume Preview's iFrame lives inside UIO's rendering container
[16:20:00 CDT(-0500)] <michelled> yep, that's correct
[16:20:22 CDT(-0500)] <colinclark> So, this is a case that justin_o_ and yura and Bosmon and I ran into quite a bit in Engage
[16:20:44 CDT(-0500)] <colinclark> That "refreshing" also involved having to zap all your subcomponents
[16:21:01 CDT(-0500)] <colinclark> At the time, we simply wrote all our refreshView() methods to do this zapping by hand
[16:21:15 CDT(-0500)] <colinclark> In other words, refreshView() would make the appropriate calls to initSubcomponent()
[16:21:31 CDT(-0500)] <Bosmon> Yes... now we have better options
[16:21:33 CDT(-0500)] <colinclark> Bosmon: Have you introduced any new techniques for this into the framework?
[16:21:35 CDT(-0500)] <colinclark> ah
[16:21:35 CDT(-0500)] <colinclark> good
[16:22:03 CDT(-0500)] <Bosmon> Although we need to decide off the bat whether we are going to represent all of these components as renderer decorators or as IoC subcomponents
[16:22:35 CDT(-0500)] <Bosmon> The two are converging now, but there are still some differences in style and affordances
[16:22:37 CDT(-0500)] <colinclark> I think in the case of UIO, two of them are obvious candidates for decorators
[16:22:47 CDT(-0500)] <colinclark> the text field sliders
[16:22:53 CDT(-0500)] <colinclark> the other one, Preview, I'm not so sure about
[16:23:02 CDT(-0500)] <Bosmon> Yes
[16:23:07 CDT(-0500)] <colinclark> I don't think we actually "do" anything with it
[16:23:11 CDT(-0500)] <colinclark> so it'd probably be fine as a decorator
[16:23:18 CDT(-0500)] <Bosmon> It is possible to move the preview out of the main markup somehow?
[16:23:30 CDT(-0500)] <colinclark> I think we probably could, yes
[16:23:36 CDT(-0500)] <colinclark> but what if we didn't?
[16:23:41 CDT(-0500)] <colinclark>
[16:23:43 CDT(-0500)] <Bosmon> Although this is exposing some interesting issues with the rendering idiom
[16:23:47 CDT(-0500)] <Bosmon> Yes, what if we didn't
[16:23:56 CDT(-0500)] <Bosmon> It is a prime example of a piece of material that is "irreplaceable"
[16:24:13 CDT(-0500)] <Bosmon> I guess, similar to things like Flash controls, and other weird pieces of junk
[16:24:27 CDT(-0500)] <colinclark> lol
[16:24:37 CDT(-0500)] <colinclark> space junk, floating in the DOM
[16:24:47 CDT(-0500)] <Bosmon> I am wondering whether we might need to make a special directive for "preserving" odd things like this
[16:24:55 CDT(-0500)] <colinclark> Flash is like a satellite from the sixties
[16:25:10 CDT(-0500)] <Bosmon> The only example of a kind of thing that we try to "preserve" right now, is, interestingly, the focused element
[16:25:32 CDT(-0500)] <colinclark> oh, right
[16:25:36 CDT(-0500)] <Bosmon> But similar to merge policies, of "preserve"....
[16:25:52 CDT(-0500)] <Bosmon> We might be able to nominate little "islands" of things that we try to keep
[16:25:52 CDT(-0500)] <colinclark> Can you back up for a sec
[16:25:56 CDT(-0500)] <colinclark> and let me ask a few questions?
[16:26:00 CDT(-0500)] <Bosmon> Clearly, depending on how "nasty" they are, we still may not succeed
[16:26:07 CDT(-0500)] <Bosmon> Perhaps a Flash control can't be preserved even if you try
[16:26:08 CDT(-0500)] <Bosmon> Sure
[16:26:39 CDT(-0500)] <colinclark> 1. What criteria should a developer use when deciding when something should be a renderer decorator vs. IoC subcomponents
[16:27:16 CDT(-0500)] <colinclark> 2. What techniques, today, do we have to handle this?
[16:28:40 CDT(-0500)] <Bosmon> I guess 1. basically comes down to an issue of... "Does the component, at startup and/or regularly replace by rendering the block of markup in which the subcomponent appears?"
[16:28:56 CDT(-0500)] <Bosmon> But actually there is not too much in it now
[16:28:58 CDT(-0500)] <colinclark> ok
[16:29:06 CDT(-0500)] <colinclark> so I guess the answer to #2 is pretty close to the answer for #1
[16:29:07 CDT(-0500)] <colinclark>
[16:29:07 CDT(-0500)] <Bosmon> 1. is hopefully a question that developers in the future will need not answer
[16:29:41 CDT(-0500)] <colinclark> I guess question #3, somewhat hilariously, is "What does Yura do?"
[16:30:00 CDT(-0500)] <Bosmon> The issues are close together, precisely because of the compactness of the structure we have for "renderer components" now
[16:30:24 CDT(-0500)] <Bosmon> Because you KNOW that any node hit by the renderer, must ALSO have an entry in the component's selectors and hence cutpoints structure, it is pretty easy to move a component from one role to the other
[16:30:45 CDT(-0500)] <Bosmon> Although there will always be oddities to paper over
[16:30:58 CDT(-0500)] <Bosmon> Right now the renderer is the only side on which there is a clear answer to what to do about multiplicity
[16:31:10 CDT(-0500)] <Bosmon> But hopefully we will fix that up on the other side too
[16:31:24 CDT(-0500)] <Bosmon> We were always planning to deal with this awkward issue of the asymmetry between inlineEdit and inlineEdits for example
[16:31:54 CDT(-0500)] <Bosmon> But now we can KNOW something has the grade of "view component", we can clearly detect someone trying to initialise something with a container that hits multiple elements.... and instead convert that to an initialisation of multiple components
[16:32:56 CDT(-0500)] <Bosmon> Btw I don't think we quite finished talking about your use of "element" in the progress component earlier?
[16:33:01 CDT(-0500)] <Bosmon> Which seems related to this issue
[16:34:48 CDT(-0500)] <michelled> can you back up a little? it's not obvious to me which I would choose - subcomponent or decorator - based on whether the markup gets rerendered
[16:34:54 CDT(-0500)] <colinclark> michelled: Seems to me there are two options that are the short path to a solution to the bug we're seeing...
[16:35:08 CDT(-0500)] <colinclark> 1. Make Preview a decorator
[16:35:14 CDT(-0500)] <colinclark> 2. Take preview's iFrame out of the rendering container
[16:35:30 CDT(-0500)] <colinclark> sorry, I didn't mean to distract from your question
[16:37:07 CDT(-0500)] <colinclark> Bosmon: michelled had a question ^
[16:39:19 CDT(-0500)] <colinclark> I guess we lost Bosmon
[16:40:03 CDT(-0500)] <colinclark> michelled: I think the answer was "if your parent component replaces a block of markup needed by your subcomponent on a regular basis, the subcomponent should be a decorator"
[16:40:43 CDT(-0500)] <michelled> interesting
[16:41:26 CDT(-0500)] <michelled> I kind of envisioned the framework knowing enough about component and subcomponents that it could trigger rerendering for subcomponents automatically
[16:41:38 CDT(-0500)] <michelled> but I suppose that's the whole point of decorators
[16:41:45 CDT(-0500)] <colinclark> I think so, yes
[16:41:53 CDT(-0500)] <michelled> colinclark: do you prefer your option 1 or option 2 above?
[16:42:01 CDT(-0500)] <colinclark> especially now that they are IoC-resolved as well
[16:42:05 CDT(-0500)] <colinclark> Hmm
[16:42:12 CDT(-0500)] <colinclark> I prefer #2 if it's straightforward
[16:42:24 CDT(-0500)] <michelled> you type a lot faster then me
[16:42:29 CDT(-0500)] <michelled> I was going to say 2
[16:43:18 CDT(-0500)] <michelled> do we have a pattern established for DOM bound things not in our container?
[16:43:57 CDT(-0500)] <colinclark> We shouldn't need to take it out of UIO's container
[16:44:04 CDT(-0500)] <colinclark> just outside of the container we render into
[16:44:25 CDT(-0500)] <colinclark> So I can imagine we might introduce a "controls" selector
[16:44:35 CDT(-0500)] <colinclark> and use it as the container into which we render
[16:44:49 CDT(-0500)] <colinclark> Right now we render into that.container
[16:45:03 CDT(-0500)] <michelled> ah, so we only render part of UIO, is that what you're saying?
[16:45:06 CDT(-0500)] <michelled> it makes sense
[16:45:07 CDT(-0500)] <colinclark> which is basically saying "everything inside UIO is transient"
[16:45:08 CDT(-0500)] <colinclark> yes
[16:45:23 CDT(-0500)] <colinclark> Easy enough to do, and a pretty common technique for components
[16:45:43 CDT(-0500)] <michelled> I like it - thanks for talking this through
[16:46:03 CDT(-0500)] <colinclark> no problem
[16:47:03 CDT(-0500)] <Bosmon> Hi , just popped away for a moment
[16:47:38 CDT(-0500)] <colinclark> no worries
[16:47:47 CDT(-0500)] <Bosmon> michelled - yes, the framework could indeed trigger re-rendering in that case
[16:48:05 CDT(-0500)] <Bosmon> I guess right now it is decorators that have the most functionality, but we will gradually close up the gap
[16:48:35 CDT(-0500)] <michelled> ah, good to know
[16:49:02 CDT(-0500)] <Bosmon> I guess there are a few things to say on both sides
[16:49:13 CDT(-0500)] <Bosmon> It is somewhat easier to write a demands block for something that is a subcomponent
[16:49:23 CDT(-0500)] <Bosmon> That is, you have the choice of hitting that INDIVIDUAL subcomponent
[16:49:30 CDT(-0500)] <Bosmon> Whereas if it is a decorator, you can only hit it by type
[16:49:40 CDT(-0500)] <Bosmon> But you may not often need to write demands blocks of that kind
[16:50:14 CDT(-0500)] <Bosmon> I imagine subcomponents are a somewhat more readable form than decorators
[16:50:21 CDT(-0500)] <Bosmon> Which is why we will try to increase their capabilities over time
[16:50:27 CDT(-0500)] <Bosmon> Which would you like to use?
[16:52:08 CDT(-0500)] <colinclark> I prefer subcomponents, I think
[16:52:23 CDT(-0500)] <colinclark> They are indeed more readable
[16:52:31 CDT(-0500)] <colinclark> I guess I'm trying to think through cases of change...
[16:52:58 CDT(-0500)] <colinclark> Now that Renderer trees are pretty well fully declarative, we can imagine that they are options for a component that might be replaced with alternatives
[16:53:35 CDT(-0500)] <colinclark> I guess for most large-scale changes in UI, you'll have to modify the template, the tree, and probably the cutpoints of a component
[16:53:56 CDT(-0500)] <Bosmon> One other upcoming framework feature is "freeing up" our collection of things that we use to define top-level elements
[16:54:04 CDT(-0500)] <Bosmon> Right now we have components:, options: and invokers:
[16:54:17 CDT(-0500)] <colinclark> right
[16:54:39 CDT(-0500)] <Bosmon> One thing we might want to do is to allow this collection to become "free", in order to make it easier for people to group together things by functional type
[16:54:47 CDT(-0500)] <Bosmon> For example, in this case of "change"
[16:54:55 CDT(-0500)] <Bosmon> A thing that might help is a special area called "rendererComponents"
[16:55:13 CDT(-0500)] <Bosmon> so that people could group this together with the "renderer tree" as part of the "things you might want to replace if you are adapting this component"
[18:12:12 CDT(-0500)] <colinclark> Bosmon: A few Uploader questions for you...
[18:12:16 CDT(-0500)] <Bosmon> Hi
[18:12:19 CDT(-0500)] <colinclark> 1. How'd it go with the infinite recursion issue?
[18:12:33 CDT(-0500)] <Bosmon> I found the cause, and I will now work it up into a framework test case
[18:12:35 CDT(-0500)] <colinclark> 2. Did you and mlam decide who would do some refactoring of the event binder for the flash strategy?
[18:12:45 CDT(-0500)] <Bosmon> We didn't decide who would do it, no
[18:12:55 CDT(-0500)] <colinclark> 3. Were you able to review and push mlam's recent pull request?
[18:13:02 CDT(-0500)] <Bosmon> I didn't
[18:13:05 CDT(-0500)] <colinclark> ok
[18:13:09 CDT(-0500)] <Bosmon> But will do all these things once I get back from YOGGA
[18:13:18 CDT(-0500)] <colinclark> Thanks so much
[18:13:25 CDT(-0500)] <colinclark> I'm sorry to lean on you so much with Uploader
[18:13:29 CDT(-0500)] <colinclark> it's good to have more eyes on it
[18:13:41 CDT(-0500)] <Bosmon> it's fine, I bear responsibility since I destabilised it so badly
[18:13:41 CDT(-0500)] <colinclark> I'm excited about mlam working on it regularly
[18:13:53 CDT(-0500)] <colinclark> and think he probably benefits from more people looking at his code, etc.
[18:13:59 CDT(-0500)] <Bosmon> And all of these are important grounds where we can make the framework better
[18:14:03 CDT(-0500)] <colinclark> cool
[18:14:08 CDT(-0500)] <colinclark> I'm also feeling some pressure for UIO
[18:14:18 CDT(-0500)] <Bosmon> ok, shall we have a meeting on that tomorrow?
[18:14:23 CDT(-0500)] <colinclark> I'd love to
[18:14:32 CDT(-0500)] <colinclark> I'm sort of figuring I may be pretty out of it for the next few days
[18:14:39 CDT(-0500)] <colinclark> I'm hanging in, but not feeling awesome with this cold
[18:14:47 CDT(-0500)] <colinclark> skipped my sailing class tonight, which says a lot
[18:14:53 CDT(-0500)] <Bosmon> Oh dear, that really is bad
[18:14:56 CDT(-0500)] <Bosmon> You should rest up
[18:16:46 CDT(-0500)] <Bosmon> I'm sorry