fluid-work IRC Logs-2010-10-25

[09:34:15 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)
[09:59:58 CDT(-0500)] <justin_o> Bosmon: are you present?
[10:12:14 CDT(-0500)] <jhung> anastasiac: got a few mins to chat about keyboard plugin before standup?
[10:12:25 CDT(-0500)] <anastasiac> sure
[10:12:56 CDT(-0500)] <anastasiac> jhung, how do you want to chat?
[10:13:04 CDT(-0500)] <jhung> We can try IRC for now.
[10:13:27 CDT(-0500)] <jhung> So I committed CSS and HTML into the repo.
[10:13:48 CDT(-0500)] <anastasiac> yes, I saw tht
[10:14:54 CDT(-0500)] <jhung> So I'm thinking that since this demo is showing how something becomes accessible using keyboard, I was thinking that the demo should use a javascript plugin for a horizontal scroller in the thumbnail area.
[10:15:22 CDT(-0500)] <anastasiac> hm{color}
[10:15:44 CDT(-0500)] <anastasiac> what would be the alternative to a javascript plugin for horizontal scrolling, jhung?
[10:17:46 CDT(-0500)] <jhung> 1. A fixed position layout for the entire demo that forces a horizontal scroll.
[10:17:46 CDT(-0500)] <jhung> 2. A naughty "excessively large container" placed into a fixed width container thus forcing a scroll.
[10:17:46 CDT(-0500)] <jhung> 3. Having no scroll and leaving it the way it is (a vertical list of thumbnails).
[10:18:36 CDT(-0500)] <anastasiac> and what are the arguments against the best of these three options?
[10:19:23 CDT(-0500)] * anastasiac is concerned about confusing the demo by introducing javascript that has nothing to do with the plugin we're trying to demo
[10:19:24 CDT(-0500)] <jhung> The best options are 1 or 3. #1 is fixed width and may layout in weird ways depending on the browser and personal preferences.
[10:20:31 CDT(-0500)] <anastasiac> jhung, did you have a particular horizontal-layout plug-in in mind?
[10:21:54 CDT(-0500)] <jhung> anastasiac: not really. I was just thinking about the intention of this demo. In this kind of scenario, a developer would have likely gone with the javascript scroller route for a horizontal scroll. It's fairly common, flexible, and easy to do. But not accessible.
[10:22:22 CDT(-0500)] <anastasiac> how do you mean "not accessible"?
[10:23:11 CDT(-0500)] <jhung> anastasiac: example http://flowplayer.org/tools/demos/scrollable/easing.htm
[10:23:33 CDT(-0500)] <jhung> Can't keyboard focus anything.
[10:23:35 CDT(-0500)] <anastasiac> ah
[10:23:52 CDT(-0500)] <anastasiac> well, I suppose we could try using the keyboard-a11y plugin to make the scroller accessible
[10:24:53 CDT(-0500)] <jhung> conversely, perhaps it's not our position to show how this kind of integration is done? We just show them how to use our plugin and leave it to them to figure out the integration.
[10:27:07 CDT(-0500)] <anastasiac> jhung, I think that might depend on how much work is required to use such a plugin... if it's not a great deal, and if we can use our plugin to make it keyboard accessible, that might actually be interesting - essentially, two demos in one
[10:27:10 CDT(-0500)] <anastasiac> hm...
[10:28:23 CDT(-0500)] <anastasiac> or, jhung, I suppose we could use the FSS's thumbnail grid styling to just make a grid out of the thumnails? avoid the scrolling issue altogether?
[10:29:41 CDT(-0500)] <jhung> anastasiac: we could, but depending on the size of the viewport, the thumbnails would be below the fold. So selecting an image will force the user to have to scroll back to the top to interact with the 5-star and the main image.
[10:30:37 CDT(-0500)] <jhung> standup.
[10:33:56 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)
[10:50:55 CDT(-0500)] <anastasiac> jhung, I have to run off to a yoga class now; I'll be back a bit after 1pm
[10:51:05 CDT(-0500)] <jhung> anastasiac: sure thing. TTYL
[13:05:26 CDT(-0500)] <justin_o> colinclark, mlam: do you have time to talk about inlineEdit stuff
[13:06:59 CDT(-0500)] <colinclark> I have a few minutes, yep
[13:07:02 CDT(-0500)] <colinclark> What's on the agenda?
[13:08:15 CDT(-0500)] <mlam> relative positioning of the keyboard tooltip
[13:08:40 CDT(-0500)] <colinclark> you want me to come over there, or talk about it here in the channel?
[13:08:49 CDT(-0500)] <mlam> i think it'd be faster in person
[13:50:43 CDT(-0500)] <jhung> anastasiac: I've been doing some thinking. I think the best approach here is to go with a grid design for the demo first, then figure out how to integrate a javascript scroller. Could be something better suited for a tutorial, while we keep the demo simple.
[13:51:03 CDT(-0500)] <jhung> what do you think?
[13:51:15 CDT(-0500)] <anastasiac> jhung, can you elaborate a bit on what you mean by a rollover? and it's keyboard accessibility?
[13:51:39 CDT(-0500)] <jhung> rollover?
[13:51:53 CDT(-0500)] * anastasiac needs reading lessons
[13:52:00 CDT(-0500)] <anastasiac> sorry, I read "scroller" as "rollover"
[13:52:07 CDT(-0500)] <jhung>
[13:52:08 CDT(-0500)] <anastasiac> my brain is fried from trying to fix a css bug
[13:52:14 CDT(-0500)] <anastasiac> but I did figure it out!
[13:52:21 CDT(-0500)] * anastasiac pats herself on the back
[13:52:48 CDT(-0500)] <anastasiac> so how would a grid design work, jhung? a small grid under the main viewer instead of the scroller?
[13:53:27 CDT(-0500)] <jhung> anastasiac: Yep.
[13:53:48 CDT(-0500)] <anastasiac> sounds fine. We control the number of images, so it doesn't need to be a large number
[13:53:58 CDT(-0500)] <jhung> anastasiac: then iterate the demo design, or leave the scroller integration as part of a tutorial.
[13:54:02 CDT(-0500)] <anastasiac> and yes, it would help to keep the demo code focussed
[13:54:09 CDT(-0500)] <jhung> anastasiac: exactly.
[13:54:14 CDT(-0500)] <anastasiac> right on the iterations
[13:55:19 CDT(-0500)] <jhung> anastasiac: I'm going to quickly update the list about this decision. I don't think this affects the markup in any way since the images are already implemented as a unordered list.
[13:56:32 CDT(-0500)] <anastasiac> jhung, thanks - good idea to update the list
[14:15:11 CDT(-0500)] <justin_o> jameswy: do you know if the invitation text, displayed when the inlineEdit field is empty, should be the same as the tooltip text
[14:15:41 CDT(-0500)] <jameswy> JenC might have a better idea.
[14:15:59 CDT(-0500)] <jameswy> justin_o could you clarify what you mean by invitation text?
[14:16:26 CDT(-0500)] <justin_o> The invitation text is what is displayed if you were to remove all of the text from an inlineEdit field
[14:16:39 CDT(-0500)] <justin_o> so if you go into one of them and remove all the text and save it, you should see it
[14:17:12 CDT(-0500)] <justin_o> jameswy, JenC : ^
[14:17:15 CDT(-0500)] <JenC> Ah, yes. I think we wanted to leave it as it was set up before, something to the effect of "Click here to edit"
[14:19:23 CDT(-0500)] <justin_o> okay
[14:51:39 CDT(-0500)] <Bosmon> justin_o: I was wanting to ask you about adding a further issue to Parade...
[14:52:50 CDT(-0500)] <justin_o> Bosmon: okay... what's up
[15:06:34 CDT(-0500)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-3818
[15:06:42 CDT(-0500)] <Bosmon> It is something yura_ will need for CollectionSpace
[15:06:48 CDT(-0500)] <Bosmon> Quite a small but important fix
[15:11:46 CDT(-0500)] <justin_o> Bosmon: okay... i can add that for you... by the way... focusin doesn't work in IE 8
[15:11:57 CDT(-0500)] <Bosmon> Well, yura has mentioned this to me
[15:12:04 CDT(-0500)] <justin_o> okay... good
[15:12:14 CDT(-0500)] <Bosmon> I pointed him at this article http://www.neeraj.name/2010/01/14/how-jquery-1-4-fixed-rest-of-live-methods.html
[15:12:17 CDT(-0500)] <Bosmon> Which attests that it works
[15:12:28 CDT(-0500)] <Bosmon> I suggested that perhaps it only works in conjunction with "live" or "delegate"
[15:12:34 CDT(-0500)] <Bosmon> So he is going to try that out at some point
[15:13:51 CDT(-0500)] <justin_o> Bosmon: okay... jquery mentions that focus won't bubble and needs to be used with live.. i'm not sure if that is the same or not
[15:14:47 CDT(-0500)] <justin_o> Bosmon: do you have time to talk about some reorderer stuff
[15:16:54 CDT(-0500)] <Bosmon> Yes, I have time now
[15:17:52 CDT(-0500)] <justin_o> Bosmon: thanks... so you were wondering in the comment you left on FLUID-3391 about turning the wrapping on and off after the component has been instantiated
[15:18:27 CDT(-0500)] <justin_o> So this was something that I wanted to chat with you about the other day, but didn't get a chance to, because i got pulled into another meeting.
[15:18:32 CDT(-0500)] <Bosmon> Yes
[15:19:44 CDT(-0500)] <justin_o> what do we want here... should we give control to the user to be able to turn wrapping on and off or should it only be in the integrators hands... if we have an option in UI Options for example that switches wrapping on and off.. would we have to reinstantiate the component or could we make the changes on the fly
[15:20:02 CDT(-0500)] <justin_o> golam, jameswy, colinclark: you may or may not be interested in this conversation too
[15:20:21 CDT(-0500)] <colinclark> i can only half follow the conversation, but i'll try
[15:20:31 CDT(-0500)] <justin_o> colinclark: thanks
[15:20:33 CDT(-0500)] <colinclark> I think we're going to need to allow users themselves to control hard stops
[15:20:44 CDT(-0500)] <Bosmon> Yes, I think this is an interesting issue on how configuration works
[15:21:00 CDT(-0500)] <Bosmon> But personally I am worried about setting the precedent that changing the configuration, does not mean reinstantiating the component
[15:21:22 CDT(-0500)] <Bosmon> Typically having configuration being "mutable" raises all kinds of fairly deep issues
[15:24:29 CDT(-0500)] <jameswy> I think this should be in the hands of the integrator. I can see cases where turning on and off wrapping shouldn't be manipulated by the user--e.g., cases where it'd change the intended functionality
[15:24:47 CDT(-0500)] <colinclark> jameswy: I don't think it can be limited to the integrator...
[15:25:16 CDT(-0500)] <colinclark> For some users, wrapping is a major efficiency booster. For other users of the exact same interface, it will be a barrier to usability.
[15:25:38 CDT(-0500)] <colinclark> Classic example--sighted, keyboard only users can access the farthest edges of a Reorderer much faster with wrapping
[15:25:47 CDT(-0500)] <Bosmon> I'm not sure I appreciate the distinction between "user" and "integrator" here
[15:25:57 CDT(-0500)] <colinclark> A screen reader user, however, runs the risk of not understanding the boundaries of the thing at all
[15:26:06 CDT(-0500)] <colinclark> "User" means someone who is actually interacting with the Reorderer
[15:26:12 CDT(-0500)] <Bosmon> It appears we have made an implicit equation that "changes made to initialisation configuration" is somehow in the domain of "integrator"
[15:26:23 CDT(-0500)] <colinclark> "Integrator" means someone who has chosen to put the Reorderer into their user interface
[15:26:30 CDT(-0500)] <Bosmon> Right
[15:26:36 CDT(-0500)] <Bosmon> These are people/stakeholders
[15:26:50 CDT(-0500)] <Bosmon> Whereas it appears we are using this distinction to argue for a particular implementation strategy
[15:27:15 CDT(-0500)] <colinclark> I don't think that distinction needs to be made, necessarily
[15:27:32 CDT(-0500)] <Bosmon> The distinction, or the argument?
[15:27:37 CDT(-0500)] <colinclark> The distinction
[15:27:44 CDT(-0500)] <Bosmon> ok
[15:27:45 CDT(-0500)] <colinclark> You're getting into implementation details, which certainly matter...
[15:28:00 CDT(-0500)] <colinclark> but which don't necessarily matter to answering the first part of justin_o's questions
[15:28:08 CDT(-0500)] <jameswy> colinclark: True, but what if the integrator doesn't want the user to wrap? What if it breaks the intended design entirely? e.g., slide puzzles
[15:28:16 CDT(-0500)] <colinclark> Which, if I wasn't too distracted, was "who should be able to control this configuration?"
[15:28:20 CDT(-0500)] <JenC> to illustrate for james: http://www.partiestoyourdoor.co.uk/acatalog/puzzles.jpg
[15:28:43 CDT(-0500)] <colinclark> jameswy: There are certainly cases where you might limit this for a particular kind of application
[15:29:04 CDT(-0500)] <colinclark> But it can't be an absolute decision
[15:29:24 CDT(-0500)] <Bosmon> This is the kind of issue which I think should generally be "taken up" by the IoC system
[15:29:40 CDT(-0500)] <Bosmon> How different configurations resolve themselves in practice should be an issue for IoC and not for the particular component
[15:30:10 CDT(-0500)] <colinclark> Bosmon: I agree, though that doesn't provide us with much help for 1.3, I'm afraid
[15:30:28 CDT(-0500)] <jameswy> Hm. Point taken. Can we have it both ways? Lock wrapping in some cases, and allow the uesr to manipulate it in others? Would the former require an integrator of UI options to disable the option for wrapping?
[15:31:14 CDT(-0500)] <Bosmon> Well - I still think the argument is valid that this isn't anything which should influence the implementation of the component
[15:31:24 CDT(-0500)] <Bosmon> This is just the kind of thing we can't have every component implementor worrying about
[15:31:29 CDT(-0500)] <colinclark>
[15:31:33 CDT(-0500)] <Bosmon> Because, in just this way, they will worry about it every time
[15:31:37 CDT(-0500)] <Bosmon> See the worry!
[15:33:00 CDT(-0500)] <justin_o> Bosmon: What would happen if the wrapping functionality was changed mid way and the component had to be re-instantiated for the changes to take affect.. would they lose their current changes?
[15:33:29 CDT(-0500)] <justin_o> just for fun... here are some javascript slide puzzles http://www.2meter3.de/jqPuzzle/demos.html
[15:33:32 CDT(-0500)] <Bosmon> Well, this is exactly the kind of reason that we fear people making changes to configuration mid-stream
[15:33:48 CDT(-0500)] <Bosmon> Having configuration "static for all time" heads off at least one big class of race condition
[15:34:11 CDT(-0500)] <Bosmon> justin_o: The question is - what is the user value of having a component which "changes" from allowing wrapping to not wrapping dynamically
[15:34:18 CDT(-0500)] <Bosmon> is this any kind of component or effect that a user might want to see?
[15:34:46 CDT(-0500)] <Bosmon> "do people want fire that can be fitted nasally"?
[15:36:39 CDT(-0500)] <justin_o> well i don't know about the fire but i could see someone playing with it and getting confused and wanting to change the setting...
[15:37:20 CDT(-0500)] <justin_o> that's not to say that a reinstantiating the component wouldn't do that, just wondering what the expected effect would be
[15:37:26 CDT(-0500)] <Bosmon> Well - shouldn't it just be that the setting is "right"?
[15:37:43 CDT(-0500)] <justin_o> Bosmon: what is "right"?
[15:37:51 CDT(-0500)] <Bosmon> That is, does a user ever want to see a component that they are interacting with, "right now", change, from being one that supports wrapping, to one that doesn't support wrapping?
[15:38:56 CDT(-0500)] <Bosmon> I'm not sure there is a unique right answer to these questions, but I want to highlight that we are on the edge of very deep issues
[15:40:12 CDT(-0500)] <Bosmon> I guess we need to split the issue apart into several subissues
[15:40:22 CDT(-0500)] <justin_o> Bosmon: okay... that might help
[15:40:33 CDT(-0500)] <Bosmon> i) is this "feature" provably similar or provably distinct to other features with the component supports in this respect
[15:40:56 CDT(-0500)] <Bosmon> ii) when beginning development of a feature, do we expect that the developer can or should reliably determine what "kind" of feature it is
[15:41:42 CDT(-0500)] <Bosmon> That is, "this is a piece of configuration we support changing at runtime" or "we don't"
[15:43:52 CDT(-0500)] <Bosmon> Right now, we have the "model" that "all the useful state associated with this component's behaviour at runtime" is captured by the component's model
[15:44:05 CDT(-0500)] <Bosmon> So - supporting some configuration which is mutable starts to threaten this model....
[15:44:36 CDT(-0500)] <Bosmon> Although clearly that "model" isn't watertight... as you say, there are lots of things which "in practice" are mutable which aren't actually part of the model ... but we certainly aim for them to be there
[15:45:43 CDT(-0500)] <Bosmon> We have this kind of problem in "Repeatable" in CSpace
[15:46:01 CDT(-0500)] <Bosmon> Although, to be sure, we are still only trying to make it adapt to all changes in the MODEL rather than in its configuration
[15:46:12 CDT(-0500)] <Bosmon> But this is a "component which contains other components" which can all be in any number of states
[15:46:49 CDT(-0500)] <Bosmon> We made an attempt to make it adapt to changes in model "differentially" - that is, by only reinstantiating pieces of markup and subcomponent that were absolutely necessary
[15:47:08 CDT(-0500)] <Bosmon> but this exposed so many bugs and obscurities that we had to go back to a "reinstantiate everything at once" model for the time being
[15:47:38 CDT(-0500)] <Bosmon> This highlights that in general it is always easier and more reliable to provide a model for change in component state that simply reinstantiates the entire tree - even if it isn't always the most efficient method
[15:49:58 CDT(-0500)] <justin_o> Bosmon: okay... so i think what you are saying is that if the user wants to change it, the integrator should provide a mechanism... such as a ui options or something to set the configuration
[15:50:17 CDT(-0500)] <justin_o> and this will trigger somehow a reinstantiation of the component with the new configuration to the user
[15:50:56 CDT(-0500)] <Bosmon> Well... I guess I want us to focus more clearly on the two parts of this issue
[15:51:02 CDT(-0500)] <Bosmon> That is, the specific part, and the general part
[15:51:21 CDT(-0500)] <Bosmon> Firstly - is this REALLY a feature of the reorderer that we consider in a different class to the others, that we have implemented so far
[15:51:29 CDT(-0500)] <Bosmon> Or is this feature request simply "accidental"
[15:51:44 CDT(-0500)] <Bosmon> For example - would we want to support a reorderer that can change orientation dynamically from horizontal to vertical?
[15:51:54 CDT(-0500)] <Bosmon> Or one that can change the default tabindex for the reorderables?
[15:52:10 CDT(-0500)] <Bosmon> That is, how "genuinely different" is the key wrapping behaviour to all these other features
[15:52:41 CDT(-0500)] <Bosmon> Secondly.... should we decide that this really is the "kind of thing" we want to support - that is, "dynamic change of configuration" - are we really sure we want to support it on a feature-by-feature basis like this?
[16:08:57 CDT(-0500)] <justin_o> Bosmon: so i think it is different than those other examples you mentioned because while this does slightly change the interaction it is because that interaction itself may be broken for users... that being said... your second part is a good point and i could see us having an infinite number of these cases that we may not want to address one by one
[16:17:17 CDT(-0500)] <colinclark> I think the simplest path forward, at least for the time being, is provide static configuration
[16:17:28 CDT(-0500)] <colinclark> I think in the medium term, hooking this up to UI Options will be essential
[16:18:22 CDT(-0500)] <colinclark> But I think we need to be careful to assume that just because we've exposed a UI Option setting for some configuration, that it won't, in other contexts, need to change (quotes important) "dynamically"
[16:18:35 CDT(-0500)] <colinclark> So, let me give you an example we ran into in a previous project, called Stretch.
[16:18:57 CDT(-0500)] <colinclark> Users could set a global preference for the language that they'd like to see captions in. In my case, it would probably be English
[16:19:25 CDT(-0500)] <colinclark> But I do speak a bit of French
[16:19:41 CDT(-0500)] <colinclark> So, let's say I'm on my iPhone and I forget my headphones
[16:19:50 CDT(-0500)] <colinclark> I really need captions without my headphones
[16:20:00 CDT(-0500)] <colinclark> So, I encounter a video that doesn't have English captions
[16:20:16 CDT(-0500)] <colinclark> There is an "instance-specific" setting that I want here...
[16:20:28 CDT(-0500)] <colinclark> Give me the captions, but I'll take them in French over not having them at all
[16:20:52 CDT(-0500)] <colinclark> justin_o: Does that make any sense, in this somewhat different context?
[16:21:04 CDT(-0500)] <justin_o> colinclark: yep it does...
[16:21:26 CDT(-0500)] <Bosmon> Yes... that's a good example
[16:21:54 CDT(-0500)] <Bosmon> But the question is raises is more in camp ii) - "one" and possibly "the best" strategy for honouring this change in configuration would be to "rerender everything"
[16:22:02 CDT(-0500)] <Bosmon> At least, to rerender the component affected by the change
[16:23:07 CDT(-0500)] <colinclark> So far, I think that strategy is probably our best bet
[16:23:19 CDT(-0500)] <colinclark> It raises the issue that justin_o rightfully points out...
[16:23:31 CDT(-0500)] <justin_o> Bosmon: i'm somewhat worried about the effect it will have.. the lose of data i guess.. so in the case of a video it's probably fine to restart it, but in other cases it may not be... don't have a good colin like example though
[16:23:31 CDT(-0500)] <colinclark> What do we do if users want to reconfigure in the midst of an interaction...
[16:23:37 CDT(-0500)] <colinclark> let's use the Stretch example again
[16:23:44 CDT(-0500)] <colinclark> I'm halfway through a video I don't understand
[16:23:54 CDT(-0500)] <Bosmon> yes
[16:23:54 CDT(-0500)] <colinclark> Show me those captions, just this once, because the user has a thick accent
[16:24:03 CDT(-0500)] <colinclark> It would suck to then get rewound the very beginning of the video
[16:24:07 CDT(-0500)] <colinclark> just because the thing got zapped
[16:24:19 CDT(-0500)] <colinclark> so we'll need some strategy for zapping a thing while retaining its model
[16:24:20 CDT(-0500)] <colinclark> w
[16:24:20 CDT(-0500)] <Bosmon> Yes - I guess this surfaces two things
[16:24:24 CDT(-0500)] <colinclark> which should be perfectly doable
[16:24:36 CDT(-0500)] <colinclark> now, we have no notion of zapping a thing at the moment, either
[16:24:37 CDT(-0500)] <Bosmon> Firstly - to make sure the concept of the "model" of a component is as sound and complete as it can be
[16:24:54 CDT(-0500)] <Bosmon> To maximise the chance we have of "restoring" it correctly, or whatever
[16:25:15 CDT(-0500)] <Bosmon> Secondly - we can indeed "think about" "incremental changes to configuration" - but this really does raise a very big can of worms we don't want to open lightly
[16:25:38 CDT(-0500)] <colinclark> yep
[16:26:42 CDT(-0500)] <Bosmon> Certainly "zapping a thing" is something we were doing all the time, in Fluid Engage
[16:26:58 CDT(-0500)] <Bosmon> But the idea would be to try to formalise this in our "renderer antigens" approach
[16:27:15 CDT(-0500)] <Bosmon> For example - "all of your markup is already there, you just need to tear down and restore event handlers" is an example of this "zapping" of which we speak
[16:41:15 CDT(-0500)] <colinclark> justin_o raised the point that "zapping" the Reorderer is a special case
[16:41:20 CDT(-0500)] <colinclark> compared to, say any component we built for Engage
[16:41:26 CDT(-0500)] <colinclark> a special case that complicates things
[16:41:57 CDT(-0500)] <colinclark> but in general, we should have several relatively straightforward techniques of "zapping"
[16:42:08 CDT(-0500)] <Bosmon> Because, you mean, most configurations of it are not yet adequately "model-based"?
[16:42:11 CDT(-0500)] <colinclark> i.e. the pre-formality of the engage approach
[16:42:24 CDT(-0500)] <colinclark> justin_o: That was your point, right?
[16:42:33 CDT(-0500)] <Bosmon> Actually the ones that don't have a model would be the ones most easiest to zap
[16:42:36 CDT(-0500)] <colinclark> the lack of model
[16:42:48 CDT(-0500)] <Bosmon> but actually so far none of our components have "tear-down" - to remove all their existing event handlers
[16:42:54 CDT(-0500)] <colinclark> right
[16:43:13 CDT(-0500)] <colinclark> I guess this really does lead us down the path towards "antigens"
[16:43:31 CDT(-0500)] <colinclark> Put simply, justin_o and golam, this means separating the two phases of a component...
[16:43:37 CDT(-0500)] <justin_o> colinclark: sounds like it yes
[16:43:45 CDT(-0500)] <Bosmon> Yes
[16:43:46 CDT(-0500)] <colinclark> Rendering markup and attaching a "live" instance of the component to the DOM
[16:43:53 CDT(-0500)] <Bosmon> And actually this goes one level beyond "antigens"
[16:44:02 CDT(-0500)] <Bosmon> "antigens" just required that the two phases be separated
[16:44:14 CDT(-0500)] <colinclark> You can imagine an addendum to this, in that we would need a way of detaching as well
[16:44:18 CDT(-0500)] <Bosmon> but so far our expressions of the concept haven't included that in addition, the components include a "teardown" function
[16:44:22 CDT(-0500)] <Bosmon> exactly
[16:44:24 CDT(-0500)] <colinclark>
[16:44:50 CDT(-0500)] <colinclark> This wouldn't be like a finalize() method in Java, for example, I imagine
[16:44:58 CDT(-0500)] <colinclark> but simply a detach
[16:45:04 CDT(-0500)] <Bosmon> Well... in that it might actually do something useful?
[16:45:13 CDT(-0500)] <colinclark> lol
[16:45:15 CDT(-0500)] <colinclark> yes, exactly
[16:45:24 CDT(-0500)] <Bosmon> But yes, this will be a purely "DOM-directed" thing
[16:45:30 CDT(-0500)] <Bosmon> Special only to components of the "view-bearing grade"
[16:45:44 CDT(-0500)] <colinclark> So, I think we are narrowing in on a few things...
[16:45:54 CDT(-0500)] <colinclark> I'm going to start by scoping this for 1.3
[16:46:26 CDT(-0500)] <colinclark> 1. Changing the configuration of a Reorderer will be achieved by reinstantiating
[16:46:48 CDT(-0500)] <colinclark> 2. We need some way to detach the current instance from the DOM
[16:47:11 CDT(-0500)] <colinclark> And then I guess looking slightly forward, we're going to need some framework supports for this
[16:47:24 CDT(-0500)] <colinclark> Does this seem about right, justin_o and Bosmon?
[16:47:30 CDT(-0500)] <colinclark> and golam
[16:47:58 CDT(-0500)] <Bosmon> Yes, I think so - although on the other hand, we might "in parallel" think about perhaps "announcing" or planning for aspects of component configuration which support dynamic change
[16:48:14 CDT(-0500)] <Bosmon> My thoughts for this would be to do something like actually supporting some kind of "changeApplier" targetted at the component options
[16:48:33 CDT(-0500)] <golam> sounds good
[16:48:33 CDT(-0500)] <Bosmon> And the options that supported change would be announced as part of some kind of "little schema"
[16:48:46 CDT(-0500)] <Bosmon> This would mean that we wouldn't need to develop infrastructure for changing each option one by one
[16:48:46 CDT(-0500)] <colinclark> Bosmon: Wow, crazy
[16:49:03 CDT(-0500)] <colinclark> that is pretty interesting
[16:49:35 CDT(-0500)] <colinclark> so each component would be required to attach changeapplier listeners for the portions of their configuration that can be changed dynamically, which were responsible for actually acting on those changes?
[16:50:01 CDT(-0500)] <Bosmon> Yes... I think that seems like a workable, scalable sort of model
[16:50:41 CDT(-0500)] <colinclark> So a component author would do two things...
[16:51:08 CDT(-0500)] <colinclark> 1. Define a-as you call it-little schema which denotes the changeable configuration paths
[16:51:48 CDT(-0500)] <colinclark> 2. Listen and respond to changes using this options applier
[16:52:05 CDT(-0500)] <colinclark> which I would assume would be provided with the "dynamically configurable" grade or something like that?
[16:52:17 CDT(-0500)] <Bosmon> Yes, that sounds about right
[16:52:22 CDT(-0500)] <colinclark> Okay, that's interesting
[16:52:27 CDT(-0500)] <colinclark> so then a related question
[16:52:35 CDT(-0500)] <Bosmon> Then it would be possible to introspect into the component to discover what things could be changed dynamically, and which required it to be "torn down"
[16:52:58 CDT(-0500)] <colinclark> Okay, this starts to get at my as yet un-asked question
[16:53:11 CDT(-0500)] <colinclark> How do we imagine UI Options will be able to configure components?
[16:53:26 CDT(-0500)] <Bosmon> Yes, I guess that is a great question
[16:53:44 CDT(-0500)] <Bosmon> The easiest route would be for it to configure components "before" they come into existence
[16:53:47 CDT(-0500)] <Bosmon> Using the IoC system
[16:54:09 CDT(-0500)] <Bosmon> So, this JIRA which THER KINGG graciously let me put into Parade is one route for doing this
[16:54:15 CDT(-0500)] <Bosmon> It could "throw tags" into the "dynamic environment"
[16:54:17 CDT(-0500)] <colinclark> Can you send me the link?
[16:54:21 CDT(-0500)] <colinclark> I'm behind on everything today
[16:54:24 CDT(-0500)] <Bosmon> And then ask for the page to be instantiated "withEnvironment"
[16:54:31 CDT(-0500)] <colinclark> interesting
[16:54:46 CDT(-0500)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-3818
[16:54:51 CDT(-0500)] <colinclark> So we'll have type tags for each relevant piece of configuration
[16:55:04 CDT(-0500)] <Bosmon> So, YURA seemed on the verge of wanting this, for CSPace
[16:55:11 CDT(-0500)] <Bosmon> Well... we might have many fewer type tags than that
[16:55:26 CDT(-0500)] <Bosmon> There might be just one, for "This thing is instantiated in the environment of UIOptions"
[16:55:27 CDT(-0500)] <colinclark> I don't mean to sound like I'm complaining...
[16:55:37 CDT(-0500)] <Bosmon> All we need is SOMETHING, which beats the "default configuration"
[16:55:42 CDT(-0500)] <colinclark> I find this ticket description a little less informative than I might like
[16:55:44 CDT(-0500)] <Bosmon> You want more description on the JIRA?
[16:55:44 CDT(-0500)] <Bosmon> Yes
[16:55:48 CDT(-0500)] <Bosmon> I thought you might
[16:55:55 CDT(-0500)] <colinclark> Maybe you can elaborate here and we can paste into the comments
[16:55:57 CDT(-0500)] <Bosmon> I actually spent some time writing it... but wasn't entirely sure what to say
[16:56:00 CDT(-0500)] <colinclark>
[16:56:09 CDT(-0500)] <colinclark> I guess it's a measure of the King's respect for you that he let it on
[16:56:21 CDT(-0500)] <colinclark> Either that, or you must have explained it in detail when I wasn't looking
[16:56:23 CDT(-0500)] <justin_o>
[16:56:55 CDT(-0500)] <Bosmon> Well, I said it would be a very small fix, and something JURA needed for CSpace
[16:56:57 CDT(-0500)] <colinclark> Bosmon: I'm not complaining, just thinking you might want to elaborate here in the chat
[16:57:03 CDT(-0500)] <Bosmon> Other than that I didn't succeed in explaining it very much more
[16:57:04 CDT(-0500)] <colinclark> Since it's all very interesting
[16:57:12 CDT(-0500)] <Bosmon> Well, you would deserve to complain, given a JIRA with this level of description
[16:57:34 CDT(-0500)] <colinclark> lol
[16:57:44 CDT(-0500)] <Bosmon> It really is entirely inadequate
[16:57:47 CDT(-0500)] <colinclark> Sometimes it's easier to show interest than complain
[16:57:51 CDT(-0500)] <colinclark> I guess it maybe is okay
[16:57:53 CDT(-0500)] <Bosmon> hahahaha
[16:58:14 CDT(-0500)] <Bosmon> Yes, sometimes it is better to chew on things than to slash them with a paw
[16:58:19 CDT(-0500)] <colinclark> All you're saying is that, during value resolution, we never look up names in the dynamic environment
[16:58:23 CDT(-0500)] <colinclark> just in the that stack
[16:58:23 CDT(-0500)] <colinclark> a
[16:58:27 CDT(-0500)] <Bosmon> yes
[16:58:32 CDT(-0500)] <colinclark> and presumably the fix is to add that ability
[16:58:37 CDT(-0500)] <Bosmon> Assuming someone understands all of these terms, the JIRA is "moderately clear"
[16:58:47 CDT(-0500)] <Bosmon> But to be sure, these terms barely existed before that IRC chat with AC 2 weeks back
[16:58:51 CDT(-0500)] <colinclark> I guess it actually makes sense to me, having stepped through the process of IoC resolution in the debugger
[16:59:10 CDT(-0500)] <colinclark> Okay, so do you know if AC documented the terminology?
[16:59:22 CDT(-0500)] <Bosmon> I think she did use it in some docs, yes
[16:59:23 CDT(-0500)] <Bosmon> Let me look
[17:00:07 CDT(-0500)] <Bosmon> hmm
[17:00:10 CDT(-0500)] <Bosmon> I don't see that she did
[17:00:18 CDT(-0500)] <Bosmon> Perhaps only in that mail she sent me privately
[17:00:38 CDT(-0500)] <colinclark> The dynamic environment is implemented as a "thread local" object, right? So, an object hanging off the fluid namespace when we're in the browser?
[17:00:44 CDT(-0500)] <colinclark> I guess I could just go look at the code
[17:01:24 CDT(-0500)] <Bosmon> I think the dynamic environment is never public
[17:01:29 CDT(-0500)] <colinclark> ok
[17:01:32 CDT(-0500)] <Bosmon> Resolution of the "dynamic environment" is itself donw through IoC
[17:01:32 CDT(-0500)] <colinclark> only the static env
[17:01:44 CDT(-0500)] <Bosmon> There is just an IoC-resolved "invoker" by the name of "fluid.threadLocal()"
[17:01:50 CDT(-0500)] <colinclark>
[17:01:55 CDT(-0500)] <colinclark> let me have a look at this
[17:02:39 CDT(-0500)] <Bosmon> Which is just a "thing which returns an object"
[17:03:49 CDT(-0500)] <colinclark> yep, it seems to make sense
[17:04:57 CDT(-0500)] <colinclark> So I guess there's a process where we'll have to convert UI Options preferences into type tags that get stuffed into the environment each time a page is loaded
[17:06:14 CDT(-0500)] <colinclark> Bosmon: Am I making sense?
[17:06:41 CDT(-0500)] <Bosmon> Well, as I was beginning to say, there may only really be ONE "type tag" representing the "UI Options Environment" itself
[17:06:53 CDT(-0500)] <Bosmon> And lots of "demands blocks" for all the different components in that environment
[17:07:01 CDT(-0500)] <colinclark> hmm
[17:07:29 CDT(-0500)] <colinclark> Can you make that more concrete by using an example?
[17:09:05 CDT(-0500)] <Bosmon> So... say the "type tag" is something like "fluid.UIOptionsEnvironment"
[17:09:50 CDT(-0500)]

[17:09:52 CDT(-0500)] <Bosmon> Or something like this
[17:10:06 CDT(-0500)] <Bosmon> That is, the "type tag" used for "function resolution" need not match anything used during "value resolution"
[17:10:14 CDT(-0500)] <Bosmon> In theory they could be the same
[17:10:21 CDT(-0500)] <Bosmon> But the info might come from any number of places
[17:11:18 CDT(-0500)] <colinclark> Okay, I think this makes sense
[17:12:01 CDT(-0500)] <Bosmon> When we do "component-tree based IoC" clearly there is a strong bias for the function resolution context to match the value resolution context
[17:12:05 CDT(-0500)] <Bosmon> But even then, they need not
[17:12:28 CDT(-0500)] <Bosmon> It's just that, "being interested in being in the environment of a particular component", it might be quite likely that the values you want to fish out are drawn from that component
[17:13:05 CDT(-0500)] <Bosmon> I guess there's no real reason for them to be different in the example I made...
[17:13:52 CDT(-0500)] <colinclark> I assume in the case of UI Options, it won't actually be UI Options where values are drawn from...
[17:14:04 CDT(-0500)] <Bosmon> Well, not "the component itself", no
[17:14:05 CDT(-0500)] <colinclark> we'll need preferences from the server, probably cached in a cookie or with local data storage
[17:14:10 CDT(-0500)] <Bosmon> right