fluid-work IRC Logs-2013-03-14

[10:17:30 CDT(-0500)] <jhung> jvass, do we have any wireframes / designs for the PMT?

[10:19:38 CDT(-0500)] <jvass> jhung, http://wiki.fluidproject.org/display/fluid/%28C4A%29+Preference+Management+Tool+Mockups

[13:38:14 CDT(-0500)] <lastlegion> Hello! This is Ganesh from India

[15:39:00 CDT(-0500)] <michelled> Bosmon: when you get a chance, the KING would like you to take a look at his JIRA: http://issues.fluidproject.org/browse/FLUID-4927

[15:42:58 CDT(-0500)] <Bosmon> Ah, he has gone

[18:06:59 CDT(-0500)] <Justin_o> Bosmon: thanks for your feedback on the FLUID-4927 jira. I've made some changes.. I'm curious to know what you think. Also have some more questions about whether or not an eventedModel grade is actually useful.

[18:10:24 CDT(-0500)] <Bosmon> Justin_o - it's a good question

[18:10:30 CDT(-0500)] <Bosmon> A lot depends on the usage model!

[18:10:33 CDT(-0500)] <Bosmon> Which is why I'm keen to see it

[18:12:54 CDT(-0500)] <Justin_o> Bosmon: okay.. maybe i'll draw something up in a comment.. by the way, for cindy's changes.. i wasn't quite sure how the relay communicates model changes in the individual enactor back to the larger model

[18:14:57 CDT(-0500)] <Bosmon> Justin_o - here is her core implementation

[18:14:58 CDT(-0500)] <Bosmon> https://github.com/fluid-project/infusion/pull/268/files#L1R39

[18:15:10 CDT(-0500)] <Bosmon> Right now it doesn't do anything more sophisticated than swap one path for another

[18:15:19 CDT(-0500)] <Bosmon> But this might already be all we need to get the current impl working

[18:19:23 CDT(-0500)] <Justin_o> Bosmon: i added a comment about the eventedModel

[18:20:14 CDT(-0500)] <Justin_o> Bosmon: in terms of cindy's code, i was looking at the model relay. I see that it listens to a change through the sourceApplier and then makes the same change onto the components model. But i don't see where component level model changes are sent back up

[18:20:49 CDT(-0500)] <Bosmon> Yes

[18:20:53 CDT(-0500)] <Bosmon> That part seems to be missing

[18:21:10 CDT(-0500)] <Bosmon> Although somehow, she insists that she has a working component : P

[18:22:52 CDT(-0500)] <Justin_o> Bosmon: maybe i'll just add comment to her pull request to ask, so i don't forget tomorrow

[18:23:05 CDT(-0500)] <Bosmon> Justin_o: cool

[18:23:15 CDT(-0500)] <Bosmon> Perhaps she didn't test the functionality like "reset", etc.

[18:26:05 CDT(-0500)] <Justin_o> Bosmon: maybe.. i didn't look through all of the her tests.. so not sure

[18:26:26 CDT(-0500)] <Bosmon> Well, it might only show up in the manual test of the component

[18:26:42 CDT(-0500)] <Bosmon> Since the tests we currently have don't know about these numerous little "private models"

[18:27:01 CDT(-0500)] <Justin_o> Bosmon: right..

[18:27:16 CDT(-0500)] <Bosmon> They would probably have been happy enough to see the global model state updated

[18:27:28 CDT(-0500)] <Bosmon> And wouldn't look to see if the UI had been updated in step

[18:29:09 CDT(-0500)] <Justin_o> Bosmon: did you have a chance to take a look at the comment i left on my jira about the eventedModel

[18:31:15 CDT(-0500)] <Bosmon> Justin_o - re that particular usage of eventedModel - I'm very concerned about exposing details to integrators that might need to change in future revisions of the framework

[18:31:39 CDT(-0500)] <Bosmon> If you offer "eventedModel" to an integrator, we will need to support it for all time

[18:31:43 CDT(-0500)] <Bosmon> Or until Fluid 3.0 : P

[18:32:58 CDT(-0500)] <Justin_o> Bosmon: I was hoping your changes to expose the applier events directly would be in place by 2.0

[18:33:11 CDT(-0500)] <Bosmon> I'm not sure they necessarily will be

