fluid-work IRC Logs-2013-09-13

[08:39:26 CDT(-0500)] <amilchev> Justin_o: hi there

[08:39:36 CDT(-0500)] <amilchev> Justin_o: thanks for the comment in the list

[08:39:47 CDT(-0500)] <Justin_o> amilchev: hello, no problem. hope it was helpful

[08:41:01 CDT(-0500)] <amilchev> Justin_o: on the question you asked, I didn't write combobox.js myself, I got it ready and modificated one or two things

[08:43:26 CDT(-0500)] <amilchev> Justin_o: it was helpful indeed, I learned how to declaratively call jQuery funcs

[08:44:27 CDT(-0500)] <Justin_o> amilchev: where did you get combobox.js from and what changes did you make to it?

[08:45:26 CDT(-0500)] <amilchev> Justin_o: http://jqueryui.com/autocomplete/#combobox - click on "view source"

[08:47:29 CDT(-0500)] <Justin_o> amilchev: oh i see

[08:48:17 CDT(-0500)] <amilchev> Justin_o: what I edited was mainly to trigger change event after line 67 (and remove some unneeded stuff like like 164-5-6)

[08:50:05 CDT(-0500)]

[08:51:08 CDT(-0500)] <amilchev> Justin_o: in the console, when I type hook.locate("auditoryOutLanguage").combobox() still doesn't find it (any other jQuery func like hide or show works) (hook is the panel)

[08:51:32 CDT(-0500)] <amilchev> so it's not like the func is added after it was called, it isn't added at all

[08:52:03 CDT(-0500)] <Justin_o> amilchev: i would image that this would actually have created a combobox hook.locate("auditoryOutLanguage").combobox()

[08:52:20 CDT(-0500)] <Justin_o> but it didn't?

[08:52:23 CDT(-0500)] <amilchev> no

[08:52:25 CDT(-0500)] <amilchev> it doesn't

[08:52:51 CDT(-0500)] <amilchev> returns TypeError: Object [object Object] has no method 'combobox'

[08:53:35 CDT(-0500)] <amilchev> $("#auditoryOutLanguage").combobox() works

[08:54:05 CDT(-0500)] <Justin_o> amilchev: okay.. i think i know what the issue is.. but for starters you don't need this line $(function() {

[08:54:06 CDT(-0500)] <Justin_o> $( "#combobox" ).combobox();

[08:54:07 CDT(-0500)] <Justin_o> });

[08:54:20 CDT(-0500)] <Justin_o> amilchev: I think that's just the initialization from the demo..

[08:54:44 CDT(-0500)] <Justin_o> amilchev: also the problem you are having probably has to do with the issue i mentioned with two versions of jQuery on the page

[08:56:15 CDT(-0500)] <Justin_o> amilchev: what you have done is to basically create a jQuery plugin that you've added to the jQuery object, but this is the 1.9.1 version that you imported. However infusion is using its own version of infusion, which doesn't have this plugin attached to it.

[08:57:05 CDT(-0500)] <Justin_o> amilchev: because the 1.9.1 version was added after infusion.. all new calls to jQuery use it. which is why calling $("#auditoryOutLanguage").combobox() works

[08:57:31 CDT(-0500)] <amilchev> Justin_o: yes, I thought of that..

[08:59:16 CDT(-0500)] <Justin_o> amilchev: you should be able to drop jQuery 1.9.1 without any issues, as I think jQueryUI works with older versions of jQuery. However, you may run into issues as I see you are also using the new version of jQueryUI.

[08:59:41 CDT(-0500)] <Justin_o> infusion also includes an older version of this, so you may still run into the version conflicts with it.

[09:00:32 CDT(-0500)] <amilchev> Justin_o: in the next month or two that perhaps would not be a problem, sure?

[09:01:56 CDT(-0500)] <Justin_o> amilchev: yes.. we should be upgrading our jQuery dependencies in roughly that time frame..

[09:02:32 CDT(-0500)] <Justin_o> amilchev: so it looks like the autocomplete component existed in jQuery 1.8 which is what is currently in infusion http://api.jqueryui.com/1.8/autocomplete/

[09:04:26 CDT(-0500)] <amilchev> Justin_o: hm.. $.fn.jquery in the console returns "1.7.2" to me .. I guess I'm not using the latest infusion

