fluid-work IRC Logs-2013-05-31

[05:03:44 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)

[10:46:43 CDT(-0500)] <michelled> cindyli: is now a good time to meet?

[10:47:14 CDT(-0500)] <cindyli> yes, michelled

[10:47:24 CDT(-0500)] <michelled> anastasiac: are you available too?

[10:47:32 CDT(-0500)] <anastasiac> sure

[10:48:22 CDT(-0500)] <michelled> skype?

[10:48:37 CDT(-0500)] <cindyli> fine

[13:47:47 CDT(-0500)] <Bosmon> hi there cindyli

[13:47:49 CDT(-0500)] <Bosmon> How are you getting on?

[13:48:14 CDT(-0500)] <cindyli> hi, Bosmon, still struggling

[13:48:44 CDT(-0500)] <Bosmon> Tell me about your problems

[13:49:34 CDT(-0500)] <cindyli> thanks, one sec to dig out the code on github

[13:50:42 CDT(-0500)] <cindyli> my goal is to replace this line with IoCSS: https://github.com/cindyli/infusion/blob/FLUID-5010/src/webapp/components/uiOptions/js/UIOptions.js#L86

[13:51:38 CDT(-0500)] <cindyli> The use of this mapping is @ https://github.com/cindyli/infusion/blob/FLUID-5010/src/webapp/components/uiOptions/js/FatPanelUIOptions.js#L108-131

[13:52:18 CDT(-0500)] <cindyli> my IoCSS rewritting:

[13:52:28 CDT(-0500)] <cindyli> distributeOptions: [{

[13:52:28 CDT(-0500)]

[13:52:28 CDT(-0500)] <cindyli> removeSource: true,

[13:52:28 CDT(-0500)]

[13:52:28 CDT(-0500)] <cindyli> }],

[13:52:57 CDT(-0500)] <Bosmon> Seems reasonable

[13:53:22 CDT(-0500)] <cindyli> 2. moved the uiOptions source tree in the fat panel out of "derivedDefaults"

[13:53:43 CDT(-0500)] <Bosmon> btw I think you are unnecessarily using the ">" combiner, since there's no real need for the components to be direct descendents

[13:53:47 CDT(-0500)] <Bosmon> You should just use whitespace

[13:54:04 CDT(-0500)] <cindyli> well, whitespace does not work

[13:54:11 CDT(-0500)] <Bosmon> !!

[13:54:17 CDT(-0500)] <Bosmon> If it doesn't, that is a bug : P

[13:54:21 CDT(-0500)] <cindyli> and i found ">" is not necessarily the direct descendents

[13:54:30 CDT(-0500)] <Bosmon> urgh

[13:54:33 CDT(-0500)] <cindyli> i can use it to address a deeper sub component

[13:54:36 CDT(-0500)] <Bosmon> The implementation must somehow be inverted

[13:56:05 CDT(-0500)] <cindyli> ok, i can create one or two test cases for this

[13:56:15 CDT(-0500)] <Bosmon> That would be marvellous

[13:56:23 CDT(-0500)] <Bosmon> Are you running into particular problems with 1. and 2.?

[13:56:31 CDT(-0500)] <Bosmon> I imagine 1. will fail until you deal with 2.

[13:57:13 CDT(-0500)] <cindyli> 1 you mean my IoCSS rewritting for uiOptions?

[13:57:25 CDT(-0500)] <cindyli> or whitespace

[13:58:38 CDT(-0500)] <cindyli> assuming we are back to the topic of rewritting uiOptions mapping

[13:58:48 CDT(-0500)] <Bosmon> back to the topic, yes

[13:58:56 CDT(-0500)] <Bosmon> I think we can deal with the whitespace as a separate bug

[13:59:04 CDT(-0500)] <cindyli> cool

[13:59:37 CDT(-0500)] <cindyli> the problem I'm running into is at instantiating fluid.uiOptions, it complaints a missing container

[13:59:47 CDT(-0500)] <cindyli> which means, this line is not resolved: https://github.com/cindyli/infusion/blob/FLUID-5010/src/webapp/components/uiOptions/js/FatPanelUIOptions.js#L111

[14:00:26 CDT(-0500)] <Bosmon> It may be just because it is still part of the ridiculous "derivedDefaults" system

[14:00:55 CDT(-0500)] <cindyli> no, at that point, i've moved everything outside of "derivedDefaults"

[14:01:08 CDT(-0500)]

[14:01:15 CDT(-0500)] <Bosmon> Yes