[18:33:17 CDT(-0500)] <Justin_o>

[18:33:43 CDT(-0500)] <Justin_o> anyways the eventedModel i outlined was just a convenience and isn't really necessary, so i don't mind dropping it

[18:34:31 CDT(-0500)] <Justin_o> Bosmon: any thoughts on if the fetchResources stuff should be a separate grade.. i think it could be useful for both the settingsPanel and the settingView components

[18:37:14 CDT(-0500)] <Bosmon> Justin_o - I'm still not clear about the relationship between the components you call XxxxViews and the panels

[18:37:23 CDT(-0500)] <Bosmon> Are you imagining that the XxxxViews will be components of the panels?

[18:37:30 CDT(-0500)] <Justin_o> Bosmon: yes

[18:37:35 CDT(-0500)] <Bosmon> Ok

[18:37:49 CDT(-0500)] <Bosmon> So it looks like you are going away from the model whereby a panel will render "all at once"

[18:38:03 CDT(-0500)] <Bosmon> but instead, each individual component will represent a separate invocation of the renderer?

[18:38:25 CDT(-0500)] <Justin_o> Bosmon: ah.. yes.. that's true

[18:38:44 CDT(-0500)] <Bosmon> That's not necessarily completely insane, but it does represent a very significant change to the model

[18:39:38 CDT(-0500)] <Justin_o> Bosmon: okay.. i think as it stands now it's hard to modify the panels though.

[18:39:44 CDT(-0500)] <Justin_o> or at least appears to be

[18:39:48 CDT(-0500)] <Bosmon> It might be possible that this refactoring is a bit too ambitious, in that it might be trying to do too many things at once

[18:40:00 CDT(-0500)] <Justin_o> Bosmon: okay.. that's fair

[18:40:32 CDT(-0500)] <Bosmon> I think our #1 goal is to end up with an "empty UIOptions", just as cindy is on the way to an "empty UIEnhancer"

[18:40:55 CDT(-0500)] <Bosmon> It might be worth just taking the most direct route to that, since it will already involve very significant refactoring

[18:41:50 CDT(-0500)] <Bosmon> I might be wrong, but I think you are going to run into problems getting the templating working for your "renderer-based setting views"

[18:42:06 CDT(-0500)] <Bosmon> Since the rules that they will operate will be quite different to the ones for "full-panel rendering"

[18:42:41 CDT(-0500)] <Justin_o> Bosmon: I thought that the template loader did all the fetching ahead of time, and passed along completed resources to each of the components

[18:43:12 CDT(-0500)] <Justin_o> which i guess means the template for the whole panel goes to the panel

[18:43:15 CDT(-0500)] <Bosmon> Justin_o - that's correct

[18:43:37 CDT(-0500)] <Bosmon> And so how do you plan to pass just the "part" of the template that belongs to one of your renderer settings views to it?

[18:44:15 CDT(-0500)] <Justin_o> Bosmon: I guess i was assuming i'd add some more of that "strange" style configuration for pointing to the templates. and then just pass in the part i want through the configuration

[18:44:34 CDT(-0500)] <Bosmon> Justin_o - how could you do it, given that the templates haven't been parsed yet?

[18:44:41 CDT(-0500)] <Bosmon> They just consist of strings at this point

[18:46:36 CDT(-0500)] <Justin_o> Bosmon: I guess i'll walk you through what i was expecting and you can tell me where i'm mistaken.. or maybe i'll figure that out as I go

[18:46:50 CDT(-0500)] <Bosmon> Justin_o: ok

[18:47:05 CDT(-0500)] <Justin_o> so for starters I would modify the list of templates https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uiOptions/js/UIOptions.js#L349-L353

[18:48:35 CDT(-0500)] <Justin_o> then i'd be able to get register the templates to the components like this https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uiOptions/js/UIOptions.js#L761-L763

[18:49:05 CDT(-0500)] <Justin_o> the components would have to be responsible for getting the markup into the DOM themselves though.. so probably a call to append or through the renderer i guess

[18:49:22 CDT(-0500)] <colinclark> late night king!

[18:49:54 CDT(-0500)] <Justin_o> colinclark: a bit.. just wanted to make sure i can hit the ground running tomorrow morning

