fluid-tech IRC Logs-2013-05-02

[12:29:42 CDT(-0500)] <yzen> so question to you

[12:29:42 CDT(-0500)] <yzen> 1:16

[12:29:42 CDT(-0500)] <yzen> for you

[12:29:42 CDT(-0500)] <yzen> 1:17

[12:29:42 CDT(-0500)] <yzen> i have uiOptions.options.members.defaultModel

[12:29:42 CDT(-0500)] <yzen> 1:17

[12:29:42 CDT(-0500)] <yzen> that essentially a combination of all default values for any_settingsPanel.model.value

[12:29:44 CDT(-0500)] <yzen> Bosmon: ^

[12:30:06 CDT(-0500)] <Bosmon> yzen, yes

[12:30:12 CDT(-0500)] <Bosmon> PLEASE STATE YOUR QUESTION NOW : P

[12:30:42 CDT(-0500)] <yzen> yes, so the question is what's a best practice in that case

[12:31:14 CDT(-0500)] <Bosmon> Well, that is an excellent question

[12:31:35 CDT(-0500)] <Bosmon> Our previous best practice would probably have been to define an event specifically to collect these values as part of an "accumulative value"

[12:32:05 CDT(-0500)] <Bosmon> You will notice a vestigial event left behind in UIO for this purpose, which was never yet used in practice

[12:32:34 CDT(-0500)] <Bosmon> Our new best practice might be to write a Skywalker record to forward these options upwards from the individual panels

[12:32:41 CDT(-0500)] <Bosmon> Although really it shouldn't be the panels jobs to do this

[12:33:16 CDT(-0500)] <yzen> Bosmon: when you say panel you mean settings panel >

[12:33:17 CDT(-0500)] <yzen> ?

[12:34:32 CDT(-0500)] <Bosmon> yzen, yes

[12:34:46 CDT(-0500)] <Bosmon> As colinclark sometimes reminds us, "One of these legs isn't quite like the others"

[12:34:51 CDT(-0500)] <Bosmon> That is, the persistence leg of the ants

[12:34:56 CDT(-0500)] <Bosmon> Is not quite like the other two

[12:35:17 CDT(-0500)] <Bosmon> In that so far we have not planned create specialised components per option dedicated to it

[12:35:26 CDT(-0500)] <Bosmon> But still, we need to do something

[12:35:38 CDT(-0500)] <Bosmon> We can't just leap in one step to the "schema-driven UIOptions" without any designs in between : p

[12:35:54 CDT(-0500)] <yzen> is there an example of forwarding the options upwards ?

[12:36:13 CDT(-0500)] <yzen> what happens when options that are forwarded are for members, will it be put onto that?

[12:36:37 CDT(-0500)] <yzen> especially if the child component is created asynchronously on event

[12:36:40 CDT(-0500)] <yzen> ?

[12:39:53 CDT(-0500)] <yzen> Bosmon: ^

[12:41:37 CDT(-0500)] <Bosmon> yzen - the Layout Reorderer shows an example of this

[12:41:42 CDT(-0500)] <Bosmon> But no, it can't happen asynchronously

[12:42:00 CDT(-0500)] <Bosmon> But that's yet another reason why the settings panels are an inappropriate place for this

[12:42:22 CDT(-0500)] <Bosmon> CLEARLY we actually do know this information on startup

[12:43:36 CDT(-0500)] <yzen> Bosmon: ok, so right now defaults are in the settings store

[12:43:55 CDT(-0500)] <yzen> They are also duplicated in each model.value value for each settings panel

[12:44:15 CDT(-0500)] <yzen> until we have a schema, what is the appropriate place for them , Bosmon?

[13:27:52 CDT(-0500)] <yzen> Bosmon: so what would you suggest ?

[14:31:06 CDT(-0500)] <anastasiac> Bosmon, are you there?

[15:29:28 CDT(-0500)] <Bosmon> Hi, anastasiac

[15:29:42 CDT(-0500)] <Bosmon> yzen - I have no concrete suggestions as yet

[15:29:44 CDT(-0500)] <anastasiac> Hi, Bosmon

[15:29:45 CDT(-0500)] <Bosmon> Do you have any proposals?

[15:30:09 CDT(-0500)] <anastasiac> Justin and I were writing some tests using the new IoC testing framework