[14:01:45 CDT(-0500)] <cindyli> my first thought was that this assignment is inside a finalInit which is not recognizable on IoC tree

[14:02:12 CDT(-0500)] <Bosmon> Well, it depends WHERE you have moved it outside "derivedDefaults"

[14:02:20 CDT(-0500)] <cindyli> as per our talk yesterday, i rewrote the whole finalInit into a listener of onCreate

[14:02:29 CDT(-0500)] <Bosmon> If it is not attached to a component which has overall "createOnEvent" it's true it will not be seen

[14:02:43 CDT(-0500)] <Bosmon> This configuration must not be evaluated until the event "templateAndIframeReady" has fired

[14:02:50 CDT(-0500)] <cindyli> yes

[14:02:53 CDT(-0500)] <Bosmon> In the past this was ensured by ridiculous manual code

[14:03:08 CDT(-0500)] <Bosmon> Whereas now it should be ensured "naturally" by having it attached to a component with the correct createOnEvent

[14:03:37 CDT(-0500)] <Bosmon> So when you say, "I've moved everything outside of "derivedDefaults"", can we look at how you have done this?

[14:03:41 CDT(-0500)] <Bosmon> Did you check that in yet?

[14:03:59 CDT(-0500)] <cindyli> not yet, can check in now

[14:04:02 CDT(-0500)] <Bosmon> cool

[14:07:43 CDT(-0500)] <cindyli> it's in, Bosmon - https://github.com/cindyli/infusion/tree/FLUID-5010

[14:10:20 CDT(-0500)] <Bosmon> cindy: so I see that the UIOptions subcomponent has lost its "createOnEvent" annotation

[14:10:37 CDT(-0500)] <Bosmon> Which will explain why its container won't resolve

[14:12:44 CDT(-0500)] <cindyli> Bosmon: it's not lost, it was moved into options block: https://github.com/cindyli/infusion/blob/FLUID-5010/src/webapp/components/uiOptions/js/FatPanelUIOptions.js#L112

[14:12:57 CDT(-0500)] <Bosmon> cindyli - that's the wrong place!

[14:13:04 CDT(-0500)] <Bosmon> It can't appear inside the component options, it will be ignored

[14:13:07 CDT(-0500)] <cindyli> man, i wrote a test case for that

[14:13:32 CDT(-0500)] <cindyli> createOnEvent can be passed down only if it's inside options block

[14:13:43 CDT(-0500)] <Bosmon> cindyli - it can never be passed down, it is not an option

[14:13:45 CDT(-0500)] <cindyli> i can check in that test case as well

[14:13:46 CDT(-0500)] <Bosmon> But a "subcomponent annotation"

[14:14:10 CDT(-0500)] <Bosmon> The only place it can appear is in the top-level record, about line 109

[14:14:17 CDT(-0500)] <Bosmon> Next to "container"

[14:14:59 CDT(-0500)] <cindyli> it can never be passed down?

[14:15:06 CDT(-0500)] <Bosmon> it can never be passed down

[14:15:14 CDT(-0500)] <Bosmon> Like "autoInit", it is non-inheritable

[14:16:05 CDT(-0500)] <cindyli> same for "container"

[14:16:47 CDT(-0500)] <cindyli> i mean "container" is also an annotation that cannot be passed down as well?

[14:16:48 CDT(-0500)] <Bosmon> Same for container, although I guess we now know that "container" can at least be targetted by IoCSS : P

[14:17:00 CDT(-0500)] <Bosmon> Material that is at top-level inside the "subcomponent record" doesn't participate in the overall options system

[14:17:46 CDT(-0500)] <Bosmon> Anyway, hopefully moving your "createOnEvent" from line 112 to 109 should improve things

[14:18:07 CDT(-0500)] <Bosmon> When you say you wrote a test case for this, you wrote a test case to determine whether the component was instantiating at the proper time?

[14:18:10 CDT(-0500)] <cindyli> it won't, that's why I moved it inside options block

[14:18:13 CDT(-0500)] <cindyli> but i can try again

[14:18:43 CDT(-0500)] <Bosmon> cindyli - wait - I see a really serious problem

[14:18:49 CDT(-0500)] <Bosmon> The options nesting is screwed up

[14:19:01 CDT(-0500)] <cindyli> no, i write a test case to prove "createOnEvent" can only be passed down when it's inside options block

[14:19:04 CDT(-0500)] <Bosmon> It seems you have an extra } at line 105 which prevents all the subsequent blocks from being interpreted as components