[18:50:49 CDT(-0500)] <Justin_o> Bosmon: i supposed i'd also have to do something with this. https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uiOptions/js/UIOptions.js#L208-L221

[18:51:31 CDT(-0500)] <Bosmon> Justin_o - The issue I see with this is that we some time ago abandoned the use of the technique known as "self-rendering", as this would be known as

[18:51:42 CDT(-0500)] <Bosmon> That is, where some existing DOM material is used as the "template" for some other DOM material

[18:52:00 CDT(-0500)] <Bosmon> I remember we did have some good reasons for it at the time, although I can't bring them to mind right away : P

[18:53:06 CDT(-0500)] <Bosmon> But at some point about 18 months ago, we went on a "death sweep" of all cases where we could discover self-rendering throughout the framework and CSpace, in order to remove them

[18:53:18 CDT(-0500)] <Justin_o> Bosmon: i'm not sure i understand what you mean by "self-rendering" do you mean where the template is already in the markup and not fetched from anywhere?

[18:53:23 CDT(-0500)] <Bosmon> Justin_o - that is what I mean

[18:54:03 CDT(-0500)] <Justin_o> Bosmon: okay.. sure, but i didn't mean that with what i was proposing.. you would still fetch the resources.. i just though the template loader was responsible for fetching all of the templates ahead of time

[18:54:34 CDT(-0500)] <Bosmon> Justin_o - it is implied in what you are proposing, because each instance of a "SettingView" as you have called it is responsible for only PART of a template

[18:54:57 CDT(-0500)] <Justin_o> Bosmon: it's the template for itself

[18:55:07 CDT(-0500)] <Justin_o> since they are all separate components

[18:55:24 CDT(-0500)] <Justin_o> maybe we aren't on the same page with what a template is

[18:55:25 CDT(-0500)] <Bosmon> Justin_o - so you are implying that someone who produces a "panel" which contains 4 "SettingViews" will provide 5 templates?

[18:55:31 CDT(-0500)] <Bosmon> One for the panel, and one for each SettingView?

[18:56:20 CDT(-0500)] <Justin_o> Bosmon: yes, probably.. although i'm thinking that in practice a lot of the settings will probably have the same template since they are radio buttons, selects, checkboxes or sliders at this point

[18:56:32 CDT(-0500)] <Justin_o> but yes, it could be distinct ones for each

[18:56:43 CDT(-0500)] <Bosmon> And what happens if the person who wrote the panel template wants to restyle them in some way?

[18:57:15 CDT(-0500)] <Justin_o> Bosmon: not sure i follow

[18:57:35 CDT(-0500)] <Bosmon> What if the person who wrote the panel doesn't like the markup for the "SettingView"

[18:57:59 CDT(-0500)] <Justin_o> I guess it sounds to me like having the parent render the template for the subcomponent is a case of "self-rendering" as the subcomponent would expect the markup in the DOM

[18:58:11 CDT(-0500)] <Justin_o> Bosmon: yes, then they could replace it..

[18:58:16 CDT(-0500)] <Bosmon> Justin_o - you can't have it both ways

[18:58:25 CDT(-0500)] <Bosmon> Either it is already in the document, OR it is in a separate template : P

[18:58:32 CDT(-0500)] <Bosmon> Which version is part of your plan?

[18:58:39 CDT(-0500)] <Justin_o> separate templates

[18:58:53 CDT(-0500)] <Justin_o> i'm trying to say don't put it in the DOM

[18:59:01 CDT(-0500)] <Bosmon> So there is actually no self-rendering, and the panel author doesn't get any say about the markup for the "SettingViews"?

[18:59:17 CDT(-0500)] <Justin_o> Bosmon: no, they would pass in a different template

[18:59:24 CDT(-0500)] <Justin_o> through the resources

[18:59:39 CDT(-0500)] <Justin_o> at least that's how i understood these things to work.. maybe i'm mistaken

[19:01:19 CDT(-0500)] <colinclark> how's it going, guys?

[19:01:25 CDT(-0500)] <colinclark> I haven't fully been following

[19:01:36 CDT(-0500)] <colinclark> had a long conversation with avtar about Nebula

[19:01:40 CDT(-0500)] <colinclark> but I'm curious to hear a summary

