...
[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