fluid-work IRC Logs-2013-04-25

[08:17:32 CDT(-0500)] <Justin_o> heidiv: good morning… is FLUID-4971 ready for me to continue code review on?

[08:17:43 CDT(-0500)] <heidiv> Justin_o yep!

[08:17:49 CDT(-0500)] <heidiv> and morning

[08:18:03 CDT(-0500)] <Justin_o> cindyli: how's everything going with FLUID-4927, i was looking through the pull request comments

[08:18:35 CDT(-0500)] <cindyli> thanks, Justin_o, trying to figure out how to implement bosman's last comment

[08:18:43 CDT(-0500)] <cindyli> "To simply the work for now, you could just supply the extra grade to pageEnhancer as an option, and leave it as being manual init"

[08:19:41 CDT(-0500)]

[08:46:26 CDT(-0500)] <Justin_o> cindyli: did you want to talk through it on skype?

[08:47:33 CDT(-0500)] <cindyli> Justin_o: i'm about to finish up the implementation but it certainly needs feedbacks from your guys

[08:47:43 CDT(-0500)] <Justin_o> cindyli: cool

[08:47:55 CDT(-0500)] <cindyli> about to push up, will let u know

[08:56:54 CDT(-0500)] <cindyli> the implementation has been pushed up - https://github.com/cindyli/infusion/commit/61324401709e4b81e764ecaeda0508c9076828f0 Bosmon, yzen, Justin_o, your feedback please

[10:01:20 CDT(-0500)] <cindyli> Justin_o: michelle, I have a branch that implements the draggable floating menu aimed for the text-to-speech design. wonder if you can take a look and give some feedback: https://github.com/cindyli/infusion/tree/FLUID-floating-selfVoicing-menu

[10:01:54 CDT(-0500)] <cindyli> run fat panel demo will show u the experimental menu. please forgive the not-so-pretty styling

[10:03:34 CDT(-0500)] <Justin_o> cindyli: okay.. will try to take a look in a bit

[10:03:37 CDT(-0500)] <Justin_o> thanks for putting it up

[10:03:42 CDT(-0500)] <cindyli> thanks, Justin_o

[10:06:55 CDT(-0500)] <cindyli> Justin_o: next, i'm going to look for a slidable slider for both touch and non-touch screens. is there anyone looking into that?

[10:07:29 CDT(-0500)] <Justin_o> cindyli: for the carousel.. jhung and heidiv are looking into finding an accessible carousel

[10:08:55 CDT(-0500)] <cindyli> Justin_o: but not sliders. jhung and heidiv, are you looking into a slidable slider for touch screens?

[10:09:18 CDT(-0500)] <Justin_o> cindyli: oh you mean for the font size and etc.. no they aren't

[10:09:35 CDT(-0500)] <cindyli> ok, will work on that. thanks, Justin_o

[10:10:10 CDT(-0500)] <Justin_o> heidiv: I left a couple more minor comments to your pull request.. once you have those taken care of I'll try to run it

[10:10:30 CDT(-0500)] <heidiv> Justin_o gee i fixed these already… making sure it pushed correctly

[10:10:44 CDT(-0500)] <Justin_o> heidiv: okay.. thanks

[10:15:15 CDT(-0500)] <heidiv> cindyli there was a jquery plugin i came across w the carousels called mousewheel - not sure if it's related to touch sliding but maybe?

[10:15:39 CDT(-0500)] <heidiv> seemed to try to make mouse/track pad activity work cross-browser

[10:16:35 CDT(-0500)] <cindyli> heidiv: would that plugin be a part of your carousel or different one?

[10:16:57 CDT(-0500)] <heidiv> cindyli it was a seperate jquery plugin that one carousel required

[10:17:13 CDT(-0500)] <cindyli> ok, i see. could try that. thanks, heidiv

[13:03:48 CDT(-0500)] <arashs> jvass: I like both of your options for simplifying content presentation on UI Options, and I was thinking that they could both be used in different scenarios