[19:02:25 CDT(-0500)] <Justin_o> I'm afraid we are speaking different languages to each other.. I'll try to explain my point of view from the begging and hopefully clear things up.. 1) each component whether panel or view would have its own template. 2) this template could be fetched by the component itself or in the case of UIO by the template loader. 3) the components would place this template into the markup themselves as they are created

[19:02:26 CDT(-0500)] <Justin_o> this could be with a call to append or through the Renderer

[19:02:33 CDT(-0500)] <Justin_o> colinclark: ^

[19:03:02 CDT(-0500)] <Justin_o> that's my reiteration of my intention.. hope it makes sense, at least in terms of being understandable

[19:04:08 CDT(-0500)] <Bosmon> Justin_o - could you expand on point 3)

[19:04:18 CDT(-0500)] <Bosmon> What do you mean by "the component would place this template into the markup themselves"

[19:04:51 CDT(-0500)] <Bosmon> a) how would they do it, b) when would they do it, c) where would they put it, d) what would be the result, and would it require e) a further stage of self-rendering?

[19:05:32 CDT(-0500)] <colinclark> Justin_o: I get that, roughly

[19:06:03 CDT(-0500)] <colinclark> I guess #3 is, as Boz is perhaps asking about, probably the most complex case, Justin_o

[19:06:19 CDT(-0500)] <colinclark> Since, as I understand what you're proposing, there'd be little tiny templates for each "ant view"

[19:06:39 CDT(-0500)] <colinclark> and the question then becomes, where does each ant view put its markup when it renders it?

[19:07:30 CDT(-0500)] <colinclark> I'm almost imagining that we'd need to have some kind of "ant rendering orchestrator" that was responsible for determining a sequence in which each ant view will render itself, and where that markup is ultimately placed, etc.

[19:08:03 CDT(-0500)] <Justin_o> Bosmon: okay.. a) append or through the Renderer b) on init or if the Renderer is being used, whenever it runs c) probably right in there container d+e) in the case of the Renderer no further rendering.. if it's a jQuery UI widget, probably more rendering

[19:08:36 CDT(-0500)] <Justin_o> colinclark: yes, I do mean tiny templates

[19:09:02 CDT(-0500)] <colinclark> Presumably, you'd want to actually associate templates with certain component grades

[19:09:26 CDT(-0500)] <colinclark> "multiSelectSettingView," "switchSettingView" etc.

[19:09:53 CDT(-0500)] <colinclark> But there is still, it seems to me, a requirement for something that actually orchestrates the process of all these ants rendering their stuff

[19:10:11 CDT(-0500)] <colinclark> Am I wrong, Justin_o?

[19:11:38 CDT(-0500)] <Justin_o> colinclark: yes.. we'd probably want to have some preconfigured components like contrast component and etc.. for something generic though the only difference may be the template.. as I believe radio buttons, selects, and checkboxes could pretty much be the same otherwise.

[19:11:40 CDT(-0500)] <Bosmon> Justin_o - and sorry to distract you with a further question, but isn't it the case that this approach moves against the "markup-first" model that we've been trying to promote for so many years?

[19:11:51 CDT(-0500)] <Bosmon> As I understand it, the "template" for a panel would now only consist of a set of empty <div>s

[19:11:52 CDT(-0500)] <Justin_o> as for orchestrating, wouldn't the framework handle that?

[19:11:59 CDT(-0500)] <Bosmon> And so would then preview to nothing

[19:12:34 CDT(-0500)] <Bosmon> It would look very similar to the markup for the typical YUI component : p

[19:12:39 CDT(-0500)] <Justin_o> Bosmon: yes.. that's true.. i think i'm slightly confused with our goals then.. i thought we had been moving the markup to always be fetched

[19:13:26 CDT(-0500)] <Bosmon> Justin_o - surely it's the case that the markup is already fetched - given that it is fetched for a panel currently

[19:14:06 CDT(-0500)] <Justin_o> Bosmon: but then don't we have the case where some components fetch there markup and some expect it in the DOM

[19:14:30 CDT(-0500)] <Bosmon> Justin_o - that's correct

[19:14:49 CDT(-0500)] <Justin_o> Bosmon: shouldn't we be consistent..