[09:06:18 CDT(-0500)] <Justin_o> amilchev: so you can try just removing the jQuery and jQueryUI imports you have and see if things still work.. although there may have been changes to the widget factory which may cause your plugin to break. You might also want to explore making this an infusion type component instead of a jQuery function. you can just create a wrapper around it similar to what has been done in textfieldslider

[09:06:19 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/TextfieldSlider.js. It's often a good idea to wrap 3rd party dependencies when you can.

[09:06:51 CDT(-0500)] <Justin_o> amilchev: that's correct.. the version of jQuery is 1.7.2, but we use jQuery UI 1.8.18

[09:07:01 CDT(-0500)] <Justin_o> amilchev: https://github.com/fluid-project/infusion/blob/master/ReleaseNotes.txt

[09:07:57 CDT(-0500)]

[09:08:14 CDT(-0500)] <amilchev> doesn't work

[09:09:19 CDT(-0500)] <Justin_o> amilchev: noConflict won't really help you here I don't think, but anyways, that prevents conflicts from happening later.. so you would have used that in between infusion and the new jQuery. it basically just frees up the jQuery namespace

[09:11:01 CDT(-0500)] <amilchev> Justin_o: so what do you suggest?

[09:12:09 CDT(-0500)] <amilchev> don't tell me I have to change the whole of it...

[09:20:50 CDT(-0500)] <Justin_o> amilchev: personally i would have written it as a infusion component. But i can understand why you would want to use this style. colinclark, Bosmon, yzen, and michelled might have opinions on which route to take. In the meantime if you want to continue using the plugin style my first suggestion would be to drop the new jQuery and jQuery UI dependencies that you are bringing in and instead just bring in the 1.8

[09:20:50 CDT(-0500)] <Justin_o> version of the autocomplete widget (as well as any of its dependencies that we don't already have in infusion, if any). If this works then you are good. If not, you will need to figure out what changes are needed probably from looking at the release notes or upgrade docs between the versions. Also, you should make sure you properly attribute where the code came from that you are modifying and make sure that it i

[09:20:51 CDT(-0500)] <Justin_o> appropriately licensed.

[09:22:23 CDT(-0500)] <Justin_o> amilchev: these are the jQueryUI parts we bring in https://github.com/fluid-project/infusion/tree/master/src/lib/jquery/ui/js

[09:26:37 CDT(-0500)] <amilchev> Justin_o: so I should stick to http://api.jqueryui.com/1.8/autocomplete/

[09:27:39 CDT(-0500)] <amilchev> in other words, use

[09:27:39 CDT(-0500)] <amilchev> <script src="http://code.jquery.com/jquery-1.8.2.js"></script>

[09:27:39 CDT(-0500)] <amilchev> <script src="http://code.jquery.com/ui/1.8.24/jquery-ui.js"></script>

[09:27:51 CDT(-0500)] <amilchev> is that right

[09:28:09 CDT(-0500)] <Justin_o> amilchev: ah.. no.. you can drop both of those

[09:29:31 CDT(-0500)] <Justin_o> amilchev: it would mean pulling in just the autocomplete file https://github.com/jquery/jquery-ui/blob/1-8-stable/ui/jquery.ui.autocomplete.js

[09:29:44 CDT(-0500)] <amilchev> does jQuery UI 1.8.18 support the autocomplete

[09:29:48 CDT(-0500)] <Justin_o> you'll probably need to download and add it to the lib directory and reference it from there

[09:30:37 CDT(-0500)] <Justin_o> amilchev: seems like it, in infusion we have only pulled in the widgets we use, which is why you'd have to add this one in sepearately

[09:30:52 CDT(-0500)] <amilchev> Justin_o: now I get it, ok

[09:33:02 CDT(-0500)] <Justin_o> amilchev: cool… let us know how that goes… and i guess we can chat at the next meeting about whether we should use the jQueryUI plugin style or infusion component wrapper..

[09:35:15 CDT(-0500)] <amilchev> Justin_o: I'm about to leave soon.. if you have any more ideas, suggestions, anything that could help .. I'd love to hear it as deadlines are approaching

[09:35:42 CDT(-0500)] <Justin_o> amilchev: can't think of anything at the moment

[09:37:04 CDT(-0500)] <amilchev> Justin_o: ok, thank you for the time then

[09:37:19 CDT(-0500)] <Justin_o> no problem.. any time

[09:37:28 CDT(-0500)] <amilchev> bye

[13:56:53 CDT(-0500)] <Bosmon> Hi Justin_o, cindyli

[13:57:04 CDT(-0500)] <Bosmon> How is work going with your composite renderin gradE?

[13:57:52 CDT(-0500)] <Justin_o> Bosmon: actually cindyli and I needed to talk to you about that.. we are still kind of confused about how things should all be put together.

[13:58:27 CDT(-0500)] <Justin_o> Bosmon: here's the jira again http://issues.fluidproject.org/browse/FLUID-5131

[13:59:44 CDT(-0500)] <Justin_o> Bosmon: from our previous chat in the channel on sept 10 you said "Well, ironically, you don't really want a "combined template" since that's exactly what the renderer for the component panels can't accept" what did you mean by this exactly?

[14:00:59 CDT(-0500)] <Bosmon> It's because the renderers for the component panels need individual templates

[14:02:01 CDT(-0500)] <Justin_o> Bosmon: okay.. i guess that is in the case where cindyli was saying we use this for uiOptions itself.. but i'm not sure how this translates for the complex panel case

[14:02:15 CDT(-0500)] <Justin_o> if we are considering using grade merging for the panel

[14:02:43 CDT(-0500)] <Bosmon> I expect not "merging" but "composing" - that is, producing a grade which contains the component panels as subcomponents

[14:02:51 CDT(-0500)] <Bosmon> How far have you got with your implementation now?

[14:06:40 CDT(-0500)] <Justin_o> Bosmon: well as far the jira.. we've been scratching our heads because we were thinking you had intended us to use grade merging… as the initial discussion had been about this and then this was brought up 'YOu will need to create a special "grade-combining grade"'

[14:07:10 CDT(-0500)] <Bosmon> Well you can "merge" grades in any number of ways : P

[14:07:24 CDT(-0500)] <Justin_o> Bosmon: hmm.. now i'm confused again

[14:07:42 CDT(-0500)] <Justin_o> Bosmon: so the individual parts of the panels should be subcomponents or grades that are all merged into one?

[14:08:01 CDT(-0500)] <Bosmon> Justin_o - whichever is appropriate : P

[14:08:03 CDT(-0500)] <Bosmon> Most likely the former

[14:08:14 CDT(-0500)] <Bosmon> Surely you haven't been scratching your heads about that for 3 days? : P

[14:10:16 CDT(-0500)] <Justin_o> Bosmon: this is the e-mail thread on the issue i started last month. where i outlined to possible options 1) grade merging and 2) using subcomponents http://fluid.2324889.n4.nabble.com/Combining-complex-panels-in-the-preferences-framework-td8799.html

