fluid-work IRC Logs-2013-03-05

[13:29:08 CST(-0600)] <cindyli> hi, Bosmon

[13:30:09 CST(-0600)] <Bosmon> CINDDY QI LI!

[13:33:49 CST(-0600)] <cindyli> ah, almost missed ur call

[13:34:06 CST(-0600)] <cindyli> Bosmon: need ur advice on how to get rid of this finalInit: https://github.com/cindyli/infusion/blob/FLUID-4908/src/webapp/components/uiOptions/js/Enactors.js#L88-93

[13:35:11 CST(-0600)] <Bosmon> cindyli - it's impossible because of the changeApplier listener

[13:35:23 CST(-0600)] <Bosmon> However, you could replace the use of the onReady event with the onCreate event

[13:35:44 CST(-0600)] <cindyli> i tried to use "expander", which didn't work because the function calls on invokers that haven't been hooked up when expander gets expanded

[13:36:11 CST(-0600)] <Bosmon> cindyli - are you using the latest framework?

[13:36:19 CST(-0600)] <cindyli> yes, i am

[13:36:21 CST(-0600)] <Bosmon> In the current model, there is no such thing as an "invoker that hasn't been hooked up"

[13:36:46 CST(-0600)] <cindyli> umm...

[13:37:10 CST(-0600)] <Bosmon> However the "getElements" call is a bit dubious

[13:37:20 CST(-0600)] <Bosmon> You can't use this kind of model for chaining invokers

[13:37:40 CST(-0600)] <Bosmon> Instead you should invoke the getElements call inside the args list of the invoker which requires it

[13:38:30 CST(-0600)] <Bosmon> The problem is that the "handleStyle" invoker does too much, and in a non-ginger way

[13:38:42 CST(-0600)]

[13:38:54 CST(-0600)] <Bosmon> cindyli - I meant of the invoker itself

[13:39:08 CST(-0600)] <Bosmon> But yes, to write an expander which calls the invoker

[13:39:23 CST(-0600)] <Bosmon> I know this is a thing that would formerly have been considered crazy

[13:40:37 CST(-0600)] <cindyli> in order to "write an expander which calls the invoker", can i call it directly in the expander function? i think no, right?

[13:40:59 CST(-0600)] <Bosmon> Here's an example from the "current" Uploader

[13:41:03 CST(-0600)]

[13:41:13 CST(-0600)] <Bosmon> This is part of the "args" definition of an invoker

[13:41:43 CST(-0600)] <Bosmon> When you are part of the "ginger process" you need to stop looking at members of the top-level "that" by hand that might not have been instantiated yet

[13:41:55 CST(-0600)] <Bosmon> Everything that you use on the "that" should be injected directly, or if a function, have its results injected

[13:42:35 CST(-0600)] <cindyli> ok

[13:42:59 CST(-0600)] <Bosmon> So, if you discover that something in the chain of things you rely on is not there, you need to inject it

[13:44:01 CST(-0600)] <Bosmon> Personally I think a clean way of doing this might be to add a listener to "handleStyle" from "onCreate"

[13:44:08 CST(-0600)] <Bosmon> You should be able to get rid of the non-standard event "onReady"

[13:45:34 CST(-0600)] <cindyli> let me take a look on the current "uploader" to have a better understanding

[13:45:46 CST(-0600)] <Bosmon> It's in my FLUID-4916 branch

[13:45:54 CST(-0600)] <cindyli> cool. thanks

[13:46:13 CST(-0600)] <Bosmon> Work is only half-done so far

[13:46:31 CST(-0600)] <Bosmon> I'm just about to make a push of some broken work to transfer from my laptop to desktop....

[13:46:40 CST(-0600)] <Bosmon> What is committed so far is working, but my next commit will be non-working

[13:47:38 CST(-0600)] <cindyli> ok, i better save the so far work as long as it's enough to help me understand the ginger way

[13:47:53 CST(-0600)] <Bosmon> Yes, the current commit is good

[13:48:08 CST(-0600)] <Bosmon> You can also look at the "new Reorderer"

[13:48:11 CST(-0600)] <Bosmon> That has been working for a while

[13:49:38 CST(-0600)] <Bosmon> https://github.com/amb26/infusion/commit/87c3af2f216a85924b36b0961691551995fa96d6

[13:49:42 CST(-0600)] <cindyli> great

[13:49:43 CST(-0600)] <Bosmon> THis commit holds a lot of the Uploader work

[13:51:34 CST(-0600)] <Bosmon> You can see that the majority of the FileQueue code has disappeared, for example

[13:59:13 CST(-0600)] <Bosmon> Btw cindyli - for https://github.com/cindyli/infusion/blob/FLUID-4908/src/webapp/components/uiOptions/js/Enactors.js#L51-L51

[13:59:40 CST(-0600)] <Bosmon> The recommended way of creating a "stub invoker" is to bind it onto a nonexistent function name - in that way it is available for stable binding by demands blocks

[14:00:03 CST(-0600)] <Bosmon> So here you might use something like fluid.uiOptions.actionAnts.getElements

[14:00:15 CST(-0600)] <Bosmon> And as for https://github.com/cindyli/infusion/blob/FLUID-4908/src/webapp/components/uiOptions/js/Enactors.js#L71-L73

[14:00:35 CST(-0600)] <cindyli> i see. doesn't matter it doesn't exist

[14:00:53 CST(-0600)] <cindyli> giving a try

[14:01:17 CST(-0600)] <Bosmon> If there is any real expectation of using an invoker that has not been bound, the recommended way of doing this is by binding it on to fluid.identity, as described in FLUID-4861 for alexn1

[14:01:39 CST(-0600)] <Bosmon> But I think that in fact you don't want to do this, and were just trying to guard against a timing issue which should really be resolved by gingerness