[19:14:52 CDT(-0500)] <Bosmon> That is why this is indeed a significant problem

[19:14:56 CDT(-0500)] <Bosmon> Justin_o - no

[19:15:08 CDT(-0500)] <Bosmon> We should do whatever our users want in a particular situation : P

[19:15:11 CDT(-0500)] <Justin_o> Bosmon: i don't mean for the demo, i just mean in general, should consistency be our goal

[19:15:20 CDT(-0500)] <Justin_o> Bosmon: but how do we know

[19:15:21 CDT(-0500)] <Bosmon> "Consistency is the hobgoblin of a weak mind" : P

[19:15:37 CDT(-0500)] <Bosmon> Justin_o - we will provide ways for them to express our intention to them

[19:15:42 CDT(-0500)] <colinclark> isn't there an inversion to that saying, Bosmon?

[19:15:43 CDT(-0500)] <Bosmon> Er, their intention to us

[19:15:47 CDT(-0500)] <Justin_o> Bosmon: what if they want to take some of these components out and use them somewhere else..

[19:15:48 CDT(-0500)] <Bosmon> colinclark - there always is

[19:15:55 CDT(-0500)] <Bosmon> "Great minds think alike"

[19:16:01 CDT(-0500)] <Bosmon> "Fools seldom differ" : P

[19:16:29 CDT(-0500)] <Bosmon> Justin_o - we will assist them to code with, as you say, jQuery UI widgets and the like

[19:16:37 CDT(-0500)] <Bosmon> But we will also provide them with ways to put designers in charge

[19:16:54 CDT(-0500)] <Bosmon> Right now the model of a "panel full of empty divs" disempowers designers

[19:17:18 CDT(-0500)] <Bosmon> BUT it may genuinely be that disempowered designers is what a particular user needs and wants

[19:17:28 CDT(-0500)] <Justin_o> Bosmon: sure but i don't think that's what we're saying here.. we're saying sometimes a fluid component has markup it fetches, and sometimes you have to put it in the dom yourself.. but you have to look through the defaults to figure out which is which

[19:17:42 CDT(-0500)] <Bosmon> We need to find a way to deliver both models to them, without everyone having to pay a penalty

[19:18:20 CDT(-0500)] <Bosmon> Justin_o - the defaults are one possibility for control, yes

[19:18:27 CDT(-0500)] <colinclark> Ideally, we would have a model where components would adapt to either finding their markup already there for them, or having to fetch "default" markup in the absence of anything

[19:18:34 CDT(-0500)] <Bosmon> There might be other ways of "sensing our context"

[19:18:58 CDT(-0500)] <colinclark> which would allow us to merge the worlds of "designer whipped up a mockup HTML page, and it works!" with "highly modular, reusable in isolation" widgets

[19:19:08 CDT(-0500)] <Justin_o> Bosmon, colinclark: agreed.. but in the case of UIO i don't think we are empowering the designers, since we are at some point still fetching templates

[19:19:24 CDT(-0500)] <colinclark> Justin_o: My sense is that there's a lot here...

[19:19:32 CDT(-0500)] <colinclark> And perhaps some more conversation to be had

[19:19:36 CDT(-0500)] <Bosmon> Justin_o - the issue is that the "designer" must be free to design at whatever level they need to

[19:19:41 CDT(-0500)] <colinclark> I can think of a couple of scenarios...

[19:19:48 CDT(-0500)] <colinclark> I know Bosmon is hopping on a plane fairly soon

[19:19:52 CDT(-0500)] <Bosmon> Which might be i) an entire "component" like UIOptions, ii) a single panel, iii) an individual control

[19:19:55 CDT(-0500)] <colinclark> So, here are my thoughts:

[19:20:12 CDT(-0500)] <Bosmon> Different designers in different scenarios may well find any or all of these levels appropriate

[19:20:25 CDT(-0500)] <colinclark> 1. Take a day, pursue your approach while keeping in mind some of these points we're talking about, and see if you think it's a viable approach

[19:20:43 CDT(-0500)] <colinclark> 2. Take a more incremental approach, and do something simpler, and keep taking progressively improving steps towards your goal