[14:10:50 CDT(-0500)] <Justin_o> Bosmon: don't worry we did spend all of three days scratching our heads just a bit hear and there, we've had a lot of other things to keep us busy

[14:12:03 CDT(-0500)] <jhung> Justin_o: sent a pull request for GPII-207.

[14:12:17 CDT(-0500)] <Bosmon> Hi Justin_o - sorry to have missed your mail

[14:12:22 CDT(-0500)] <Justin_o> jhung: thanks.. i probably won't have time to look at it today, but i'll check it out on monday

[14:12:32 CDT(-0500)] <jhung> cindyli: I'll take a look at GPII-193 now

[14:12:39 CDT(-0500)] <jhung> Justin_o: sure no prob.

[14:12:53 CDT(-0500)] <Justin_o> Bosmon: no problem

[14:15:14 CDT(-0500)] <Justin_o> Bosmon: so my initial e-mail didn't hit on the need for the multiple templates yet.. so that part isn't considered there.. although i'm pretty sure it gets brought up later in the thread.. one of the biggest annoyances with the subcomponents as they are is the need to configure the modelRelay between each subcomponent and the panel

[14:15:33 CDT(-0500)] <Justin_o> and passing along the message bundles too

[14:15:35 CDT(-0500)] <Bosmon> Justin_o - it should be possible to do this automatically

[14:15:40 CDT(-0500)] <Bosmon> This is what I meant by a "grade-combining grade"

[14:15:48 CDT(-0500)] <Bosmon> Given you know where all of the relevant pieces of model are

[14:16:27 CDT(-0500)] <Justin_o> Bosmon: yes.. definitely building some tooling around this would be essential, but how would we do it automatically.. we don't really know the model paths of the subcomponents

[14:17:18 CDT(-0500)] <Justin_o> also not sure if passed the parent bundle down correctly..

