[10:16:43 CDT(-0500)] <colinclark> hey yzen, is the "preferences changed" event for the PCP in the Flow Manager yet?

[10:17:00 CDT(-0500)] <yzen> no not yet

[10:17:13 CDT(-0500)] <yzen> colinclark: ^

[10:17:16 CDT(-0500)] <colinclark> ok, thanks

[10:17:19 CDT(-0500)] <yzen> np

[13:38:22 CDT(-0500)] <cindyli> anastasiac, Justin_o, right now the component that connects prefs editor and panels is called "fluid.prefs.prefsEditorConnections", since we are adding another connection component for enactors and prefs editor, which I'm calling it "fluid.prefs.enactorConnections". do you mind I rename the one for panels to "fluid.prefs.panelConnections"?

[13:39:25 CDT(-0500)] <anastasiac> cindyli, that makes sense to me – they should have consistent names, and panels/enactors makes a bit more sense than editors/uiEnhancer, I think. maybe

[13:40:27 CDT(-0500)] <cindyli> ok. thanks

[13:40:34 CDT(-0500)] <anastasiac> cindyli, I'm thinking about the name now

[13:40:50 CDT(-0500)] <anastasiac> it's a grade we "add to" a panel, to say that we want it connected to the prefs editor

[13:41:06 CDT(-0500)] <cindyli> that's right

[13:41:07 CDT(-0500)] <anastasiac> or a grade we add to the enactor, to connect it to the uiEnhancer

[13:41:10 CDT(-0500)] <anastasiac> hm

[13:41:54 CDT(-0500)] <anastasiac> cindyli, sorry, I'm not trying to be difficult, but I'm not sure which way to name them now

[13:42:30 CDT(-0500)] <cindyli> the one for enactors is to connect enactors with uiEnhancer. the one for panels is to connect panels with prefsEditor

[13:42:42 CDT(-0500)] <cindyli> anastasiac: ^

[13:43:43 CDT(-0500)] <cindyli> ah, sounds making sense to call them "fluid.prefs.prefsEditorConnections" and "fluid.prefs.uiEnhancerConnections"

[13:57:23 CDT(-0500)] <anastasiac> cindyli and Justin_o, regarding the idea of changing the name "fluid.prefs.prefsEditor" to "fluid.prefs.editor" - I searched the integration code I'm writing, and it's interesting. I only use that actual grade name once, and only in the grades version of the integration; if you're using schemas, you never explicitly use that grade

[13:58:01 CDT(-0500)]

<anastasiac> and in the grades version, you do use "

Unknown macro: {prefsEditor}

.x" a bit, and that actually looks a wee bit more clear than "

Unknown macro: {editor}

.x" might

[13:58:34 CDT(-0500)] <anastasiac> so I'm actually leaning toward recommending we leave it as it is

[13:58:38 CDT(-0500)] <Justin_o> anastasiac: thanks for looking into that.. i guess we should leave it then.. the only other question then is what to call the full stack

[13:58:50 CDT(-0500)] <anastasiac> ah, yes, that question still remains

[13:59:05 CDT(-0500)] <anastasiac> perhaps we could call it "fullStack" ?

[14:21:02 CDT(-0500)] <jessm> hey Justin_o, should i forward your email to the UX list for C4a? wasn't sure if it should go there?

[14:42:27 CDT(-0500)] <Bosmon> cindyli, Justin_o - I have just merged in your branch now for FLUID-5131

[14:42:29 CDT(-0500)] <Bosmon> Great work!

[14:43:00 CDT(-0500)] <cindyli> super!!! thanks, Bosmon

[14:45:17 CDT(-0500)] <Bosmon> cindyli - as for the TextfieldSlider "modelPath" work - would this not be better done by using the ModelRelay system that you already wrote?

[14:45:37 CDT(-0500)] <Bosmon> If you were to move it over to this, it would be closer to the implementation we had once model relay goes into the framework proper

[14:45:50 CDT(-0500)] <Bosmon> I am speaking of your FLUID-5190 work, pull request 424

[14:46:41 CDT(-0500)] <cindyli> umm.. let me try, Bosmon

[14:47:05 CDT(-0500)] <Bosmon> cindyli - cool!

[14:47:16 CDT(-0500)] <Bosmon> I think the modelRelay that you have written is already good enough for this

[14:47:41 CDT(-0500)] <Bosmon> And its configuration and general idiom is mostly compatible with the modelRelay we will have soon

[14:47:54 CDT(-0500)] <Bosmon> In general we will abolish the "modelPath" system wherever we find it once this happens

[14:48:10 CDT(-0500)] <cindyli> sounds reasonable

[15:01:35 CDT(-0500)] <cindyli> Bosmon: after experimenting a bit, i rmb why I didn't use model relay. the goal of 5190 is to allow integrators to save sliding value to any path names they want. rules required by the model relay needs to specify the internal model path. if a random name is chosen, how does textfieldSlider know which model path to listen?

[15:02:43 CDT(-0500)] <Bosmon> cindyli - the idea is that textfieldSlider will use a fixed path internally, and will then be supplied configuration to bind its internal path to an external path via modelRelay

[15:03:00 CDT(-0500)] <Bosmon> So - instead of configuration the option named "modelPath", users will instead configure the modelRelay belonging to the textfieldSlider

[15:03:02 CDT(-0500)] <Bosmon> Does that make sense?

[15:04:12 CDT(-0500)] <cindyli> well, anastasia is offline, we had a discussion yesterday in the channel regarding ur question of "Does that make sense". let me find out

[15:04:59 CDT(-0500)] <cindyli> Bosmon: http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2013-10-24, from 12:53:25 onwards

[15:19:12 CDT(-0500)] <Bosmon> cindyli - do you feel that this discussion still makes sense? : P

[15:19:32 CDT(-0500)] <Bosmon> I don't see anything in it that has a bearing on whether to use modelRelay for this application or not.....

[15:21:03 CDT(-0500)] <cindyli> Bosmon: with model relay, when textfield slider is used, there are 2 requirements: 1. it's inside a wrapper component; 2. the internal path is "value"

[15:21:30 CDT(-0500)] <cindyli> anastasia mentioned yesterday in the channel: it's going to feel very weird to write documentation that says "you can call your model field whatever you like, unless you're using our textfieldSlider, then you must use 'value'"

[15:23:15 CDT(-0500)] <cindyli> i guess whether using model relay makes more sense is depending on how integrators are going to use text field slider, or anastasia's use case, perhaps

[15:24:37 CDT(-0500)] <Bosmon> cindyli - 1. No wrapper component is required, since modelRelay is a mixin grade of the textfieldSlider itself, 2. The entire purpose of ModelRelay is to abstract over whatever the internal path is to a model field

[15:25:17 CDT(-0500)] <Bosmon> anastasia's comment misses the point that the author of a component always calls their model field whatever they like, and the purpose of ModelRelay is to ensure that the integrator of the component in addition gets to call their model field whatever they like .......

[15:26:37 CDT(-0500)] <Bosmon> The "modelPath" system was only ever a poor man's proxy for the modelRelay system

[15:26:45 CDT(-0500)] <Bosmon> As indeed, was the historical "shared object reference" system........

[15:32:25 CDT(-0500)] <cindyli> i see your point, Bosmon. i will talk over with anastasia on Monday to see if it satisfies her needs

Browser not supported