[15:30:33 CDT(-0500)] <anastasiac> we were looking at your TestingTests.js file for guidance

[15:31:12 CDT(-0500)] <yzen> well one could be for the time being, until the schema, have a defaultModel member of uiOptions that both panels and enactors draw the default value from , when the schema arrives we will be able to bootstrap uio with the "default" information

[15:31:39 CDT(-0500)] <anastasiac> we were wondering about the use of IoCSS on line 244, specifying an event on the component under test

[15:31:54 CDT(-0500)] <Bosmon> yzen - so the defaultModel would be initialised separately?

[15:31:58 CDT(-0500)] <anastasiac> we're wondering if this could be set on a subcomponent of the event under test - should we expect that to work?

[15:32:51 CDT(-0500)] <yzen> when the schema arrives ?

[15:32:57 CDT(-0500)] <yzen> well actually

[15:33:06 CDT(-0500)] <yzen> at this point default model could be a grade

[15:33:45 CDT(-0500)] <Bosmon> yzen - I guess this discussion really revolves around what API we plan to design, and when

[15:34:06 CDT(-0500)] <Bosmon> So far anastasiac and Justin_o's page at http://wiki.fluidproject.org/display/fluid/Designing+a+new+UIO+API doesn't have any plans for use of the model

[15:34:42 CDT(-0500)] <yzen> well it's not really a model

[15:34:51 CDT(-0500)] <yzen> it's a collection of defaults

[15:34:55 CDT(-0500)] <yzen> and it always stays the same

[15:35:46 CDT(-0500)] <Bosmon> Ok - it doesn't describe that either

[15:36:24 CDT(-0500)] <Bosmon> anastasiac - can you give an example of what you mean by "set on a subcomponent of the event under test"?

[15:37:06 CDT(-0500)] <anastasiac> Bosmon, the component we were testing is the pageEnhancer. We wanted the tests to listen for an event of the pageEnhancer's uiEnhancer subcomponent

[15:39:06 CDT(-0500)] <yzen> Bosmon: well okat this point i m trying to move on without braking tests, and centralize that information in one plaec

[15:39:28 CDT(-0500)] <Bosmon> anastasiac - that should be fine

[15:40:12 CDT(-0500)] <Bosmon> michelled - I've refreshed my PUL request with an addition for the missing includes

[15:40:17 CDT(-0500)] <Bosmon> Did you discover any other issues in your testing?

[15:40:19 CDT(-0500)] <anastasiac> ok, good. We were having troubling getting it working, and we weren't sure if that was the problem, Thanks, Bosmon

[15:40:45 CDT(-0500)] <Bosmon> anastasiac - no reason why you might still not be having trouble getting it working : P

[15:40:49 CDT(-0500)] <Bosmon> It is a very new facility after all

[15:41:15 CDT(-0500)] <anastasiac> well, yes, we're learning about it

[15:44:22 CDT(-0500)] <Bosmon> anastasiac - in case you are interested, the original JIRA which described this facility is at http://issues.fluidproject.org/browse/FLUID-4929

[15:44:30 CDT(-0500)] <anastasiac> thanks

[15:47:27 CDT(-0500)] <yzen> Bosmon: ^

[15:55:15 CDT(-0500)] <yzen> Bosmon: ok so the scope of the problem is: we have default values for a number all of our enactors and all of our panels, they are the same for the same type of preference. When we will have the schema, that default value will be derived from it directly.

[15:56:14 CDT(-0500)] <yzen> Bosmon: the derived defaults can either be stored in some central location or can be accessed through a schema accessing strategy

[16:00:00 CDT(-0500)] <Bosmon> yzen - I guess we may as well put them somewhere central then, even if it temporarily annoys our users

[16:00:14 CDT(-0500)] <Bosmon> anastasiac and Justin may have comments about what sense this makes of our upcoming API

[16:00:24 CDT(-0500)] <yzen> Bosmon: in any case it will be better than in store's defaults

[16:00:34 CDT(-0500)] <Bosmon> But it seems necessary that the defaults don't belong in the panel definitions themselves

[16:00:39 CDT(-0500)] <Bosmon> And they don't belong in the enactors

[16:00:43 CDT(-0500)] <Bosmon> And they don't belong in the store

[16:01:00 CDT(-0500)] <yzen> Bosmon: what about things liek min and max ?

[16:01:07 CDT(-0500)] <yzen> or enums ?