[14:21:25 CDT(-0500)] <cindyli> the subsequent blocks are not components, they are IoCSS sources

[14:21:54 CDT(-0500)] <Bosmon> cindyli - I think it is essential to make them components!

[14:22:15 CDT(-0500)] <cindyli> they are subcomponents of "inline" component

[14:23:10 CDT(-0500)] <Bosmon> cindyli - but the "fatPanel" grade is indeed derived from "inline"

[14:23:14 CDT(-0500)] <Bosmon> So they should just be standard subcomponents

[14:23:21 CDT(-0500)] <cindyli> i mean to make them sub-components of "fatPanel"? is that right?

[14:23:22 CDT(-0500)] <cindyli> sorry, not "i mean", should be "you mean"

[14:23:38 CDT(-0500)] <cindyli> ok, give a try

[14:24:54 CDT(-0500)] <cindyli> btw, uiOptions should be the sub-component of uiOptionsLoader, rather than fatPanel

[14:25:14 CDT(-0500)] <Bosmon> Although it's interesting that you say you found it didn't work with "createOnEvent" on line 109, since this implies that "createOnEvent" is not responsive to IoCSS broadcasts

[14:25:34 CDT(-0500)] <Bosmon> I imagine you were expecting it to be distributed by this material in UIOptions.js:

[14:25:35 CDT(-0500)]

[14:25:35 CDT(-0500)] <Bosmon> removeSource: true,

[14:25:35 CDT(-0500)]

[14:25:35 CDT(-0500)] <Bosmon> }],

[14:25:40 CDT(-0500)] <Bosmon> Line 74

[14:27:35 CDT(-0500)] <Bosmon> cindyli - in that case, I suggest what you do is to move all the material from "derivedDefaults" into a separate grade

[14:27:56 CDT(-0500)] <Bosmon> That is, a grade which becomes an "additive grade" to uiOptionsLoader

[14:28:16 CDT(-0500)] <Bosmon> Then the action of fatPanel grade is to assign this grade to the loader, which will cause the "createOnEvent" to be seen correctly

[14:29:00 CDT(-0500)] <cindyli> ah, i see your point. trying...

[14:31:08 CDT(-0500)] <cindyli> btw, i tried to move uiOptionsLoader into components block of fat panel, and moved uiOptions that was used to be inside derivedDefaults in fatPanel, into components block of uiOptionsLoader, same error: container is undefined, at instantiating fluid.uiOptions

[14:33:05 CDT(-0500)] <Bosmon> cindyli - with the "createOnEvent" in the right place?

[14:34:35 CDT(-0500)] <cindyli> You got me, genius. it was at the wrong place. now fat panel demo is working!!! YAY!!!

[14:34:45 CDT(-0500)] <Bosmon> yay yay yay!

[14:34:48 CDT(-0500)] <Bosmon> You did it

[14:34:50 CDT(-0500)] <cindyli> you are always my life saver!!!

[14:35:03 CDT(-0500)] <Bosmon> Now you just have a couple hundred lines more refactoring elsewhere

[14:35:14 CDT(-0500)] <Bosmon> Well, it's the least I can do given I threatened your life in the first place : P

[14:35:23 CDT(-0500)] <cindyli> haha

[14:35:32 CDT(-0500)] <cindyli> we still should try the approach of the additive grade, which seems cleaner

[14:35:41 CDT(-0500)] <Bosmon> Yes

[14:35:55 CDT(-0500)] <Bosmon> Now we have them, additive grades definitely seem like the approach of choice for many situations

[14:36:05 CDT(-0500)] <cindyli> cool. thanks a lot, Bosmon(A)

[14:36:07 CDT(-0500)] <Bosmon> Including many situations which we previously planned to address with demands blocks

[14:36:27 CDT(-0500)] <cindyli> super

[14:36:39 CDT(-0500)] <Bosmon> You can see that the old comment there was planning to apply this material using additive demands blocks, but it took many years for these to arrive

[14:36:49 CDT(-0500)] <cindyli>

[14:36:52 CDT(-0500)] <Bosmon> And in the meantime we discovered that dynamic grades were more tidy and almost as powerful

[14:37:26 CDT(-0500)] <cindyli> totally agree, i rmb how much i struggled with demands blocks

[14:38:04 CDT(-0500)] <Bosmon> We were still blinded by the idea of "types" inherited from the Java world

