fluid-tech IRC Logs-2013-07-24

[09:01:45 CDT(-0500)] <Bosmon7> Hi yzen

[09:02:01 CDT(-0500)] <Bosmon7> Did the ${} wrapping approach work?

[09:04:14 CDT(-0500)] <yzen> Bosmon7: still have to try it

[09:18:04 CDT(-0500)] <yzen> Bosmon7: so just adding the wrapping does not work

[09:45:16 CDT(-0500)] <Bosmon7> yzen - what have you tried?

[09:45:34 CDT(-0500)] <yzen> so these are a couple of lines from expandBound

[09:45:37 CDT(-0500)] <yzen> that matter

[09:45:42 CDT(-0500)] <yzen> var EL = typeof (value) === "string" ? fetchEL(value) : null;

[09:45:43 CDT(-0500)] <yzen> if (EL) {

[09:45:45 CDT(-0500)] <yzen> proto.valuebinding = EL;

[09:45:46 CDT(-0500)] <yzen> } else if (value !== undefined) {

[09:45:48 CDT(-0500)] <yzen> var expanded = expandLight(value);

[09:45:49 CDT(-0500)] <yzen> proto.value = expanded !== undefined ? expanded : value;

[09:45:51 CDT(-0500)] <yzen> }

[09:45:52 CDT(-0500)] <yzen> if (options.model && proto.valuebinding && proto.value === undefined) {

[09:45:53 CDT(-0500)] <yzen> proto.value = fluid.get(options.model, proto.valuebinding, options.resolverGetConfig);

[09:45:54 CDT(-0500)] <yzen> }

[09:46:03 CDT(-0500)] <yzen> the expanded stuff is new

[09:47:09 CDT(-0500)] <yzen> Bosmon7: ^

[09:47:35 CDT(-0500)] <Bosmon7> yzen - could you explain why it wasn't working before?

[09:48:15 CDT(-0500)] <yzen> what do you mean by "it"?

[09:49:15 CDT(-0500)] <Bosmon7> yzen - why did neither the original strategy, or the one involving ${} end up resolving the reference?

[09:50:32 CDT(-0500)] <yzen> Bosmon7: ok so the original strategy was not resolving the path without ${} because it was the default elPath i believe, so if i wrapped it the EL would be parsed. But that does not help since it's only used to get things from the model and nothing else

[09:56:54 CDT(-0500)] <Bosmon7> yzen - I guess all further pathways involving the "valuebinding" field defer to fluid.get

[09:57:29 CDT(-0500)] <Bosmon7> Can you explain the workflow where expanded holds a value of undefined, and value is not undefined?

[09:57:51 CDT(-0500)] <Bosmon7> It appears in that case you return to storing the original value

[09:58:10 CDT(-0500)] <Bosmon7> What use case does that cover?

[10:00:16 CDT(-0500)] <yzen> Bosmon7: yes so the original version was proto.value = value; which is the reference to the actual value field in the tree. so it is expandable to undefined we use the original value for it which perhaps is not necessary and just having proto.value = expanded; would suffice, assuming non-expandable value will stay as such

[10:01:42 CDT(-0500)] <Bosmon7> It's worth trying out with the simplified logic

[10:01:57 CDT(-0500)] <Bosmon7> Although I'm already worried about our now inability to render strings to the user which begin with {

[10:06:35 CDT(-0500)] <Bosmon7> I guess this whole "renderer and IoC component" idiom is by definition screwed up, but we should probably try to patch it up as much as possible

[10:07:21 CDT(-0500)] <yzen> Bosmon7: well isn't that the case why we would want to have value if expanded is undefined?

[10:07:44 CDT(-0500)] <yzen> Bosmon7: wouldn't a string with { expand to undefined ?

[10:07:52 CDT(-0500)] <yzen> if so we use value

[10:08:56 CDT(-0500)] <Bosmon7> yzen - it's unclear what would happen - I suspect that we may well get an exception rather than undefined

[10:09:20 CDT(-0500)] <Bosmon7> This is the reason that the old "fetchEL" path was so cautious

[10:09:32 CDT(-0500)] <Bosmon7> I suggest that you write a test to investigate what happens

[10:09:51 CDT(-0500)] <yzen> Bosmon7: ok

[10:15:04 CDT(-0500)]

[10:15:09 CDT(-0500)]

[10:19:39 CDT(-0500)] <Bosmon7> yzen - what about Strings like {test.string ......

[10:19:56 CDT(-0500)] <yzen> oh ok one sec

[10:22:34 CDT(-0500)]

[10:22:54 CDT(-0500)] <yzen> Bosmon7: yes that gives an error since it's looking for an }. suggestions? should it be wrapped?

[10:30:11 CDT(-0500)] <Bosmon7> yzen - this is why I was keener on patching up the existing pathway which used "fetchEL" and the "EL or nothing" idiom ...

[10:32:38 CDT(-0500)] <Bosmon7> So it might be a better approach to fix up the rest of the body where it expects that the return from "fetchEL" can only be a simple reference into the model

[10:33:09 CDT(-0500)]

[10:33:18 CDT(-0500)] <Bosmon7> But I imagine that right now what happens is that we ignore this

[10:34:38 CDT(-0500)] <Bosmon7> In the case it is, what you should do is just send it to "options.externalFetcher" directly

[10:35:43 CDT(-0500)] <yzen> Bosmon7: hmm

[10:35:54 CDT(-0500)] <yzen> but i did get it to work like this too:

[10:35:56 CDT(-0500)] <yzen> var index = value.indexOf("{") || 0;

[10:35:57 CDT(-0500)] <yzen> var endcpos = value.indexOf("}", index + 1);

[10:35:59 CDT(-0500)] <yzen> if (endcpos > -1) {

[10:36:00 CDT(-0500)] <yzen> var expanded = expandLight(value);

[10:36:01 CDT(-0500)] <yzen> }

[10:36:02 CDT(-0500)] <yzen> proto.value = expanded !== undefined ? expanded : value;

[10:39:09 CDT(-0500)] <sgithens> I'm going to test out the Goto Meeting Android app today... hopefully it works!

[10:41:05 CDT(-0500)] <Bosmon7> yzen - we should try to reuse the logic inside fluid.resolveContextValue - or, if it is broken (which is quite possible), we should fix it there

[10:41:21 CDT(-0500)] <Bosmon7> It will be dangerous to proliferate the number of different places in the codebase where we parse EL references

[10:43:04 CDT(-0500)] <sgithens> I was thinking about parsing EL references the other day

[10:43:18 CDT(-0500)] <sgithens> as part of that diffing algorithm

[10:43:32 CDT(-0500)] <sgithens> and how it would be nice to associate a bit of extra information with some of the paths

[10:44:02 CDT(-0500)] <sgithens> sort of like how you can attach properties to symbols, vars, and other things in lisp

[10:44:16 CDT(-0500)] <Bosmon7> Also I think the code you have pasted will fail in the case the reference holds "a}"

[11:07:45 CDT(-0500)] <yzen> Bosmon7: ok so i updated resolveContextValue like this:

[11:07:45 CDT(-0500)]