[14:17:42 CDT(-0500)] <Bosmon> Justin_o - you do know the model paths of the subcomponents, since presumably you already generated them from the aux schema ....

[14:18:02 CDT(-0500)] <Bosmon> And even if you didn't, they still expose the same metadata that they did to the aux schema building process, allowing you to build them again

[14:18:52 CDT(-0500)] <Justin_o> Bosmon: okay.. i think i see where you are headed.. i was hoping to get to the changes necessary in the schema next, but seems like we will need a schema to create this.. and that those not using the schema will have to manually create something that looks like what is in the e-mail thread.. does that sound about right?

[14:19:44 CDT(-0500)] <Bosmon> Justin_o - I guess you could call the thing you make a "schema", yes - although you could just inspect the existing component tree

[14:20:21 CDT(-0500)] <Justin_o> Bosmon: oh you mean from the preference map?

[14:20:47 CDT(-0500)] <Bosmon> Justin_o - yes, the preferences map

[14:21:05 CDT(-0500)] <Justin_o> Bosmon: right now only panels and enactors have preference maps

[14:21:22 CDT(-0500)] <Bosmon> Justin_o - but it is panels we are talking about

[14:21:22 CDT(-0500)] <Justin_o> i would imagine that these components here would just be plain infusion components

[14:21:35 CDT(-0500)] <Bosmon> Justin_o - they couldn't be, how could they be integrated into UIOptions?

[14:21:52 CDT(-0500)] <Bosmon> "a plain infusion component" isn't a "UIOptions panel"

[14:21:57 CDT(-0500)] <Justin_o> Bosmon: i think we're talking at different levels again

[14:22:20 CDT(-0500)] <Bosmon> Well, we aren't coming up with a general solution to fix the renderer, we are talking exclusively about UIOptions panels here

[14:22:21 CDT(-0500)] <Justin_o> Bosmon: so right now i'm just talking about creating a panel that is composed of a many parts..

[14:22:30 CDT(-0500)] <Justin_o> Bosmon: for sure

[14:22:59 CDT(-0500)] <Bosmon> Justin_o - but in fact, each of these "parts" is in fact rendering a UIOptions preference

[14:23:04 CDT(-0500)] <Justin_o> Bosmon: basically to creat panels like http://wiki.fluidproject.org/display/fluid/%28C4A%29+Preference+Editor+adjuster+mockups+for+iteration+2#id-%28C4A%29PreferenceEditoradjustermockupsforiteration2-5.Fullyexpandedviewshowingexamplesofhoveranddrop-downfunctionality%28contrastdeactivated%29

[14:23:10 CDT(-0500)] <Bosmon> Therefore these "parts" should be integrated properly into the UIOptions infrastructure

[14:23:23 CDT(-0500)] <Bosmon> It's no good abandoning all of the work that we just put so much mental effort into : P

[14:24:23 CDT(-0500)] <Bosmon> As you mentioned before, you'll find it impossible to efficiently produce the "grade-combining grade" necessary to aggregate the panels together, without making use of elements like the preferencesMap structure that we already required for the aux builder

[14:24:54 CDT(-0500)] <Justin_o> Bosmon: i'm still envisioning that the panel will know that it is related to the UIO, but does the individual component need to? At some level it can't really.. since we would have a slider that we use for perference x and preference y.. it should really be associated with either.

[14:25:13 CDT(-0500)] <Bosmon> Justin_o - of course the slider is associated with a preference!

[14:25:28 CDT(-0500)] <Justin_o> Bosmon: even the textFieldSlider we have now isn't

[14:25:34 CDT(-0500)] <Justin_o> but the panel it is in, is

[14:25:40 CDT(-0500)] <Bosmon> Justin_o - the textFieldSlider isn't a panel

[14:25:42 CDT(-0500)] <Justin_o> that's why panels have to be unique in a way

[14:25:49 CDT(-0500)] <Justin_o> Bosmon: yes exactly

[14:26:33 CDT(-0500)] <Bosmon> Justin_o - do you see any UI widgets in that mockup that aren't associated with a preference? : P

[14:26:40 CDT(-0500)] <Justin_o> Bosmon: so from the wireframes i sent you… you have panels for increase size and speak text.. these both have many adjusters… some of which are shared between the two panels.. how would we construct such a panel

[14:26:50 CDT(-0500)] <Justin_o> so as to be able to reuse those parts that are common across both