[13:04:28 CDT(-0500)] <arashs> But I came across a concept, and wanted to know what you think. The 7th image on this article (http://coding.smashingmagazine.com/2013/03/11/responsible-web-design/) has a "text size" scroll bar that has stages. I was imagining that we could have a scroll bar like this with each stage dedicated to specific content on the page…

[13:05:19 CDT(-0500)] <arashs> what do you think?

[13:18:05 CDT(-0500)] <Justin_o> cindyli: just looking over your code changes for FLUID-4927

[13:18:09 CDT(-0500)] <Justin_o> what was this needed for https://github.com/cindyli/infusion/commit/61324401709e4b81e764ecaeda0508c9076828f0#L2R257

[13:19:40 CDT(-0500)] <cindyli> Justin_o: you mean 'fluid.originalEnhancerOptions'?

[13:21:16 CDT(-0500)]

[13:21:40 CDT(-0500)] <Justin_o> i mean that.uiEnhancerOptions = fluid.copy(uiEnhancerOptions);

[13:22:36 CDT(-0500)] <cindyli> right, good point, no longer necessary to make a copy. making change

[13:22:50 CDT(-0500)] <Justin_o> cindyli: thansk

[13:23:06 CDT(-0500)] <cindyli> np

[13:25:23 CDT(-0500)] <cindyli> done and pushed, Justin_o

[13:27:35 CDT(-0500)] <Justin_o> cindyli: great. thanks

[13:29:04 CDT(-0500)] <Justin_o> cindyli: i think that's all i can see.. i guess you couldn't make it autoInit because you needed to copy the options before the framework started to act on them?

[13:29:20 CDT(-0500)] <cindyli> yes, Justin_o

[13:29:35 CDT(-0500)] <Justin_o> cindyli: okay

[14:04:55 CDT(-0500)] <Bosmon> Hi cindyli

[14:04:59 CDT(-0500)] <Bosmon> Did you work out the GRADES?

[14:05:19 CDT(-0500)] <cindyli> yes, Bosmon

[14:05:25 CDT(-0500)] <Bosmon> That's great!

[14:05:36 CDT(-0500)] <cindyli> here: https://github.com/cindyli/infusion/commit/61324401709e4b81e764ecaeda0508c9076828f0

[14:05:40 CDT(-0500)] <Bosmon> Looks like htere will be some BIG MERGING ACTTION soon : P

[14:05:46 CDT(-0500)] <Bosmon> How are things standing with the design work?

[14:06:38 CDT(-0500)] <cindyli> pretty good i think, Justin_o and michelle are reviewing that branch

[14:07:23 CDT(-0500)] <Justin_o> Bosmon, cindyli: it's pretty close.. I'm testing it out and have a few more comments/issues to mention.

[14:07:54 CDT(-0500)] <Bosmon> cindyli - I'm wondering whether you ran into this problem: http://issues.fluidproject.org/browse/FLUID-4987

[14:08:02 CDT(-0500)] <Bosmon> I have a memory you might have mentioned something similar to this recently

[14:08:51 CDT(-0500)] <cindyli> no, don't recal

[14:08:53 CDT(-0500)] <cindyli> l

[14:08:59 CDT(-0500)] <Bosmon> Perhaps it was Justin_o....

[14:09:13 CDT(-0500)] <Bosmon> Did you at some point seem to see events firing twice, or having listeners registered twice?

[14:09:57 CDT(-0500)] <Justin_o> Bosmon: sounds like something i may have run into.. i'll read over the description and hopefully it will job my memory

[14:10:37 CDT(-0500)] <cindyli> The issue i ran into often is options specified in a demands block don't get registered

[14:11:40 CDT(-0500)] <Justin_o> Bosmon: can't really remember.. the summary sounds familiar, but the description doesn't bring anything specific to mind. Sorry

[14:16:46 CDT(-0500)] <cindyli> yzen: regarding ur comment on the pull request - Only model/applier specific stuff can stay in the final init function. We should move this material into an onCreate listener.

[14:17:10 CDT(-0500)] <cindyli> how do we distinguish what goes into finalInit or onCreate listener?

[14:17:25 CDT(-0500)] <Bosmon> cindyli - at the moment the movement seems to be to move everything into the onCreate listener

[14:17:43 CDT(-0500)] <Bosmon> I'm still not convinced that this is actually satisfactory, but it's certainly better than finalInit : P

[14:18:05 CDT(-0500)] <cindyli> meaning finalInit is on the way to be deprecated? Bosmon

[14:18:07 CDT(-0500)] <Bosmon> The model/applier stuff needs to stay behind since we have no declarative syntax for it yet

[14:18:24 CDT(-0500)] <Bosmon> cindyli - yes - this was part of the framework discussion we had last month

[14:18:29 CDT(-0500)] <yzen> Bosmon: that was essentially the tone of your email about framework update right ?

[14:18:35 CDT(-0500)] <Bosmon> yzen - that's right

[14:19:15 CDT(-0500)] <Bosmon> Manual init components are being deprecated extremely soon - and following that, we aim to plan to remove the "lifecycle listeners" such as XxxxInitFunction

[14:21:14 CDT(-0500)] <Bosmon> You can now see a "reasonably modern Uploader" at https://github.com/amb26/infusion/blob/b3903d989568c261933968893f1bcd8ba261aa05/src/webapp/components/uploader/js/Uploader.js#L440-L668 : P

[14:21:31 CDT(-0500)] <Bosmon> 230 lines of configuration, and no initFunctions....

[14:21:39 CDT(-0500)] <Bosmon> Oh sorry

[14:21:45 CDT(-0500)] <Bosmon> There is still a small finalInitFunction

[14:22:33 CDT(-0500)] <Bosmon> Unfortunately we STILL need a better solution to "onCreate"

[14:22:46 CDT(-0500)] <Bosmon> last night I was kicking around an idea of "inverse listeners"

[14:23:04 CDT(-0500)] <Bosmon> That is, a style of configuration that looks like invokers but actually describes listeners

[14:23:32 CDT(-0500)] <Bosmon> The problem is that although it is declarative, it is almost impossible for anyone to discover a PARTICULAR listener supplied to onCreate and override it

[14:23:54 CDT(-0500)] <Bosmon> We have a partial solution to this with namespaces - but this unfortunately doesn't work when people supply arrays of listeners to onCreate, since all but the last one get knocked off

[14:24:10 CDT(-0500)] <Bosmon> And what would have to happen is that people supply a different namespace to each listener, which looks rather unnatural

[14:25:38 CDT(-0500)] <Bosmon> My idea is to provide an alternative syntax using some suggestive word like "on" or "when", perhaps like this:

[14:27:16 CDT(-0500)] <Bosmon> when: {

[14:27:16 CDT(-0500)] <Bosmon> bindFocus: {

[14:27:16 CDT(-0500)] <Bosmon> event: "onCreate",

[14:27:16 CDT(-0500)] <Bosmon> funcName: "fluid.uploader.bindFocus",

[14:27:16 CDT(-0500)]

[14:27:16 CDT(-0500)] <Bosmon> },

[14:27:16 CDT(-0500)] <Bosmon> ....

[14:27:23 CDT(-0500)] <Bosmon> So, this would be the new way of registering the first listener I showed there in the "onCreate" block

[14:27:41 CDT(-0500)] <Bosmon> But the advantage now is that the "bindFocus" name could be straightforwardly used to override just this one particular listener

[14:29:17 CDT(-0500)] <Bosmon> I guess the disadvantage is that it becomes harder to talk about a particular sequence of listeners.....

[14:30:02 CDT(-0500)] <Bosmon> Perhaps this isn't such a great idea

[14:30:05 CDT(-0500)] <Bosmon> Any suggestions?

[14:33:20 CDT(-0500)] <Justin_o> Bosmon: i'm not sure i follow what it is exactly you want to accomplish

[14:35:05 CDT(-0500)] <Bosmon> Justin_o - the aim is for people who are configuring the component to be able to individually target each piece of this material in order to override it if they wish

[14:35:30 CDT(-0500)] <Bosmon> Right now stuck into a giant amorphous "onCreate" block it would be impossible for the integrator to find an individual listener

[14:36:11 CDT(-0500)] <Justin_o> Bosmon: i think i'd probably attach an array of listeners to the onCreate event

[14:36:15 CDT(-0500)] <Bosmon> I guess the answer is probably to start adopting even deeper namespaces for listeners - and put them in the records

[14:36:18 CDT(-0500)] <Justin_o> but i guess you are saying that is hard to override

[14:36:58 CDT(-0500)] <Bosmon> So perhaps we should recommend something like this:

[14:37:04 CDT(-0500)] <Bosmon> listeners: {

[14:37:04 CDT(-0500)] <Bosmon> "onCreate": [{

[14:37:04 CDT(-0500)] <Bosmon> namespace: "uploader.bindFocus",

[14:37:04 CDT(-0500)] <Bosmon> listener: "fluid.uploader.bindFocus",

[14:37:04 CDT(-0500)]

[14:37:05 CDT(-0500)] <Bosmon> },

[14:37:34 CDT(-0500)] <Justin_o> Bosmon: what happens if no namespace is provided

[14:37:44 CDT(-0500)] <Justin_o> for example with all the existing components

[14:37:49 CDT(-0500)] <Bosmon> Justin_o - if no namespace is provided, the listeners only accumulate and can never be configured away

[14:37:55 CDT(-0500)] <Justin_o>

[14:37:59 CDT(-0500)] <Justin_o> i see

[14:38:02 CDT(-0500)] <Bosmon> All listeners with no namespace are added to a global pool for that event

[14:38:20 CDT(-0500)] <Justin_o> i see the issue now

[14:38:38 CDT(-0500)] <Justin_o> are we saying that we should always be supplying namespaces for our listeners then

[14:38:59 CDT(-0500)] <Bosmon> Putting a namespace on every "standard listener" for a component certainly adds more verbosity, but I don't see a good alternative to it right now

[14:39:14 CDT(-0500)] <Bosmon> And I'm not sure I can think of a reasonable "convention" either that would invent the namespace names as required

[14:39:45 CDT(-0500)] <Bosmon> Perhaps one possibility is to make a convention that every "standard listener" has a global function name based on the name of the component

[14:39:54 CDT(-0500)] <Bosmon> And then to take the "last two path segments" to form the namespace name as above

[14:40:03 CDT(-0500)] <Justin_o> Bosmon: can you have more than one listener in the same namespace

[14:40:05 CDT(-0500)] <Justin_o> ?

[14:40:13 CDT(-0500)] <Bosmon> Justin_o - no, exactly one per namespace

[14:40:22 CDT(-0500)] <Bosmon> Which is why we need to keep inventing new namespaces at a furious rate : P

[14:40:38 CDT(-0500)] <Justin_o> lol

[14:40:55 CDT(-0500)] <cindyli> or can the listener function name like "fluid.uploader.bindFocus" be used to identify the listener, they are unique

[14:41:02 CDT(-0500)] <Justin_o> can you explain this one a bit more "Perhaps one possibility is to make a convention that every "standard listener" has a global function name based on the name of the component"

[14:42:30 CDT(-0500)] <Bosmon> Yes, I guess we could just use the function name itself.... but in some cases there is no such global name

[14:42:48 CDT(-0500)] <Bosmon> Look at this listener for example:

[14:42:50 CDT(-0500)] <Bosmon> {

[14:42:50 CDT(-0500)]

[14:42:50 CDT(-0500)] <Bosmon> method: "click",

[14:42:50 CDT(-0500)]

[14:42:50 CDT(-0500)] <Bosmon> }

[14:43:23 CDT(-0500)] <cindyli> i see. that's where it needs a unique name

[14:43:28 CDT(-0500)] <Bosmon> Sometimes the function has been resolved an existing one attached to component itself

[14:44:06 CDT(-0500)] <Bosmon> So this listener might have the namespace of something like "uploader.pauseButton"

[14:44:13 CDT(-0500)] <Bosmon> Or perhaps even "uploader.pauseButton.click"

[14:44:20 CDT(-0500)] <cindyli> make sense

[14:44:50 CDT(-0500)]

[14:44:57 CDT(-0500)] <cindyli> what if there are several invokers registered for pauseButton.click

[14:45:05 CDT(-0500)]

[14:45:15 CDT(-0500)] <cindyli> better

[14:45:48 CDT(-0500)] <Bosmon> cindyli - I have no idea but one would imagine there is just one PURPOSE for registering a listener to pauseButton.click

[14:46:35 CDT(-0500)] <Bosmon> The naming should be about purposes, and not about physical parts of the component's structure - although in general you'd think that names for the latter lead to names for the former

[14:46:43 CDT(-0500)] <Bosmon> The pause button DOES something.... it causes the uploader to pause

[14:47:06 CDT(-0500)] <Bosmon> And so it is that purpose of the button which gives rise to the name of the handler

[14:47:13 CDT(-0500)] <cindyli> agree

[14:47:50 CDT(-0500)] <Bosmon> We have a chance to do better here than we could with "renderer decorators" - since there was no expectation there that integrators would find bits of protoTree and override them

[14:47:53 CDT(-0500)] <Bosmon> They were a complete mess

[14:48:27 CDT(-0500)] <Bosmon> But we still need to think how we can make a convention that "looks sensible" but doesn't create a huge amount of work for the original component author

[14:49:03 CDT(-0500)] <Bosmon> There should be a clear and direct way of deriving a namespace for something which makes sense to both the author and the integrator

[14:49:22 CDT(-0500)] <anastasiac> Bosmon, quick question about the new "members" functionality: I wouldn't be able to use this to move something from an integrator option into the model, would I?

[14:49:27 CDT(-0500)] <cindyli> that's true. not easy to accommodate both

[14:49:37 CDT(-0500)] <Bosmon> anastasiac - no, "members" moves things only onto the top-level component

[14:49:46 CDT(-0500)] <anastasiac> ok, thanks - that's what I suspected

[14:50:00 CDT(-0500)] <Bosmon> In theory you could try to see whether you could get away with writing an EL reference inside the "model" part of the configuration

[14:50:10 CDT(-0500)] <Bosmon> But we haven't worked out that part of the framework much so far

[14:50:16 CDT(-0500)] <Bosmon> yzen and I were having a chat about it last night in fluid-tech

[14:50:27 CDT(-0500)] <yzen> Bosmon: it was fun

[14:50:57 CDT(-0500)] <Bosmon> anastasiac - even if you succeeded in moving an option into the model right now, you would have the further problem that the "applier" wouldn't be prepared to take any special account of the material

[14:51:03 CDT(-0500)] <Bosmon> But it is worth a try to see what happens

[14:51:08 CDT(-0500)] <Bosmon> And if it doesn't work, write up a JIRA for it

[14:51:18 CDT(-0500)] <anastasiac> yeah, I figured

[14:51:30 CDT(-0500)] <anastasiac> I tried the el path, but didn't work

[14:51:41 CDT(-0500)] <Bosmon> anastasiac - what did it do?

[14:51:59 CDT(-0500)] <anastasiac> it got extremely confused

[14:52:46 CDT(-0500)] <anastasiac> it seems to update the model, but as you say, the applier wasn't informed

[14:53:17 CDT(-0500)] <Bosmon> anastasiac - so the model material came from another model then?

[14:53:22 CDT(-0500)] <Bosmon> Rather just from "any old option"?

[14:53:38 CDT(-0500)] <anastasiac> no, not another model; it came from an integrator option

[14:53:53 CDT(-0500)] <Bosmon> anastasiac - ok, so what could the applier have to know about it?

[14:54:48 CDT(-0500)] <anastasiac> Bosmon, I haven't yet tracked down exactly what was going on, but the tests failed because the model didn't seem to have what it was supposed to have, despite the fact that it seemed that the initial members processing seems to put it there

[14:55:14 CDT(-0500)] <anastasiac> as I said, I haven't yet tracked down exactly what went wrong

[14:55:18 CDT(-0500)] <Bosmon> anastasiac - that's interesting

[14:55:37 CDT(-0500)] <Bosmon> See if you can diagnose what the resulting situation was...

[15:02:26 CDT(-0500)] <anastasiac> Bosmon, turns out I was wrong: the EL path didn't actually work, and the model was NOT successfully modified by the members processing

[15:03:35 CDT(-0500)] <anastasiac> fluid.recordStrategy wraps the name in an array, so the EL path parsing doesn't actually parse it

[15:12:11 CDT(-0500)] <Bosmon> anastasiac - thanks, that's good to know

[15:55:56 CDT(-0500)] <yzen> pretty cool http://smallcultfollowing.com/babysteps/blog/2013/03/20/parallel-js-lands/