fluid-tech IRC Logs-2013-08-08

[12:38:26 CDT(-0500)] <Bosmon7> Hi cindyli - did my resurrected comment make sense?

[12:38:38 CDT(-0500)] <cindyli> it did, Bosmon7

[12:40:21 CDT(-0500)] <Bosmon7> cool

[12:44:28 CDT(-0500)] <cindyli> Bosmon7: can you take a look on the change i made so far for ur comment to see if it's on the right track?

[12:44:30 CDT(-0500)] <cindyli> https://github.com/cindyli/infusion/compare/jobara:FLUID-4907...cindyli:FLUID-4907-5109

[12:45:31 CDT(-0500)] <cindyli> the change is not fully functioning yet. it breaks the schema demo for full page with preview

[12:50:21 CDT(-0500)] <Bosmon7> Hi cindyli - it looks reasonable, but can you explain how this change interacts with the schema configuration?

[12:51:21 CDT(-0500)] <cindyli> Bosmon7: this change does not require any special schema configuration

[12:52:59 CDT(-0500)] <Bosmon7> cindyli - yes, but what plan do you have for a schema-driven user of UIO to gain access to your implementation?

[12:53:15 CDT(-0500)] <Bosmon7> That is, how will the instance of access to the staticEnvironment from Builder.js be replaced?

[12:55:18 CDT(-0500)] <cindyli> that part is now handled at one place by pageEnhancer and the builder is using fluid.pageEnhancer rather than fluid.uiEnhancer,

[12:55:36 CDT(-0500)] <cindyli> does that answer ur question?

[13:00:24 CDT(-0500)] <Bosmon7> cindyli - ok yes, I see this now

[13:00:50 CDT(-0500)] <Bosmon7> Is there any possibility that the consumer of the built enhancer doesn't actually want a pageEnhancer but a plain uiEnhancer?

[13:05:13 CDT(-0500)] <cindyli> the difference btw page enhancer and ui enhancer is the former, 1. keeps track both original user options and place it into static env, 2. place ui enhancer into static env, 3. set up initial uie model. other than those, they are pretty much same

[13:05:41 CDT(-0500)] <cindyli> all our current design requires uie in the static env.

[13:07:17 CDT(-0500)] <cindyli> i was thinking about use cases to use plain ui enhancer. it would be possible if integrators have their own ways to hook up uie with their app

[13:08:56 CDT(-0500)] <cindyli> that would not be a easy task, i figure

[13:09:13 CDT(-0500)] <cindyli> possible tho

[13:19:09 CDT(-0500)] <Bosmon7> cindyli - perhaps the exact grade added to the root of the built UIE could be an option with a default value

[13:20:16 CDT(-0500)] <Bosmon7> yzen is asking a question about kettle, I believe

[13:20:42 CDT(-0500)] <yzen> Bosmon7: yes

[13:20:50 CDT(-0500)] <yzen> Bosmon7: I'm taking kettle out from univeral

[13:21:05 CDT(-0500)] <Bosmon7> yzen - great

[13:21:10 CDT(-0500)] <yzen> but trying to figure out where the config related stuff belongs

[13:21:15 CDT(-0500)] <yzen> universal or kettle

[13:21:21 CDT(-0500)] <Bosmon7> yzen - which stuff do you mean in particular?

[13:21:36 CDT(-0500)] <yzen> so the whole reason i have this dilemma is because of the problem

[13:22:00 CDT(-0500)] <yzen> configs contain configuration for components in the gpii namespace

[13:22:23 CDT(-0500)] <yzen> when we init from config i would need those components loaded

[13:22:27 CDT(-0500)] <Bosmon7> ok

[13:22:39 CDT(-0500)] <Bosmon7> Well, the config loader mechanism itself belongs in kettle

[13:22:49 CDT(-0500)] <Bosmon7> But anything referring to a gpii namespaced component clearly belongs in universal

[13:24:22 CDT(-0500)] <yzen> Bosmon7: yes

[13:24:27 CDT(-0500)] <yzen> well let me give you an example

[13:24:31 CDT(-0500)] <yzen> we have a config for pref server

[13:25:29 CDT(-0500)] <yzen> it declared a single component of type kettle.server with an app component gpii.preferencesServer

[13:25:36 CDT(-0500)] <yzen> kettle reads the config

[13:25:40 CDT(-0500)] <yzen> makes defaults

[13:25:45 CDT(-0500)] <yzen> declares demands

[13:25:49 CDT(-0500)] <yzen> BUT

[13:25:53 CDT(-0500)] <yzen> at the point of initialization

[13:26:11 CDT(-0500)] <yzen> i need to have gpii pref server node module loaded

[13:28:16 CDT(-0500)] <Bosmon7> yzen - can you expand on that point?

[13:28:24 CDT(-0500)] <yzen> sure

[13:28:39 CDT(-0500)] <yzen> so config contains material that is used to declare demands and defaults

[13:29:09 CDT(-0500)] <yzen> then the config loader proceeds to initialize the component at the top of the component tree (e.g. that conns all the servers)