[14:27:03 CDT(-0500)] <Bosmon> Justin_o - I don't see any "adjustors which are shared between the two panels"

[14:27:21 CDT(-0500)] <Justin_o> Bosmon: the -+ adjuster for example

[14:27:28 CDT(-0500)] <Bosmon> The panels are quite distinct

[14:27:31 CDT(-0500)] <Bosmon> And don't overlap in any way : P

[14:27:59 CDT(-0500)] <Bosmon> Justin_o - I see 3 of these, they look separate to me

[14:28:06 CDT(-0500)] <Bosmon> Each of them handles just one preference

[14:28:15 CDT(-0500)] <Justin_o> Bosmon: it looks to me that the first adjuster in both are created from the same thing, but work on a different part of the model

[14:29:13 CDT(-0500)] <Justin_o> that being "text size" and "words spoken per minute"

[14:29:38 CDT(-0500)] <Justin_o> and there is also "Magnification"

[14:30:14 CDT(-0500)] <Bosmon> Justin_o - this wasn't a problem for us, dealing with the textfieldSlider ...

[14:30:18 CDT(-0500)] <Bosmon> For example, we use configuration like this:

[14:30:29 CDT(-0500)] <Bosmon> protoTree: {

[14:30:29 CDT(-0500)]

[14:30:29 CDT(-0500)]

[14:30:29 CDT(-0500)]

[14:30:29 CDT(-0500)]

[14:30:29 CDT(-0500)] <Bosmon> textSize: {

[14:30:30 CDT(-0500)] <Bosmon> decorators: {

[14:30:30 CDT(-0500)] <Bosmon> type: "fluid",

[14:30:31 CDT(-0500)] <Bosmon> func: "fluid.uiOptions.textfieldSlider"

[14:30:31 CDT(-0500)] <Bosmon> }

[14:30:32 CDT(-0500)] <Bosmon> }

[14:30:40 CDT(-0500)] <Bosmon> We would carry on doing the same

[14:30:56 CDT(-0500)] <Bosmon> Just with a different component type in place of "textfieldSlider"

[14:31:19 CDT(-0500)] <Bosmon> This would represent the "thing" you are talking about

[14:31:32 CDT(-0500)] <Bosmon> This is configuration taken from "fluid.uiOptions.panels.textSize"

[14:31:40 CDT(-0500)] <Justin_o> Bosmon: yes we could keep doing that.. although i'd probably just make it a real subcomponent so that it showed up on the IoC tree… but we'd still need to configure the model relay for this

[14:31:43 CDT(-0500)] <Bosmon> In our Panels.js

[14:32:01 CDT(-0500)] <Bosmon> Justin_o - yes, but we already have the infrastructure necessary to automatically configure modelRelay

[14:32:06 CDT(-0500)] <Bosmon> That we build as part of the auxBuilder

[14:32:13 CDT(-0500)] <Bosmon> built

[14:32:45 CDT(-0500)] <Justin_o> Bosmon: but that would assume that the textfieldSlider or whatever component would have a preferenceMap, but it wouldn't make sense for that really

[14:33:27 CDT(-0500)] <Justin_o> Bosmon: the only way i can see around that is to use it as a sub grade of something that just had a preferenceMap on it

[14:33:38 CDT(-0500)] <Bosmon> Justin_o - the panel combiner combines things which are already panels, into other things which are panels

[14:33:59 CDT(-0500)] <Bosmon> ALL of these things have preferenceMaps

[14:34:01 CDT(-0500)] <Justin_o> Bosmon: okay… that would make sense so that each of these adjusters could be a panel on it's own

[14:34:07 CDT(-0500)] <Bosmon> Justin_o - yes

[14:34:11 CDT(-0500)] <Bosmon> Not "could be"

[14:34:15 CDT(-0500)] <Justin_o> Bosmon: are

[14:34:15 CDT(-0500)] <Bosmon> "must necessarily be" : P

[14:34:42 CDT(-0500)] <Justin_o> Bosmon: you are saying that a panel can be a collection of panels?

[14:34:50 CDT(-0500)] <Bosmon> Justin_o - "must necessarily be" : P

[14:35:14 CDT(-0500)] <Bosmon> This was the "grade-combining grade" that I was referring to

[14:35:30 CDT(-0500)] <Bosmon> I guess it would be clearer if I had said "panel-combining panel"

[14:35:43 CDT(-0500)] <Bosmon> But I had assumed we were already talking about panels : P

[14:36:34 CDT(-0500)] <Justin_o> Bosmon:

[14:36:52 CDT(-0500)] <Justin_o> Bosmon: okay.. just looked at the base grade for panels, and this does make sense https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Panels.js#L23-L30

[14:37:13 CDT(-0500)] <Justin_o> i had been thinking there was a bit more to a basic panel, but it is really just a rendererComponent and modelRelay

[14:37:14 CDT(-0500)] <Bosmon> Justin_o - yes, that would need to be kicked out

[14:37:19 CDT(-0500)] <Bosmon> That is, the base grade of "rendererComponent"

[14:37:27 CDT(-0500)] <Justin_o> Bosmon: really

[14:37:29 CDT(-0500)] <Justin_o> why sow

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

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

[14:37:34 CDT(-0500)] <Bosmon> You would need to knock that down to viewComponent, plus whatever new grade you came up with

[14:37:39 CDT(-0500)] <Bosmon> This is what I was referring to on the 10th

[14:37:55 CDT(-0500)] <Bosmon> You will eventually come up with a new grade, which will one day appear as a base grade of rendererComponent

[14:38:02 CDT(-0500)] <Justin_o> Bosmon: i suppose we'd need to still support the renderer API for refreshView and afterRender though

[14:38:06 CDT(-0500)] <Bosmon> but for the time being you will need to do this yourself

[14:38:09 CDT(-0500)] <Bosmon> Justin_o - exactly

[14:38:27 CDT(-0500)] <Bosmon> This base grade will have whatever is common in the USAGE of the renderer API, as seen from the top, from UIOptions

[14:38:46 CDT(-0500)] <Bosmon> Thankfully our framework doesn't really care about "types" so it doesn't matter if this appears more than once or not at all

[14:39:04 CDT(-0500)] <Bosmon> But it will be helpful for architectural clarity that this base grade actually exists

[14:39:26 CDT(-0500)] <Bosmon> But in the meantime, you do need to throw out "rendererComponent" from the grade structure of "panel" since it tries to do too much

[14:39:36 CDT(-0500)] <Bosmon> btw, didn't we decide on calling this grade "panel" rather than "panels"?

[14:39:57 CDT(-0500)] <Bosmon> It seems very silly to have a single grade named in a plural way

[14:40:50 CDT(-0500)] <Bosmon> So it will be fine to revert this grade down to [viewComponent, modelRelay, autoInit] for the time being

[14:41:44 CDT(-0500)] <Justin_o> Bosmon: you're right we did.. and i thought we had changed it.. maybe we missed it or lost it in a merge somewhere

[14:41:50 CDT(-0500)] <Bosmon> ok

[14:41:56 CDT(-0500)] <Bosmon> Well, you can take care of both of these at the same time

[14:42:02 CDT(-0500)] <Justin_o> Bosmon:

[14:42:28 CDT(-0500)] <Justin_o> cindyli: have you been following along with this? any questions for Bosmon?

[14:42:57 CDT(-0500)] <Bosmon> It's worth writing in an empty "preferenceMap" into this structure too

[14:43:02 CDT(-0500)] <Bosmon> Just to emphasise that it is mandatory

[14:43:07 CDT(-0500)] <Justin_o> Bosmon: that would make sense

[14:44:44 CDT(-0500)] <Justin_o> Bosmon: can you also take a look at these jiras and see if they are still issues and if they should be fixed for 1.5 http://issues.fluidproject.org/browse/FLUID-5067

[14:44:57 CDT(-0500)] <Justin_o> http://issues.fluidproject.org/browse/FLUID-4195

[14:45:17 CDT(-0500)] <Justin_o> meant to ask you that at the community meeting but didn't get a chance

[14:46:59 CDT(-0500)] <Justin_o> Bosmon: also if you look at the channel logs, you might have some opinions on what amilchev is working on.. i was speaking to him this morning.

[14:47:56 CDT(-0500)] <Bosmon> Justin_o - my opinion is that there is absolutely no way he should be writing a JQuery UI plugin for his work

[14:48:16 CDT(-0500)] <Bosmon> The deficiencies in this terrible plugin are well-known, and are even admitted by its originators : P

[14:48:37 CDT(-0500)] <Bosmon> As a member of our community, he should be producing a Fluid component

[14:49:05 CDT(-0500)] <Bosmon> FLUID-5067 is done

[14:49:11 CDT(-0500)] <Justin_o> Bosmon: yes agreed...

[14:49:27 CDT(-0500)] <Bosmon> fluid-everyone - could I put out a general request for people who merge pull requests to go and update the original JIRAs

[14:49:37 CDT(-0500)] <Justin_o> +1

[14:49:40 CDT(-0500)] <Bosmon> Since it is much harder after the fact to discover the revision number when they were merged in

[14:49:50 CDT(-0500)] <Bosmon> Especially since it seems we can't depend on having a github JIRA plugin

[14:50:28 CDT(-0500)] <Bosmon> 4195 is not done, but colinclark and I might make a start today

[14:50:48 CDT(-0500)] <Bosmon> So let's not deassign it and the related issues from 1.5 until we have a better idea how far we are going to get

[14:53:37 CDT(-0500)] <Justin_o> Bosmon: sounds good

[14:55:14 CDT(-0500)] <Justin_o> Bosmon: and I closed off FLUID-5067

[14:55:31 CDT(-0500)] <Bosmon> Thanks, Justin_o

[14:56:02 CDT(-0500)] <Bosmon> avtar - would it be possible to get the "source editor" plugin added to the version of Confluence we have for our documentation?

[14:56:34 CDT(-0500)] <Justin_o> Bosmon: thank you.. I think we'll start looking at the panel merging panel thing on monday.

[14:58:10 CDT(-0500)] <Bosmon> Justin_o - cool!

[14:59:33 CDT(-0500)] <Justin_o> Bosmon: have you seen this http://www.amazon.com/Kaspar-Titanic-Cat-Michael-Morpurgo/dp/0062006185

[15:00:49 CDT(-0500)] <Bosmon> hahahaha

[15:00:50 CDT(-0500)] <Bosmon> Amazing

[15:00:57 CDT(-0500)] <Bosmon> I'm sure KASPARNETT will be excited

[15:02:36 CDT(-0500)] <cindyli> Bosmon, Justin_o, which part is considered too much for the "rendererComponent" being kicked out of from the grade list of "fluid.uiOptions.panel"?

[15:02:56 CDT(-0500)] <Bosmon> cindyli - the part that actually does rendering

[15:03:04 CDT(-0500)] <Justin_o> Bosmon: he might have to change those unit tests he's been writing

[15:03:11 CDT(-0500)] <avtar> Bosmon: i'll take a look at it

[15:03:31 CDT(-0500)] <Bosmon> Thanks, avtar!

[15:04:03 CDT(-0500)] <Bosmon> Unfortunately we find we can't work with the "visual-only" editing UI that the latest Confluence provides....

[15:04:16 CDT(-0500)] <Bosmon> Wow, I see some sunlight

[15:05:11 CDT(-0500)] <cindyli> Bosmon: wonder what kind of different rendering we expect in the new grade we're going to write?

[15:08:08 CDT(-0500)] <Bosmon> cindyli - the rendering which is achieved by sequentially triggering the render methods of the subcomponents

[15:09:13 CDT(-0500)] <Bosmon> Well, I guess you could try to use the renderer proper on the top component, and then again on the lower components ...

[15:09:34 CDT(-0500)] * Bosmon feels bad that he has not fixed the renderer since 2008

[15:09:50 CDT(-0500)] <cindyli> haha

[15:10:52 CDT(-0500)] <Bosmon> Well, in fact you could actually implement the system the other way, and use a "giant prototree" approach

[15:11:16 CDT(-0500)] <Bosmon> In this way ONLY the top component's rendering loop would be used

[15:11:16 CDT(-0500)] <cindyli> a prototree that contains the info for top and sub components?

[15:11:23 CDT(-0500)] <Bosmon> This would be more complicated, but more efficient

[15:11:46 CDT(-0500)] <Bosmon> I think for rendering complex panels, the multi-pass approach would be extremely slow and probably visually distracting, as each of the subpanels appeared one by one

[15:12:37 CDT(-0500)] <cindyli> so, what we can do: 1. define the giant protoTree in the top component

[15:12:51 CDT(-0500)] <cindyli> 2. inject sub-templates into the top template

[15:12:58 CDT(-0500)] <cindyli> 3. rendering happens at the top

[15:13:03 CDT(-0500)] <cindyli> does it sound right?

[15:13:23 CDT(-0500)] <Bosmon> cindyli - in either case, the basic parts of the discussion we had earlier still stand - there will be some kind of "grade-combining grade" that uses the metadata information to combine separate panels into a combined panel

[15:13:26 CDT(-0500)] <Bosmon> cindyli - that's right

[15:13:50 CDT(-0500)] <cindyli> ok. sounds clear. thanks, Bosmon. will try

[15:16:15 CDT(-0500)] <cindyli> umm… Bosmon, after a bit more thinking, this way simplifies the implementation, but confusing for the sub-panel creators since the sub-panel is not a fully encapsulated cell any more

[15:16:30 CDT(-0500)] <Bosmon> cindyli - the subpanel will be still encapsulated

[15:16:37 CDT(-0500)] <Bosmon> It will be a perfectly standard UIOptions panel in its own right

[15:16:49 CDT(-0500)] <Bosmon> The combination machinery will all be in the "grade-combining grade"

[15:20:16 CDT(-0500)] <cindyli> ok, imaging the case that alex creates the little "+", "-" panels to be reused in several final panels. since the protoTree for little panels appear one level up, there's no way these little panels can be rendered by itself. they always need to dependent on the parent component.

[15:20:26 CDT(-0500)] <cindyli> "to be"

[15:20:37 CDT(-0500)] <Bosmon> cindyli - you will need to get Justin_o to explain the preceding discussion to you

[15:21:07 CDT(-0500)] <cindyli> ok. monday...

[15:21:07 CDT(-0500)] <Bosmon> The prototree for each panel is still written in the standard place

[15:21:27 CDT(-0500)] <Bosmon> The "grade-combining grade" aggregates them into a larger prototree, and larger preference map

[15:22:39 CDT(-0500)] <cindyli> ok

[15:22:44 CDT(-0500)] <Justin_o> Bosmon: actually that brings up a question.. why don't prototrees merge?

[15:23:02 CDT(-0500)] <Justin_o> is there something in particular that we will need to be careful about

[15:23:25 CDT(-0500)] <Bosmon> Justin_o - very simple protoTrees might merge ok

[15:24:14 CDT(-0500)] <Bosmon> You might need to do some renaming to ensure that their top-level keys don't collide

[15:24:33 CDT(-0500)] <Justin_o> Bosmon: right

[15:24:55 CDT(-0500)] <Justin_o> Bosmon: i suppose we might have issues with selectors for that reason, since these would need to be surfaced up too

[15:25:13 CDT(-0500)] <Justin_o> Bosmon: can selectors be hierarchical?

[15:27:40 CDT(-0500)] <Bosmon> Justin_o - they could, yes

[15:27:46 CDT(-0500)] <Bosmon> So rebasing the selectors might be another piece of work

[15:28:58 CDT(-0500)] <Justin_o> Bosmon: we'd have to make sure that they don't bleed out of their intended scope though

[15:29:16 CDT(-0500)] <Bosmon> Justin_o - this is what I meant by the rebasing

[15:29:52 CDT(-0500)] <Justin_o> Bosmon: ah okay.. yes.. i think that will be tricky

[15:31:58 CDT(-0500)] <Bosmon> It should be fine to just take all the selectors from the subpanel and prefix them with the selector which designates the subpanel

[15:34:19 CDT(-0500)] <Justin_o> Bosmon: i don't think that would work in the case of complex selectors like "img, [role~='img']"

[15:34:35 CDT(-0500)] <Bosmon> Justin_o - those selectors are not valid for the renderer in any case

[15:34:44 CDT(-0500)] <Bosmon> Those selectors are only ever operated by jQuery

[15:34:58 CDT(-0500)] <Bosmon> And in that case they will get properly scoped, based on the location of the "container" once the component is rendered

[15:35:11 CDT(-0500)] <Justin_o> Bosmon: interesting.. okay.. well we will have to be careful about that sort of thing

[15:35:13 CDT(-0500)] <Bosmon> The renderer only acceps simple selectors for its cutpoints

[15:35:20 CDT(-0500)] <Bosmon> Of the kind which can be prefixed safely

[15:35:52 CDT(-0500)] <Justin_o> Bosmon: well that's good.. and there is the selectorsToIgnore option for those which shouldn't be used by the renderer already which should help clarify these things

[15:36:19 CDT(-0500)] <Justin_o> Bosmon: i'm going to take off now.. thanks for the help

[15:36:26 CDT(-0500)] <Justin_o> have a good weekend