[14:01:46 CST(-0600)] <Bosmon> It should really be the case that either the invoker exists or it doesn't

[14:02:05 CST(-0600)] <cindyli> ok

[14:03:31 CST(-0600)] <Bosmon> But if you want the component to indeed work in a model where the user hasn't supplied an implementation for getElements as you have requested, you should instead write a demands block binding the "nonexistent long function name" you will create onto fluid.identity

[14:04:33 CST(-0600)] <Bosmon> As a further comment, it seems a bit peculiar that you have put the "setting" flag into the model

[14:04:40 CST(-0600)] <Bosmon> It should just appear as an argument to "handleStyle"

[14:04:54 CST(-0600)] <Bosmon> Of course it can STILL appear as an argument to handleStyle if you write an EL reference in its invoker

[14:04:59 CST(-0600)] <Bosmon> But I am wondering why it is there at all

[14:08:37 CST(-0600)] <Bosmon> In general the principle in the new ginger world is to avoid AS MANY AS POSSIBLE direct references to the component from the free functions that form its operations

[14:08:38 CST(-0600)] <cindyli> Bosmon: "setting" is the flag that listens to the incoming request to determine if the elements should be styled or not. isn't the model the place for it? so the changeApplier can listen and react?

[14:08:57 CST(-0600)] <Bosmon> As many as possible should be injected directly as function arguments

[14:09:15 CST(-0600)] <Bosmon> And you should work hard to organise the responsibility of the component so that these injected references are as focused as possible and from a small set

[14:09:33 CST(-0600)] <Bosmon> cindyli - it seems to make more sense to pass the "settings" condition as function arguments

[14:12:42 CST(-0600)] <cindyli> Bosmon: so that we can get rid of "that.applier.modelChanged.addListener("setting", that.handleStyle);" in the finalInit?

[14:13:18 CST(-0600)] <cindyli> even passing it in as a function argument, where should it be refer to? as an option?

[14:14:05 CST(-0600)]

[14:14:49 CST(-0600)] <cindyli> still feel model is a better place for it

[14:30:23 CST(-0600)] <Bosmon> cindyli - it could be, although "setting" seems to me an extremely strange value to place in a model

[14:30:36 CST(-0600)] <Bosmon> Since it does not refer to a piece of STATE but in fact to the mode of an operation which only occurs at one point in time

[14:33:53 CST(-0600)] <cindyli> Bosmon: ok. is "options" more proper to hold it?

[14:34:03 CST(-0600)] <Bosmon> cindyli - it doesn't seem to me like a piece of state at all

[14:36:37 CST(-0600)] <cindyli> Bosmon: i wonder how to inject the setting as a function argument if it's not anywhere on the tree

[14:38:22 CST(-0600)] <Bosmon> cindyli - clearly it comes upstream from somewhere

[14:38:31 CST(-0600)] <Bosmon> It should form part of the original function signature of the "ant method"

[14:39:09 CST(-0600)] <cindyli> i see

[14:54:20 CST(-0600)] <cindyli> Bosmon: a bit more thinking at modifying that component: if "setting" is only expected by a invoker rather than being a model value to have changeApplier listening to it, every setting change needs a explicitly call on that invoker instead of setting being automatically applied. Is that less convenient? is that the action ant behavior we want?

[15:08:27 CST(-0600)] <Bosmon> cindyli - how does the argument impact the setting being automatically applied?

[15:09:39 CST(-0600)] <Bosmon> Although perhaps the point is that different ants will have model state consisting of other than just a boolean... perhaps it's just the naming of the property that is misleading

[15:09:44 CST(-0600)] <Bosmon> Or perhaps I just misread it : P

[15:10:10 CST(-0600)] <Bosmon> I think often our convention in this case is to name the setting as "value", as we do in InlineEdit, for example

[15:10:21 CST(-0600)] <Bosmon> To emphasise that it consists of the entirety of some model state

[15:15:58 CST(-0600)] <cindyli> yay, Bosmon. i'm certainly not good at coming up with names. i will rename "setting" to "value" and keep it in the model. thanks

[15:17:25 CST(-0600)] <Bosmon> cool, good show

[15:25:26 CST(-0600)] <Bosmon> cindyli - but I still think it would be better for the value to be passed as an argument to the handler itself

[15:25:35 CST(-0600)] <Bosmon> Probably from the changeListener binder on line 89

[15:25:37 CST(-0600)] <cindyli> haha

[15:25:49 CST(-0600)] <Bosmon> Otherwise there is the standard ambiguity about whether the change has been applied to the model yet or not

[15:27:04 CST(-0600)] <cindyli> oh, ya, let me push up the changes. you can decide if that's what you expect

[15:27:28 CST(-0600)] <Bosmon> cindyli - great

[15:29:17 CST(-0600)] <cindyli> done, refresh page, Bosmon, here's the link anyway: https://github.com/cindyli/infusion/blob/FLUID-4908/src/webapp/components/uiOptions/js/Enactors.js

[15:31:47 CST(-0600)] <Bosmon> Hi cindyli - that is looking very good now

[15:31:58 CST(-0600)] <Bosmon> Although you should try to fish the changed value out of the changeRequest on line 75

[15:32:04 CST(-0600)] <Bosmon> Hopefully you will not run into a framework bug

[15:32:27 CST(-0600)] <cindyli> i see. will try that

[15:32:42 CST(-0600)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-4739

[15:32:45 CST(-0600)] <Bosmon> This JIRA is relevant

[15:32:47 CST(-0600)] <Bosmon> It should certainly be fixed

[15:34:23 CST(-0600)] <cindyli> good to know. thanks, Bosmon