[19:22:32 CDT(-0500)] <Justin_o> colinclark: i think i might have to do the work the opposite direction, which is to say start with what's there and see if i can make an empty UIO out of that, then start to break things down from there

[19:23:33 CDT(-0500)] <colinclark> Aside from the issue of "in-page markup" vs. "little tiny templates," what are the other complexities that you foresee in Justin_o's idea, Bosmon?

[19:23:45 CDT(-0500)] <colinclark> Justin_o: I think that makes sense to me

[19:26:19 CDT(-0500)] <colinclark> I think some of this is tough to gauge because we're balancing two somewhat conflicting priorities

[19:26:23 CDT(-0500)] <colinclark> which is often the case

[19:26:34 CDT(-0500)] <colinclark> 1. Implement the new designs so people can start to see the next generation of UIO

[19:26:36 CDT(-0500)] <Bosmon> colinclark - the other complexities relate to timing, and propagation of resources

[19:26:59 CDT(-0500)] <colinclark> 2. Create a long-term API enabling people like Kostas and Chris and Evgeni to create fairly radical extensions of UIO

[19:27:47 CDT(-0500)] <Bosmon> In the "old framework" on which UIO is based, we had no way to dynamically collect together a number of asynchronous things which were all IoC-resolved, and then cause a component's construction to wait on them

[19:28:06 CDT(-0500)] <Bosmon> In the "new framework" we conceivably have this ability but haven't yet started to work on delivering it

[19:28:09 CDT(-0500)] <Justin_o> Bosmon, colinclark: so I'm going to start with what's there and get the empty thing working, but when we start moving to the new designs, should i drop all semblance of template fetching in favour of it being in the demo page?

[19:28:30 CDT(-0500)] <Bosmon> Justin_o - I think it would be best to continue with the model we have now?

[19:28:42 CDT(-0500)] <Bosmon> That is, "one template per panel" and "empty divs at the panel level"

[19:28:50 CDT(-0500)] <Justin_o> Bosmon: okay

[19:29:03 CDT(-0500)] <Bosmon> It is a kind of "middle compromise choice" that will disturb people as little as possible - even though it might not be best for everyone

[19:29:34 CDT(-0500)] <Bosmon> Also it will mean that anyone following AC's current integration instructions will not be immediately disturbed when we start showing versions of this new component

[19:29:58 CDT(-0500)] <Bosmon> And then we can think in the meantime about how we really plan to deliver the flexibility to users that we know they need

[19:30:10 CDT(-0500)] <Bosmon> I know that AC has been having discussions with users about "generic checkbox panels" etc.

[19:31:19 CDT(-0500)] <Bosmon> Your aim for "empty divs at the panel level" was laudable since it clearly met the need of SOME users - but we can't just swap one static model for another

[19:31:32 CDT(-0500)] <Bosmon> I think if we ever change this current organisation, it should be in favour of one that offers all choices

[19:31:38 CDT(-0500)] <Bosmon> Rather than simply making 1 different choice

[19:32:00 CDT(-0500)] <Bosmon> Sorry, I meant "empty divs at the setting level"

[19:33:32 CDT(-0500)] <Justin_o> Bosmon: sounds good.. I guess i'm afraid that our current approach maybe making everyone equal by not really serving either. So we should keep this improvement on our radar

[19:33:44 CDT(-0500)] <Bosmon> wow, comments from cindy as well just now

[19:33:51 CDT(-0500)] <Bosmon> Everyone's working late today : P

[19:33:57 CDT(-0500)] <Justin_o> Bosmon:

[19:40:20 CDT(-0500)] <Justin_o> Bosmon, colinclark: thanks for the chat, I think i have a the direction for moving forward.. i'm heading out for tonight though.. talk to you later

[19:40:37 CDT(-0500)] <colinclark> good luck, Justin_o

[19:40:41 CDT(-0500)] <colinclark> let me know if you want to chat more tomorrow

[19:40:58 CDT(-0500)] <colinclark> Bosmon: thanks for chatting; i'm off to my meeting

[19:41:07 CDT(-0500)] <Justin_o> colinclark: thanks, will do

[19:41:08 CDT(-0500)] <Bosmon> Thanks, colinclark and Justin_o

[19:41:25 CDT(-0500)] <Bosmon> I'm just replying to cindyli's pull comments now