...
[13:50:14 CDT(-0500)] <Justin_o> colinclark: so the issue with 1) is mostly about duplication
[13:50:44 CDT(-0500)] <colinclark> sorry I'm only now finally catching up to you, Justin_o
[13:50:49 CDT(-0500)] <colinclark> and for making you repeat yourself
[13:52:01 CDT(-0500)] <Justin_o> colinclark: and it was seeming that the work to produce to make the component as well as maintaining seemed to not be worth it given the perceived (although debatable) ease of just using the builder directly as it is in the demo
[13:52:14 CDT(-0500)] <Justin_o> colinclark: although the demo example could be too simplistic i suppose
[13:53:18 CDT(-0500)] <colinclark> I guess some of it is maybe philosophical
[13:53:30 CDT(-0500)] <colinclark> but most of it, I think, is about user-friendliness
[13:53:54 CDT(-0500)] <colinclark> anastasiac's responses to the "plain English" questions suggest a perspective we want to try to accommodate
[13:53:57 CDT(-0500)] <colinclark> I think
[13:54:05 CDT(-0500)] <colinclark> I mean, we always have to measure the cost of these things
[13:54:47 CDT(-0500)] <colinclark> but I really can imagine, at one level of usage, that I as a developer, want to get my hands on a thing that I can reliable say IS a UI Options component, or is an Exploration Tool Component, or is a PMT
[13:54:50 CDT(-0500)] <colinclark> and so on
[13:55:08 CDT(-0500)] <colinclark> perhaps I'm putting too fine a point on it
[13:55:57 CDT(-0500)] <colinclark> but I think anastasiac was saying that 1) she likes that we can teach a user how to do one thing instead of two or three, which we've already accomplished and 2) she'll have to do extra work to explain what a builder is and what it produces
[13:56:12 CDT(-0500)] <colinclark> Bosmon: Any thoughts, technically, on what the best way is to accomplish this?
[13:56:22 CDT(-0500)] <colinclark> Do either of Justin_o
[13:56:30 CDT(-0500)] <colinclark> 's ideas resonate with you?
[13:56:51 CDT(-0500)] <colinclark> michelled: Did you have any look combing through some UIO-using source code for signs of classname trouble?
[13:56:58 CDT(-0500)] <colinclark> "any luck" that is
[13:57:37 CDT(-0500)] <Bosmon> colinclark - could you expand on your question slightly - or, perhaps narrow it?
[13:57:52 CDT(-0500)] <Bosmon> "I want to get my hands on a thing which I can reliably say IS a UI Options component"
[13:58:01 CDT(-0500)] <Bosmon> Which part of this problem would we like to assist with?
[13:58:27 CDT(-0500)] <colinclark> I think Justin's explanation deals with the technical problems
[13:59:24 CDT(-0500)] <colinclark> the user experience issue is largely one of providing a user with a single means for instantiating what they see as the UIO component, and ensuring it has a recognizable grade associated with it so they could, at some point, issue IoC configuration against it
[13:59:31 CDT(-0500)] <colinclark> I think, anyway 
[14:00:11 CDT(-0500)] <colinclark> I think that latter point is what Justin_o means when he says "we probably couldn't map it to fluid.uiOptions this way and preserve all of the contract that a typical infusion component would have"
[14:00:21 CDT(-0500)] <Bosmon> Yes
[14:00:58 CDT(-0500)] <Bosmon> I think we have to abandon the idea of a "single means"
[14:01:07 CDT(-0500)] <Bosmon> As I think parts of our discussion have suggested
[14:01:07 CDT(-0500)] <colinclark> hmm
[14:01:14 CDT(-0500)] <colinclark> what does that mean, specifically?
[14:01:30 CDT(-0500)] <Bosmon> It means that the name "fluid.uiOptions" couldn't expect to designate different things to different people
[14:01:43 CDT(-0500)] <colinclark> Yes, that's fine
[14:02:07 CDT(-0500)] <colinclark> When I said "single means," I was referring to there being a component that represented the whole of "that UIO component up there" to user #1s
[14:02:11 CDT(-0500)] <Bosmon> Yes
[14:02:22 CDT(-0500)] <Bosmon> We should do this, and it would not be a problem
[14:02:39 CDT(-0500)] <Bosmon> Although I can't remember whether the "builder" can be directed to fabricate a component with a particular name, but if it can't, it should
[14:02:46 CDT(-0500)] <colinclark> I was just going to suggest...
[14:03:05 CDT(-0500)] <colinclark> the ability for a "user" of the builder to be able to contribute grades to the thing that gets produced
[14:03:12 CDT(-0500)] <colinclark> or something like this?
[14:03:13 CDT(-0500)] <Bosmon> It seems that the "auxSchema" can include a naemsapce
[14:03:26 CDT(-0500)] <Bosmon> namespace
[14:03:45 CDT(-0500)] <colinclark> Are there other aspects of "the contract that a typical Infusion component would have" that I should keep in mind, Justin_o?
[14:03:47 CDT(-0500)] <Justin_o> Bosmon: yes it can take a namespace, but you would get something like fluid.uiOptions.prefsEditor
[14:04:32 CDT(-0500)] <anastasiac> Bosmon, could you elaborate on how this would work? would the "fluid.uiOptions" component have the builder as a subcomponent? Would it be a wrapper function that creates the builder then invokes the constructed grade? other?
[14:04:49 CDT(-0500)] <Bosmon> It appears that it used to call itself "fluid.uiOptions.constructed"
[14:04:50 CDT(-0500)] <colinclark> hopefully other
[14:05:13 CDT(-0500)] <anastasiac> yes, that's the default namespace if none is provided (updated to "fluid.prefs.constructed")
[14:05:25 CDT(-0500)] <Bosmon> anastasiac - it would work as it works now, the builder constructs a grade with a known name
[14:05:44 CDT(-0500)] <anastasiac> so the integrator still has to create the builder then run the function? still two steps?
[14:05:56 CDT(-0500)] <anastasiac> I thought we were trying to get it down to one step
[14:06:11 CDT(-0500)] <Bosmon> So when we restore our "UIO" component, in addition to containing some of the code present in the "prefsEditorDemo", it will also define a name that is not silly
[14:06:12 CDT(-0500)] <Justin_o> colinclark: it's a real grade that gets produced but if you did something like fluid.uiOptions = outputOfBuilder then I would assume the name wouldn't exist in any IoC related context of to calls to fluid.defaults
[14:06:27 CDT(-0500)] <colinclark> right
[14:06:30 CDT(-0500)] <Bosmon> Justin_o - see my remark earlier about a sensible name
[14:06:34 CDT(-0500)] <Bosmon> anastasiac, likewise
[14:06:42 CDT(-0500)] <Bosmon> We will put this component "back into the frameworK"
[14:06:53 CDT(-0500)] <Bosmon> And so the demo will contain FEWER steps, not more
[14:06:54 CDT(-0500)] <Bosmon> fewer!
[14:07:37 CDT(-0500)] <anastasiac> so what will the component look like? what will its relationship to the builder be?
[14:07:49 CDT(-0500)] <Bosmon> It's relationship to the builder, will be that it is BUILT by the builder
[14:08:00 CDT(-0500)] <Justin_o> Bosmon: i assume what you are saying is that we run a build and use it's output
[14:08:07 CDT(-0500)] <Bosmon> Justin_o - that is right
[14:08:35 CDT(-0500)] <Justin_o> Bosmon: so maybe we just call fluid.defaults("fluid.uiOptions", {gradeNames: ["outputFromBuilderGrade", "autoInit"]
[14:08:36 CDT(-0500)] <anastasiac> so the integrator still has two steps. 1) create the builder, 2) invoke the function
[14:08:39 CDT(-0500)] <Justin_o> something like that
[14:08:51 CDT(-0500)] <Bosmon> Justin_o - that's another option, yes
[14:09:07 CDT(-0500)] <Bosmon> anastasiac - the integrator just has ONE step
[14:09:09 CDT(-0500)] <Justin_o> anastasiac: no i think thats in the uiOptions.js, so a user would directly interact with the outputed grade
[14:09:10 CDT(-0500)] <Bosmon> "instantiate the component"
[14:09:26 CDT(-0500)] <anastasiac> ok, I'm clearly not understanding something
[14:09:37 CDT(-0500)] <anastasiac> my understanding of "the component" is that it's something created by the builder
[14:09:40 CDT(-0500)] <anastasiac> that's not the case?
[14:09:42 CDT(-0500)] <Justin_o> anastasiac: i'll make a pastie.. one second
[14:09:44 CDT(-0500)] <Bosmon> anastasiac - that is the case
[14:09:48 CDT(-0500)] <colinclark>
[14:09:52 CDT(-0500)] <colinclark> awesome, thanks Justin_o
[14:10:01 CDT(-0500)] <colinclark> So, I guess to wrap up the main part of this
[14:10:09 CDT(-0500)] <colinclark> 1. Sorry to distract you all with going over this again
[14:10:14 CDT(-0500)] <colinclark> 2. It's been very informative
[14:10:30 CDT(-0500)] <colinclark> 3. We should, before shipping 1.5, provide this kind of affordance for users
[14:10:48 CDT(-0500)] <colinclark> 4. I'll send out an email to users of the preferences framework giving them a heads up that the renaming has happened
[14:11:43 CDT(-0500)] <colinclark> 5. We still need to figure out if we've got a subtle problem related to the CSS renaming
[14:11:59 CDT(-0500)] <colinclark> I think michelled is on that latter mission
[14:12:33 CDT(-0500)] <michelled> there is definitely use of uio theme names in the oercommons source
[14:12:58 CDT(-0500)] <michelled> it's actually the strategy that we recommend to make a site conform nicely when a theme is chosen
[14:13:24 CDT(-0500)] <colinclark> that's exactly what I was afraid of
[14:13:31 CDT(-0500)] <colinclark> Can you also check out they instantiate UIO?
[14:13:45 CDT(-0500)] <colinclark> does it more or less reflect our tutorial, or are they doing anything fancy?
[14:16:16 CDT(-0500)] <Justin_o> sorry about the delay.. my computer decided to lock up for a bit.. probably all the instances of sublime i'm running
[14:16:24 CDT(-0500)] <Justin_o> http://pastie.org/private/pftaoeghqsg12wn6anjqg
[14:16:25 CDT(-0500)] <colinclark> no worries
[14:17:24 CDT(-0500)] <Justin_o> Bosmon, colinclark, anastasiac: does it look okay?
[14:18:33 CDT(-0500)] <Bosmon> Justin_o - something like that, yes - although it might be more helpful if we could get some insight into what the constructed grade name actually is in any case, and guide it to be something helpful
[14:18:40 CDT(-0500)] <anastasiac> it looks lovely
[14:18:53 CDT(-0500)] <Bosmon> I guess by default it will be something like fluid.uiOptions.constructed.something?
[14:19:07 CDT(-0500)] <anastasiac> the constructed grade name is now in the "fluid.prefs.constructed"
[14:19:14 CDT(-0500)] <anastasiac> you get "prefsEditor" and "uio"
[14:19:23 CDT(-0500)] <anastasiac> so "fluid.prefs.constructed.prefsEditor"
[14:19:36 CDT(-0500)] <anastasiac> if you override the namespace with "footer" you can then use "foofer.prefsEditor"
[14:19:53 CDT(-0500)] <anastasiac> s/footer/foofer
[14:21:04 CDT(-0500)] <Bosmon> So perhaps we could achieve fluid.uiOptions.prefsEditor?
[14:21:09 CDT(-0500)] <Bosmon> Simply through configuration to the builder?
[14:21:28 CDT(-0500)] <anastasiac> yes, easily
[14:21:33 CDT(-0500)] <Justin_o> Bosmon: yes, that would be easy
[14:22:23 CDT(-0500)] <Justin_o> Bosmon: the question would be is that what we'd want?
[14:22:46 CDT(-0500)] <Bosmon> I think it has some things in its favour
[14:22:58 CDT(-0500)] <Justin_o> i just really mean the name
[14:23:03 CDT(-0500)] <Bosmon> For example, it helps to bridge the gaps between the worlds of users #1 and #2
[14:23:06 CDT(-0500)] <Bosmon> yes
[14:23:07 CDT(-0500)] <Justin_o> i like the 1 less step
[14:23:13 CDT(-0500)] <Bosmon> It is a name that can be "naturally achieved"
[14:23:21 CDT(-0500)] <Bosmon> And so it is clearer to users how they might naturally achieve other things
[14:23:34 CDT(-0500)] <Bosmon> As well as giving them easy access to all the other grade names that are constructed in the same step
[14:24:49 CDT(-0500)] <Justin_o> fluid-everyone: are you okay with fluid.uiOptions.prefsEditor as the packaged component for the preference framework
[14:25:02 CDT(-0500)] <colinclark> yup, I'm fine with it
[14:25:12 CDT(-0500)] <colinclark> and other prefsEditors will likely mirror this approach?
[14:25:20 CDT(-0500)] <colinclark> pga.explorationTool.prefsEditor?
[14:25:26 CDT(-0500)] <colinclark> or whatever
[14:25:56 CDT(-0500)] <anastasiac> seems ok to me
[14:26:03 CDT(-0500)] <Justin_o> okay.. i'll just reopen FLUID-5161 and we can make the necessary changes
[14:26:37 CDT(-0500)] <Justin_o> cindyli: did you want to make these changes or would you like me too.. i don't mind doing it.. up to you
[14:27:49 CDT(-0500)] <cindyli> Justin_o: go ahead to make changes since you seem to be more clear about all these
[14:28:41 CDT(-0500)] <Justin_o> cindyli: okay
[14:29:51 CDT(-0500)] <cindyli> thanks, Justin_o
[14:41:17 CDT(-0500)] <michelled> colinclark: in terms of your earlier question, oercommons is mostly following the tutorial. There is one listener being added programatically in the green site, but it should be a simple fix
[14:41:28 CDT(-0500)] <colinclark> ok
[14:41:31 CDT(-0500)] <colinclark> well, there you go
[14:41:39 CDT(-0500)] <colinclark> so the CSS issue isn't a trivial one
[14:41:50 CDT(-0500)] <colinclark> Have the stylesheets changed much amidst all this refactoring, Justin_o?
[14:41:54 CDT(-0500)] <michelled> nope, it's not
[14:41:59 CDT(-0500)] <colinclark> aside from the names
[14:46:26 CDT(-0500)] <colinclark> michelled: do you think it would be crazy to ship two copies of the UIO stylesheets?
[14:46:42 CDT(-0500)] <colinclark> Or doubled definitions of everything, half of them marked deprecated?
[14:52:01 CDT(-0500)] <michelled> I'd rather see two copies of the stylesheets instead of double definitions
[14:52:25 CDT(-0500)] <michelled> I imagine we could modify the css generation code to generate the two copies
[14:52:49 CDT(-0500)] <michelled> or maybe we should make another build target?
[14:53:20 CDT(-0500)] <colinclark> Either one would be fine
[14:53:55 CDT(-0500)] <colinclark> Despite my typically aggressive "I want to break backwards compatibility" stance these days, I think we should plan for something before we cut 1.5
[14:54:16 CDT(-0500)] <colinclark> I worry that the "accessibility is too hard" set will just see this as further fuel for the fire