[13:30:01 CDT(-0500)] <yzen> at that point component types in the subtree are not necessarily in kettle name space (they are not loaded as part of kettle)

[13:30:32 CDT(-0500)] <Bosmon7> yzen - so it sounds like the issue is that the config loader needs to initialise servers which have some mutual dependence relations?

[13:30:53 CDT(-0500)] <Bosmon7> That is, at least one other server requires that the preference server has loaded first, before it initialises?

[13:31:19 CDT(-0500)] <yzen> yes preference server module that is

[13:32:16 CDT(-0500)] <Bosmon7> yzen - so how is that dependence currently managed with the "everything in universal" approach?

[13:32:26 CDT(-0500)] <yzen> we load everything

[13:33:01 CDT(-0500)] <Bosmon7> yzen - how do you ensure that the load occurs in the correct order?

[13:34:35 CDT(-0500)] <yzen> Bosmon7: so right now we do this https://github.com/GPII/universal/blob/master/gpii/node_modules/gpiiFramework/configLoader.js#L22-L32

[13:35:07 CDT(-0500)] <Bosmon7> yzen - oh yes, I remember now

[13:35:09 CDT(-0500)] <Bosmon7> How dreadful : P

[13:35:11 CDT(-0500)] <yzen> yes

[13:35:12 CDT(-0500)] <yzen>

[13:35:16 CDT(-0500)] <yzen> it needs to be fixed

[13:35:17 CDT(-0500)] <yzen>

[13:36:50 CDT(-0500)] <yzen> suggestions ?

[13:38:25 CDT(-0500)] <Bosmon7> yzen - the solution takes the form of all of our solutions

[13:38:37 CDT(-0500)] <Bosmon7> You will draw up a little JSON structure that holds a list of modules to be "required"

[13:39:50 CDT(-0500)] <yzen> Bosmon7: i was thinking of adding that to a config file yes

[13:39:51 CDT(-0500)] <Bosmon7> But it seems this should be properly modularised, so that this allows modules to remain self-contained

[13:39:52 CDT(-0500)] <yzen> ok gots it

[13:39:56 CDT(-0500)] <Bosmon7> yzen - cool

[15:09:53 CDT(-0500)] <yzen> Bosmon7:

[15:10:03 CDT(-0500)] <yzen> Bosmon7: ayt?

[15:12:12 CDT(-0500)] <Bosmon7> Hi yzen

[15:12:49 CDT(-0500)] <yzen> Bosmon7: so just referencing modules just by their name is probably impossible don't you think?

[15:13:01 CDT(-0500)] <yzen> given that i execute a config loader from kettle

[15:13:38 CDT(-0500)] <Bosmon7> yzen - it will have to be enough!

[15:13:49 CDT(-0500)] <Bosmon7> The use of kettle will have to pass in a module loader from their own location

[15:13:52 CDT(-0500)] <Bosmon7> The user

[15:14:16 CDT(-0500)] <yzen> can you elaborate ?

[15:14:20 CDT(-0500)] <Bosmon7> If we can't load in a module by name, we could hardly expect to load it in given something else.....

[15:14:34 CDT(-0500)] <Bosmon7> yzen - similar to the way that a "require" is the argument to all of our own framework require functions

[15:14:51 CDT(-0500)] <Bosmon7> When the consumer of kettle from universal starts it up, they will have to pass their own "require" to it

[15:15:38 CDT(-0500)] <yzen> how would they do it ?

[15:16:09 CDT(-0500)] <Bosmon7> yzen - as an argument!

[15:16:15 CDT(-0500)] <Bosmon7> To ....... a function!!

[15:16:16 CDT(-0500)] <yzen> no i understand

[15:16:22 CDT(-0500)] <Bosmon7> Such things still exist, even in this modernised world....

[15:16:24 CDT(-0500)] <yzen> but where would it come from ?

[15:16:34 CDT(-0500)] <Bosmon7> Well they are always given one by node

[15:16:39 CDT(-0500)] <Bosmon7> Just the same way they are now

[15:19:55 CDT(-0500)] <yzen> Bosmon7: but how a consumer can be started up without kettle knowing where it is?

[15:20:17 CDT(-0500)] <Bosmon7> yzen - it is the consumer that starts up kettle, not vice versa

[15:20:25 CDT(-0500)] <Bosmon7> And so naturally the consumer can supply the necessary startup arguments

[15:20:29 CDT(-0500)] <Bosmon7> Including its own "require"

[15:20:42 CDT(-0500)] <yzen> Bosmon7: ok

[15:20:48 CDT(-0500)] <yzen> the current way we start up

[15:20:55 CDT(-0500)] <yzen> is we call config loader with a config

[15:21:01 CDT(-0500)] <yzen> config loader will belong to kettle

[15:21:18 CDT(-0500)] <yzen> so the start up process will be different wouldn't it ?

[15:24:08 CDT(-0500)] <yzen> Bosmon7: ^

[15:24:18 CDT(-0500)] <Bosmon7> yzen - yes

[15:24:28 CDT(-0500)] <Bosmon7> We will supply the module loader and some other arguments, together with the config