[14:38:12 CDT(-0500)] <Bosmon> Where the "type" of an object is decided at its point of construction

[14:38:31 CDT(-0500)] <Bosmon> I felt we needed demands blocks because this was the only way to get at the point of construction BEFORE it happened

[14:38:51 CDT(-0500)] <Bosmon> Even though we decided that "grades were not types" it wasn't completely clear all the ways in which this was true

[14:39:04 CDT(-0500)] <Bosmon> But now we have no problem causing modification of grade structure AFTER the point of construction

[14:39:09 CDT(-0500)] <cindyli> i see your point

[14:39:20 CDT(-0500)] <Bosmon> So we no longer need to win the "race" through the mechanism of demands blocks, except in some exceptional situations

[14:39:31 CDT(-0500)] <Bosmon> I think the demands blocks we have in the Uploader will remain, but in very few other places

[14:40:07 CDT(-0500)] <Bosmon> But I think it's possible in the future of the framework we might be able to abolish all uses of demands blocks except for invokers

[14:40:19 CDT(-0500)] <Bosmon> Justin_o had this idea, "Why can't a component be its own progressive checker"

[14:40:24 CDT(-0500)] <Bosmon> Which is a very good question

[14:41:38 CDT(-0500)] <Bosmon> And the only real reason is because of a framework limitation, "Cannot affect the collection of a component's subcomponents once iteration over them has started"

[14:41:45 CDT(-0500)] <Bosmon> Which I'm sure I had JIRAed somewhere but maybe I forgot

[14:43:43 CDT(-0500)] <cindyli> sounds powerful

[14:44:09 CDT(-0500)] <Bosmon> But in theory, if the progressiveChecker, say, for the Uploader, could be one of its own subcomponents, assigned there by its own grade, it could cause a further modification of the Uploader's grade structure whilst it is still evaluating

[14:44:52 CDT(-0500)] <Bosmon> The problem is, as the framework is now, once we have started trying to instantiate the "progressiveChecker" subcomponent, we have already started instantiating subcomponents, and so will not respond to any further changes they cause in the grade structure which define new subcomponents

[14:45:11 CDT(-0500)] <Bosmon> But in theory this could let us get rid of almost the last demands blocks in the framework

[14:49:05 CDT(-0500)] <cindyli> ah

[14:50:08 CDT(-0500)] <Bosmon> This is also much more helpful than the "demands block" model which in fact made no attempt to ensure that the "replaced type name" did anything even slightly similar to the original demanded name

[14:50:38 CDT(-0500)] <Bosmon> In the current Uploader, our demands blocks at least now resolve the demands block onto a derived grade of the original name, but there's no reason they need to do this

[14:50:51 CDT(-0500)] <Bosmon> So in effect you are specifying the same thing twice

[14:51:12 CDT(-0500)] <Bosmon> For example, "This is the remote strategy of the Uploader" - "It is the HTML5 remote strategy", AND "It is derived from the original remote strategy grade"

[14:51:33 CDT(-0500)] <Bosmon> Doing this with additive grades allows the type structure to grow naturally from the original grade, ONLY through addition

[14:52:19 CDT(-0500)] <cindyli> it means one component may end up as a combination of many additive grades

[14:53:57 CDT(-0500)] <cindyli> smart to resolve the demands block onto a derived grade

[14:54:30 CDT(-0500)] <Bosmon> yes, it is at least you could say "courteous"

[14:54:47 CDT(-0500)] <Bosmon> But indeed, if we are always going to resolve onto a derived grade, you can ask why we need to use a demands block at all

[14:55:03 CDT(-0500)] <cindyli> to manipulate things at runtime

[14:55:17 CDT(-0500)] <cindyli> dynamically, on the fly

[14:55:48 CDT(-0500)] <Bosmon> Well, you could say it is "on the fly", but in the "ginger view" there's nothing to say that "this wasn't always what the grade was going to be" : P

[14:55:56 CDT(-0500)] <Bosmon> If things were actually being CHANGED, it would cause chaos

[14:56:11 CDT(-0500)] <Bosmon> But in fact we have a model that is purely ADDITIVE, once something has been seen, it can never change or become unseen

[14:56:30 CDT(-0500)] <Bosmon> So the addition of dynamic grades can only cause NEW things to appear in a component that have not yet been observed

[14:56:45 CDT(-0500)] <cindyli> i see

