fluid-tech IRC Logs-2013-05-08

[08:56:02 CDT(-0500)] <Bosmon> Hi yzen, just had time for a quick look over the changes in your FLUID-4686 branch, in general they look very good!

[08:56:13 CDT(-0500)] <Bosmon> I think we need to think about lines like the following: https://github.com/yzen/infusion/blob/fb6fdba52d2d5d0324820bd527fb5cec19f03f1d/src/webapp/components/uiOptions/js/UIEnhancer.js#L144-L146

[08:56:36 CDT(-0500)] <Bosmon> Which highlight part of the conversation terms we had this week about distinguishing between the "default model" and the "model"

[08:56:54 CDT(-0500)] <Bosmon> In the future when we write expressions like this, they will set up a permanent association between one model and another....

[08:57:24 CDT(-0500)] <Bosmon> I guess given that the "defaultModel" area of the options doesn't actually refer to any model, this isn't going to be problematic

[08:57:37 CDT(-0500)] <Bosmon> But we will need to be careful that we are sure that we are saying what we mean....

[08:58:49 CDT(-0500)] <Bosmon> I notice that you have indeed eliminated any association between the Enhancer/Enactors and the store

[08:58:51 CDT(-0500)] <yzen> Bosmon: yes exactly and that was my second concern from yesterday's conversation

[08:58:53 CDT(-0500)] <Bosmon> This is probably correct

[08:59:08 CDT(-0500)] <Bosmon> You mentioned that one test was still failing?

[08:59:29 CDT(-0500)] <yzen> page enhancer's association with the store was the one we discussed, the other one, its association with default model ...

[09:03:29 CDT(-0500)] <yzen> Bosmon: brb commuting

[09:30:34 CDT(-0500)] <yzen1> Bosmon: back

[09:32:04 CDT(-0500)] <yzen1> Bosmon: so yes, my concern is where would page enhancer get "defaultModel" in case there's no uiOptions ?

[10:16:01 CDT(-0500)] <yzen> Bosmon ayt ?

[12:03:51 CDT(-0500)] <Bosmon> Hi yzen

[12:04:01 CDT(-0500)] <Bosmon> I suggest we adopt a "standard reference" for this

[12:04:01 CDT(-0500)] <yzen> Hi

[12:04:10 CDT(-0500)] <yzen> could you expand ?

[12:04:20 CDT(-0500)]

[12:04:35 CDT(-0500)] <Bosmon> Whatever can be seen with this grade name attached will be it

[12:04:54 CDT(-0500)] <yzen> ok

[12:05:07 CDT(-0500)] <yzen> but i m talking about the case where there is no uioptions

[12:05:22 CDT(-0500)] <Bosmon> yzen - yes

[12:05:44 CDT(-0500)] <Bosmon> Precisely

[12:06:04 CDT(-0500)] <yzen> were would it be ? would the pageenhancer have this grade ?

[12:06:08 CDT(-0500)] <yzen> defaultModel grade?

[12:08:25 CDT(-0500)] <Bosmon> yzen - yes, why not

[12:08:30 CDT(-0500)] <yzen> ok

[12:08:33 CDT(-0500)] <yzen> makes sense

[12:08:41 CDT(-0500)] <Bosmon> The pageEnhancer is a cluster of "more distant stuff" that will be resolved in the absence of anything more specific

[12:08:52 CDT(-0500)] <yzen> right

[12:38:03 CDT(-0500)] <cindyli> Bosmon: is there a way in IoCSS to pass one source value to more than one targets?

[12:38:29 CDT(-0500)] <cindyli> I had no success so far and writing a test case for it

[12:40:17 CDT(-0500)] <Bosmon> cindyli - A great question, and it's true that that facility may be currently broken

[12:40:22 CDT(-0500)] <Bosmon> It is certainly intended to be possible

[12:40:37 CDT(-0500)] <Bosmon> But there is an interesting issue relating to when the original material is "removed" from the source

[12:40:39 CDT(-0500)] <cindyli> great. good to know

[12:41:09 CDT(-0500)] <Bosmon> When it is broadcast from the component's own options it is removed immediately, whereas when it is broadcast from a 3rd-party component clearly it must be left in place because it has most likely started to evaluate already

[12:41:26 CDT(-0500)] <Bosmon> But that is an odd inconsistency that needs to be formalised, possibly by use of another option or directive

[12:41:48 CDT(-0500)] <cindyli> ok. i see

[12:43:25 CDT(-0500)] <cindyli> have a question on this comment: When it is broadcast from the component's own options it is removed immediately

[12:44:16 CDT(-0500)] <cindyli> what if that source option is also needed by "the component"'s grade?

[12:45:05 CDT(-0500)] <Bosmon> cindyli - yes, it's a great question

[12:45:10 CDT(-0500)] <cindyli> saying, the grade component of the original also needs the source to be populated into its own subcomponent

[12:45:12 CDT(-0500)] <Bosmon> And currently I believe there is no way to control that

[12:45:32 CDT(-0500)] <Bosmon> This is the kind of thing I expected to be exposed once we started using the IoCSS system in anger : P

[12:46:05 CDT(-0500)] <cindyli> we are having this issue now with the "prefix" option for the fat panel

[12:46:09 CDT(-0500)] <Bosmon> There's also another important facility which has not been implemented, which is the ability to broadcast listeners down to any number of matching events in a tree

[12:46:21 CDT(-0500)] <cindyli> both fatPanel and inline need to pass the "prefix" down

[12:46:35 CDT(-0500)] <Bosmon> There is a JIRA describing this under the name "proleptic binding" dating from the original UIOptions work we were doing in July 2011

[12:56:47 CDT(-0500)] <cindyli> the next-step IoCSS seems quite powerful. btw, Bosmon, is the issue of passing one source to several targets already jiraed or on you list. should I finish the test case or create a jira?

[12:57:13 CDT(-0500)] <Bosmon> cindyli - the test case and JIRA would be both extremely valuable!

[12:57:24 CDT(-0500)] <cindyli> cool. carry on ...

[15:11:29 CDT(-0500)] <yzen> Bosmon: is this still an issue ? http://issues.fluidproject.org/browse/FLUID-2248

[15:14:04 CDT(-0500)] <Bosmon> yzen - I imagine it will still be an issue if we take away the timeout, yes

[15:15:07 CDT(-0500)] <yzen> Bosmon: for the currently supported browser , hmm ok

[15:17:46 CDT(-0500)] <Bosmon> Well, that can only be verified through further testing

[15:20:34 CDT(-0500)] <Bosmon> ok fluid-everyone, setting off for a trip for a couple of days - might be able to look in, but good luck

[15:21:00 CDT(-0500)] <colinclark> See you on Monday, Bosmon!

[15:21:04 CDT(-0500)] <colinclark> In person!