[14:57:17 CDT(-0500)] <Bosmon> But in this model we gain a lot of consistency - since i) we are free of most scheduling issues and race conditions, since it doesn't matter WHEN a particular value is observed, and ii) we can depend on everything which has been brought into existence to stay in existence, meaning the reference remains valid

[14:57:35 CDT(-0500)] <Bosmon> From the point of view of the EL evaluator, it appears that every expression is immutable

[14:57:50 CDT(-0500)] <Bosmon> Since after the first time it has been evaluated, it never appears to change its value

[14:58:39 CDT(-0500)] <Bosmon> This isn't in fact strictly true, but it is "mostly true" : P

[14:58:59 CDT(-0500)] <cindyli> ya

[14:59:34 CDT(-0500)] <Bosmon> At least, it is true as we need to make it - in cases like resolving invokers, for example, we DO sometimes see expressions changing their values

[14:59:40 CDT(-0500)] <Bosmon> But in general we think of this as part of a separate process

[15:00:15 CDT(-0500)] <Bosmon> In the future there will be a distinction between the two types of invokers, "dynamic invokers" and "static invokers" - to emphasise the points where we expect there might be change

[15:00:32 CDT(-0500)] <Bosmon> Perhaps 90% of the invokers we have written so far will be "static invokers" which only need to evaluate their arguments once

[15:01:01 CDT(-0500)] <Bosmon> There is for example an awkward case in the Reorderer where there is a member of the component which is constantly changing, which requires a "dynamic invoker" which evaluates its arguments each time afresh

[15:01:34 CDT(-0500)] <Bosmon> But it will be good to be able to highlight where these places are, since in general they always correspond to a design error

[15:01:42 CDT(-0500)] <cindyli> how do you distinguish if an invoker is dynamic of static

[15:01:52 CDT(-0500)] <Bosmon> Which in the case of the Reorderer, is the fact that not enough of its changing material is inside its model

[15:01:54 CDT(-0500)] <cindyli> different definitions?

[15:02:04 CDT(-0500)] <Bosmon> In fact some configurations of the Reorderer still don't use a model at all

[15:02:17 CDT(-0500)] <Bosmon> My plan is currently for an extra annotation "dynamic: true" inside the invoker's block

[15:02:25 CDT(-0500)] <cindyli> ok

[15:02:57 CDT(-0500)] <Bosmon> It will also let us improve the performance of all the non-dynamic invokers gigantically

[15:03:01 CDT(-0500)] <Bosmon> Perhaps even by a factor of 100 or so : P

[15:03:07 CDT(-0500)] <cindyli> exactly

[15:03:25 CDT(-0500)] <Bosmon> The vast majority of them will and should be happy to evaluate their arguments just once

[15:03:33 CDT(-0500)] <Bosmon> Unless they happen to be the ones that are drawn from "{arguments]"

[15:03:37 CDT(-0500)]

[15:03:49 CDT(-0500)] <Bosmon> But these ones are very easy to find and require no IoC machinery

[15:05:00 CDT(-0500)] <cindyli> ok

[15:55:22 CDT(-0500)] <cindyli> Bosmon: r u still there

[15:56:07 CDT(-0500)] <Bosmon> Hey there cindyli!

[15:56:31 CDT(-0500)] <cindyli> the implementation of the additive grade for loader - https://github.com/cindyli/infusion/blob/FLUID-5010/src/webapp/components/uiOptions/js/FatPanelUIOptions.js#L241-275

[15:56:50 CDT(-0500)] <Bosmon> Ok

[15:56:53 CDT(-0500)] <cindyli> however, what should be rendered into iframe is rendered on the main page

[15:56:58 CDT(-0500)] <Bosmon> It should probably have the word "fatPanel" in its name somewhere : P

[15:57:15 CDT(-0500)] <cindyli> for this -

[15:57:16 CDT(-0500)]

[15:57:23 CDT(-0500)] <cindyli> let me try

[15:57:35 CDT(-0500)] <Bosmon> Well, that won't fix anything

[15:57:39 CDT(-0500)] <Bosmon> What is happening with the container?

[15:58:06 CDT(-0500)] <cindyli> that's what I'm wondering

[15:58:14 CDT(-0500)] <Bosmon> Does the reference not resolve correctly?

[15:58:25 CDT(-0500)] <cindyli> ya, also suspect that

[15:59:45 CDT(-0500)] <cindyli> tracing

[16:06:18 CDT(-0500)] <cindyli> templatesAndIframeReady seems not fired

[16:06:47 CDT(-0500)] <cindyli> weird that uiOptions still gets created