[06:38:24 CST(-0600)] <chrispetsos> Justin_o: Hi, do you have some time for a question?

[07:37:01 CST(-0600)] <Justin_o> chrispetsos: hello.. how are you?

[07:37:33 CST(-0600)] <chrispetsos> Hi Justin_o: i'm fine thanks.

[07:39:35 CST(-0600)] <chrispetsos> Justin_o: well, actually i was employing the repeatingSelector technique to create the two bottom adjusters shown here (http://160.40.60.238/prefsEditors/demos/adjustersPilots2/), "Magnifier location follows:" and " Screen reader follows: "

[07:41:00 CST(-0600)] <Justin_o> okay, looks like they are rendering out well

[07:41:04 CST(-0600)] <Justin_o> chrispetsos: ^

[07:41:57 CST(-0600)] <chrispetsos> Justin_o: Tried to reuse as much of their code as possible, but there were problems with their values. It seemed that the value of the one was copied to the other and vice-versa

[07:43:02 CST(-0600)] <chrispetsos> Justin_o: after some experiments, i've managed to solve this, but with less reused code. the changes can be shown here https://github.com/chrispetsos/prefsEditors/commit/3ccf4a526249a73ad2eb4b32236d5764ddf5a7b3

[07:43:22 CST(-0600)] <chrispetsos> Justin_o: "Basically, everything that has to do with the repeatingSelector mechanism (and anything dependent on that) had to be uniquely specified in the sub-adjusters."

[07:43:54 CST(-0600)] <chrispetsos> Justin_o: if you think there is any more delicate solution i'm open...

[07:47:20 CST(-0600)] <Justin_o> chrispetsos: so looking through your changes there.. gpii.prefs.panel.followingElement as a base grade.

[07:48:24 CST(-0600)] <Justin_o> chrispetsos: so one thing, which it seems you've run into, is that protoTrees don't merge. You'll have to write this out into each of your specific panel grades. I think the repeatingSelectors should merge though.

[07:52:59 CST(-0600)] <chrispetsos> Justin_o: previously, protoTrees only existed in the base grade, while now they only exist in the sub-adjusters. I've never had to merge protoTrees. I hoped that a single protoTree in the base grade would be shared correctly among two adjusters but it seems that something went wrong with the repeatingSelector technique

[07:53:52 CST(-0600)] <chrispetsos> Justin_o: I suspect that the expander used there searched throughout the page and found some IDs twice. leading to conflicts, but i'm not exactly sure about that

[07:54:14 CST(-0600)] <Justin_o> chrispetsos: that's possible, did you get an error or anything?

[07:58:10 CST(-0600)] <chrispetsos> Justin_o: Nope no errors there. I've checked out here http://160.40.60.238/prefsEditors/demos/adjustersPilots2/ the problematic version. Play around a bit with the bottom adjusters to get a feeling of what goes wrong.

[07:59:10 CST(-0600)] <chrispetsos> And the files that should interest you at that version are: 1) https://github.com/chrispetsos/prefsEditors/blob/5eda943f1e91055f4ee6fa4e8549d32327b22a43/src/shared/adjusters/js/FollowingElementAdjuster.js, 2) https://github.com/chrispetsos/prefsEditors/blob/5eda943f1e91055f4ee6fa4e8549d32327b22a43/src/shared/adjusters/js/MagnifierFollowsFollowingElementAdjuster.js, 3) https://github.com/chrispetsos/prefsEditors/blob/5eda943f1

[07:59:24 CST(-0600)] <chrispetsos> Justin_o: 3) https://github.com/chrispetsos/prefsEditors/blob/5eda943f1e91055f4ee6fa4e8549d32327b22a43/src/shared/adjusters/js/ScreenReaderFollowsFollowingElementAdjuster.js

[08:22:43 CST(-0600)] <Justin_o> chrispetsos: thanks.. i'll take a look at those

[08:30:50 CST(-0600)] <chrispetsos> Justin_o: OK , thanks, perhaps we will be able to employ a better solution when the composite panel is available

[09:13:40 CST(-0600)] <amilchev> hey Justin_o, how are you?

[09:19:04 CST(-0600)] <cindyli> anastasiac: the fix for 5203 for having more than one text field slider in one composite panel has been included in a pull request. I also modified your PFID branch to demonstrate what changes are required for integrators to use this fix: https://github.com/cindyli/infusion/tree/anastasia-PFID, you may want to take a look

[09:20:16 CST(-0600)] <anastasiac> thanks, cindyli, I'll have a look

[09:21:52 CST(-0600)] <Justin_o> amilchev: hello.. i'm alright.. how are things going?

[09:25:55 CST(-0600)] <amilchev> Justin_o: it's OK, things are moving along

[09:26:28 CST(-0600)] <Justin_o> amilchev: that's good..

[09:27:17 CST(-0600)] <amilchev> Justin_o: I faced some strange issues today and decided to ask you first, perhaps the problem is little

[09:27:25 CST(-0600)] <amilchev> wait a sec..

[09:27:31 CST(-0600)] <Justin_o> amilchev: sure

[09:32:10 CST(-0600)] <amilchev> Justin_o: first of all, this is the file to run - https://github.com/radmanovi4/prefsEditors/blob/gpii-271/demos/pcp/index.html

[09:34:10 CST(-0600)] <amilchev> Justin_o: have a look at this function - https://github.com/radmanovi4/prefsEditors/blob/gpii-271/src/shared/adjusters/pcp/js/speakText.js#L213-L216

[09:34:10 CST(-0600)]

<amilchev> It would be better if I pass the state (that.model.partialAdjustersVisibility) as an argument in line 136, instead of passing "

Unknown macro: {that}

" and storing it as a local variable, right?

[09:35:32 CST(-0600)] <Justin_o> yes, better to pass in the value you need directly

[09:36:32 CST(-0600)]

<Justin_o> which would be something like "

Unknown macro: {that}

.model.partialAdjustersVisibility"

[09:37:06 CST(-0600)] <amilchev> Justin_o: Yeah, exactly, but that value is undefined when the header is clicked

[09:37:37 CST(-0600)] <amilchev> and thus nothing it's the the hideEvent() that is always fired

[09:37:55 CST(-0600)] <Justin_o> ah okay.. new feature

[09:38:01 CST(-0600)] <amilchev> and thus it's the the hideEvent() that is always fired *

[09:38:02 CST(-0600)] <Justin_o> you need to add another property there

[09:38:13 CST(-0600)] <Justin_o> so in your showHidePartial invoker declaration

[09:38:28 CST(-0600)] <Justin_o> you need to add the key/value dynamic: true

[09:39:05 CST(-0600)]

<amilchev> Justin_o: same thing goes for this argument being "

Unknown macro: {that}

" instead of the model value --> https://github.com/radmanovi4/prefsEditors/blob/gpii-271/src/shared/adjusters/pcp/js/speakText.js#L130

[09:39:13 CST(-0600)]

<Justin_o> basically all of the arguments to an invoker now, except ones called

Unknown macro: {arguments}

. are cached.. to make them more performant.. if you have an argument that changes values.. you need to set dynamic to true

[09:40:04 CST(-0600)] <Justin_o> amilchev: yep same thing there.. set it directly to the value and make the invoker dynamic

[09:40:06 CST(-0600)] <amilchev> Justin_o: uh, that explains why most of the animation I tried to configure was .. messed up

[09:40:57 CST(-0600)] <Justin_o> amilchev: yes.. sorry about that.. keep forgetting about all of the infusion changes that have gone in.. one other thing that has changes is how you can work with strings.. I'm updating the docs on this now..

[09:40:58 CST(-0600)] <amilchev> Justin_o: I found this in MyInfusion.js - is this what I need to do?

[09:40:58 CST(-0600)] <amilchev> handleStyle: {

[09:40:58 CST(-0600)] <amilchev> funcName: "fluid.prefs.enactors.styleElements.handleStyle",

[09:40:58 CST(-0600)]

<amilchev> args: ["

Unknown macro: {arguments}

.0",

Unknown macro: {expander}

, "

Unknown macro: {that}

"],

[09:40:58 CST(-0600)] <amilchev> dynamic: true

[09:40:59 CST(-0600)] <amilchev> },

[09:41:14 CST(-0600)] <Justin_o> amilchev: yes.. that's it

[09:41:59 CST(-0600)] <amilchev> Justin_o: ok, I'm glad it's such a small issue will fix it right away

[09:42:01 CST(-0600)] <amilchev> thank you

[09:42:32 CST(-0600)] <Justin_o> amilchev: let me know if you come across any other issues..

[09:43:42 CST(-0600)] <amilchev> Justin_o: as far as acknowledging new Infusion features being added - I suggest posting on the list whenever a new doc is completed, as Anastasia promised to do with the composite panel

[09:44:30 CST(-0600)] <amilchev> Justin_o: sure, no problem.. I'm actually taking off, have a nice day

[09:45:06 CST(-0600)] <Justin_o> amilchev: good suggestion.. have a good day..

[10:13:03 CST(-0600)] <Justin_o> anastasiac: i've updated the localization in the prefs framework doc.. i'm sure it could use some touchups though http://wiki.fluidproject.org/display/docs/Localization+in+the+Preferences+Framework

[10:13:21 CST(-0600)] <anastasiac> Thanks, Justin_o, I'll have a look

[10:13:44 CST(-0600)] <Justin_o> anastasiac: thanks

[10:16:11 CST(-0600)] <Justin_o> jhung: are you ready to talk about FSS stuff at the community meeting this week?

[10:17:16 CST(-0600)] <jhung> Justin_o: can we schedule next Wednesday? I have an appointment this Wednesday and won't be in the office.

[10:17:24 CST(-0600)] <Justin_o> jhung: no problem

[10:17:32 CST(-0600)] <jhung> Justin_o: cool thanks

[10:17:32 CST(-0600)] <Justin_o> jhung: so Nov 13

[10:17:37 CST(-0600)] <jhung> yep

[10:18:04 CST(-0600)] <Justin_o> jhung: okay.. scheduled.. thanks

[10:18:52 CST(-0600)] <Justin_o> fluid-everyone: anyone have any topics they'd like to cover or be covered for a community meeting this month? I'll probably be scheduling some for doc sprints

[10:20:07 CST(-0600)] <michelled> Justin_o: I think it would be good to hear about Jon's research into CSS libraries

[10:20:26 CST(-0600)] <Justin_o> michelled: yes.. scheduled that one just now for Nov 13

[10:20:28 CST(-0600)] <michelled> oh, just saw you already talked about that

[10:20:33 CST(-0600)] <Justin_o>

[10:21:53 CST(-0600)] <Justin_o> anastasiac: how many doc sprints would you like to do this month at the community meetings?

[10:22:13 CST(-0600)] <anastasiac> all of them?

[10:22:40 CST(-0600)] <anastasiac> Justin_o, why don't we schedule what other people would like (like Jon) and then fill the gaps with docs sprints?

[10:23:43 CST(-0600)] <Justin_o> anastasiac: okay.. cool.. are you open to doing one this week.. if not we can do the build tools stuff again

[10:25:52 CST(-0600)] <anastasiac> Justin_o, I'm up for this week, certainly!

[10:27:54 CST(-0600)] <Justin_o> anastasiac: okay.. how does this look http://wiki.fluidproject.org/display/fluid/Community+workshops

[10:28:24 CST(-0600)] <anastasiac> wow, excellent, Justin_o

[10:28:43 CST(-0600)] <Justin_o> you get almost all of them

[10:28:55 CST(-0600)] <Justin_o> too bad there aren't anymore donuts

[11:28:58 CST(-0600)] <Justin_o> colinclark, Bosmon: do dynamic grades all have to have the same options?

[11:29:20 CST(-0600)] <colinclark> I don't know the answer to that question, but perhaps yzen does

[11:29:48 CST(-0600)] <Justin_o> colinclark, Bosmon, yzen: sorry.. i meant dynamic components

[11:30:16 CST(-0600)] <yzen> Justin_o: well not necessarily , if they are used in combination with dynamic grades?

[11:31:09 CST(-0600)] <colinclark> Justin_o: https://github.com/fluid-project/infusion/blob/master/src/tests/framework-tests/core/js/FluidIoCTests.js#L3106-L3120

[11:31:30 CST(-0600)] <colinclark> You can see an example in this test case of a dynamic component being created as the result of a particular event

[11:31:39 CST(-0600)] <colinclark> and certainly you can bind options to the arguments of that event

[11:31:47 CST(-0600)] <colinclark> Is that something like what you need?

[11:31:53 CST(-0600)] <colinclark> or what are you looking for?

[11:32:25 CST(-0600)] <Justin_o> colinclark: that's interesting...

[11:34:28 CST(-0600)] <Justin_o> colinclark: what I'm looking at is for the gpii composite panel that will be used by the pmt and pcp.. so there are a couple of types of expansion of the panel. 1) is when you turn on a preference you get specific adjusters for it.. for example turning on speak text will show the adjusters for volume and speech rate 2) for showing the extra adjusters like

[11:34:28 CST(-0600)] <Justin_o> voice pitch and language

[11:35:18 CST(-0600)] <Justin_o> colinclark: what i'm thinking is that for the extra adjusters it would be easy to use a dynamic component based on DOM elements.. but for the first expansion, it has to be model bound to a specific preference value

[11:35:37 CST(-0600)] <Justin_o> colinclark: and there could be multiples of these within a single panel

[11:41:58 CST(-0600)] <Justin_o> maybe it shouldn't be a component and the configuration will just have to be a bit heavier for the integrator

[12:05:16 CST(-0600)] <Bosmon> Justin_o - sounds like a mess : P

[12:05:23 CST(-0600)] <Bosmon> Can you explain the different scenarios in more detail?

[12:05:30 CST(-0600)] <Bosmon> What kind of dynamism is required?

[12:21:45 CST(-0600)] <Justin_o> Bosmon: here are the wireframes http://wiki.fluidproject.org/download/attachments/34570511/adjusters-for2ndpilots.pdf?version=7&modificationDate=1383157258814&api=v2

[12:22:25 CST(-0600)] <Justin_o> Bosmon: in particular you can look at visual alternatives

[12:23:10 CST(-0600)] <Justin_o> Bosmon: i was talking with cindyli, and perhaps we'll do the model bound expansion just as configuration that will need to be supplied to the composite panel.. which is possible to do through the auxschema

[12:24:57 CST(-0600)] <Justin_o> Bosmon: by the way, can you please take a look at cindyli and my pull requests.. we need those in to update chris and alex's code

[12:40:53 CST(-0600)] <Bosmon> Justin_o - I heard that there was a functional issue with your radio button rewriting pull - is that resolved now?

[12:42:23 CST(-0600)] <Justin_o> Bosmon: was that the issue with passing down options to the slider.. if so, that was fixed in cindyli's pull request

[12:42:29 CST(-0600)] <Justin_o> anastasiac: is there another issue

[12:42:31 CST(-0600)] <Justin_o> ?

[12:43:53 CST(-0600)] <anastasiac> sorry, I'm trying to catch up. Are you asking in general, or about something specific from your memory? Are you referring to the conversation we had today after stand-up, Justin_o?

[12:44:32 CST(-0600)] <Justin_o> anastasiac: referring to Bosmon's comment about a technical issue with my pull request

[12:45:47 CST(-0600)] <anastasiac> ah, I don't think so...

[12:46:50 CST(-0600)] <Justin_o> anastasiac: thanks

[12:48:55 CST(-0600)] <Bosmon> "[07:06] <cindyli> chrispetsos: anastasiac found a bug yesterday (http://issues.fluidproject.org/browse/FLUID-5203) that options from subpanels are not handled properly in some cases. So, you may have problem implementing what you want by using composite panels with the current infusion lib in gpii repo. we will update the gpii infusion once all major issues with composite panels are

[12:48:55 CST(-0600)] <Bosmon> addressed."

[12:49:08 CST(-0600)] <Bosmon> Is this the same issue that anastasiac was observing in her branch named "PFID" ?

[12:49:37 CST(-0600)] <anastasiac> I think that was referring to the problem that make multiple sliders not work

[12:49:39 CST(-0600)] <cindyli> Bosmon, anastasiac, that's the text field slider issue that anastasiac found and have been fixed in my pull request

[12:49:46 CST(-0600)] <Bosmon> cindyli - thanks

[12:49:50 CST(-0600)] <cindyli> FLUID-5203

[12:49:54 CST(-0600)] <Bosmon> How can I verify this issue?

[12:51:03 CST(-0600)] <cindyli> Bosmon: anastasiac has some testing code that I compared before and after - https://github.com/cindyli/infusion/tree/anastasia-PFID

[12:51:16 CST(-0600)] <cindyli> perhaps i should make a unit test for it

[12:51:50 CST(-0600)] <Bosmon> So there isn't some test code in trunk that I can use to demonstrate the fix?

[12:52:09 CST(-0600)] <sgithens> DEMONSTRATE!

[12:55:06 CST(-0600)] <cindyli> Bosmon: not yet, adding now

[12:55:53 CST(-0600)] <Bosmon> Ok, thanks cindyli!

[12:56:03 CST(-0600)] <Justin_o> Bosmon: in the meantime, anymore thoughts on dynamic stuff or should i stick with the configuration option i mentioned

[12:57:21 CST(-0600)] <Bosmon> Justin_o - I don't think I have enough detail to understand the problem yet

[12:58:09 CST(-0600)] <Justin_o> Bosmon: okay.. i'll try to detail some more.. did you look at the wireframes?

[12:59:11 CST(-0600)] <Bosmon> Justin_o - yes - but it's not clear which one of them I am looking at

[12:59:37 CST(-0600)] <Justin_o> Bosmon: no problem.. i'll try to walk you through it.. so lets look at the Visual Alternatives panel

[13:00:20 CST(-0600)] <Justin_o> Bosmon: in my mind this is a single composite panel, where each adjuster inside is an individual subpanel

[13:01:13 CST(-0600)] <Justin_o> Bosmon: you'll notice through the wireframe that there are two types of expansion 1) turning Speak Text on and off will reveal/hide the "Words Spoken per minute" and "Volume" adjusters

[13:01:50 CST(-0600)] <Justin_o> Bosmon: you'll also notice "more" which will show even more adjusters like "Voice Pitch"

[13:02:06 CST(-0600)] <Justin_o> that last part is 2)

[13:02:33 CST(-0600)] <Bosmon> Justin_o - ok, so you have some model-driven elements to the component

[13:03:02 CST(-0600)] <Justin_o> so for part 2) i think it will be easy to handle with a dynamic component that is created based on DOM elements which are containers around the more adjusters

[13:03:11 CST(-0600)] <Bosmon> I suggest that these should be addressed by gearing some changes to the model to a traditional fluid event which becomes the "createOnEvent" for a fresh panel subcomponent

[13:03:29 CST(-0600)] <Bosmon> Unfortunately our infrastructure for this kind of problem is not great, but it is sort of workable

[13:03:52 CST(-0600)] <Bosmon> There will be dedicated support for this kind of thing in the "new modelRelay" and "new Renderer"

[13:04:06 CST(-0600)] <Justin_o> Bosmon: i don't think that would work with the composite panel structure as it is.. since it works on all sub panel components at once

[13:04:14 CST(-0600)] <Justin_o> for rendering and the such

[13:04:36 CST(-0600)] <Justin_o> also how would you remove it

[13:04:41 CST(-0600)] <Bosmon> Justin_o - in what sense does it "work on all subpanel components at once"?

[13:04:57 CST(-0600)] <Bosmon> Justin_o - I imagine you would remove it by calling "destroy" on the subcomponent and then calling refreshView

[13:05:03 CST(-0600)] <Justin_o> Bosmon: well the composite panel needs to handle the rendering of all the subcomponetns

[13:05:15 CST(-0600)] <Bosmon> Justin_o - doesn't it already? : P

[13:05:20 CST(-0600)] <Justin_o> well all sub panels.. not necessarily all sub components

[13:05:25 CST(-0600)] <Justin_o> Bosmon: yes..

[13:05:41 CST(-0600)] <Justin_o> there's not way to say, render me this sub panel but not that one

[13:05:53 CST(-0600)] <Bosmon> Justin_o - the way to do this is by the subpanel not actually existing!

[13:06:12 CST(-0600)] <Bosmon> If it is annotated with "createOnEvent" and the event has not occurred, then I would presume it would not be rendered

[13:06:16 CST(-0600)] <Bosmon> As a result of not being there

[13:07:21 CST(-0600)] <Justin_o> Bosmon: but the rendering is not controlled by the sub panels. the composite panel does all that.. so if shows up in the components block it will render out it's markup.. the sub panels are all created with a createOnEvent of "initSubPanels"

[13:08:00 CST(-0600)] <Bosmon> Justin_o - how can it render out the markup if there is no existing component corresponding to the subpanel?

[13:08:13 CST(-0600)] <Bosmon> Surely it can only render out markup for which it has a component which has produced a protoTree

[13:09:05 CST(-0600)] <Justin_o> Bosmon: this is true, they are sort of fakely created in advance in a dummy DOM element..

[13:09:18 CST(-0600)] <Bosmon> Justin_o - my idea is that the subpanel will have a further subpanel which will decorate its component tree further, if it exists

[13:09:35 CST(-0600)] <colinclark> michelled and jessm: Here's my sketch of an abstract for the Digital Media and Learning Conference in Boston next March: https://www.piratepad.ca/p/floe-dml-proposal

[13:09:45 CST(-0600)] <Justin_o> Bosmon: you mean a composite panel in the composite panel?

[13:09:46 CST(-0600)] <colinclark> Could you two review and refine it, and then I'll submit it for us?

[13:09:58 CST(-0600)] <colinclark> Here is the CFP, in case it helps, michelled and jessm: http://dml2014.dmlhub.net/call-for-proposals/

[13:10:12 CST(-0600)] <Justin_o> Bosmon: there are issues of expression in the auxiliary schema to worry about too though

[13:10:18 CST(-0600)] <michelled> thanks colinclark - sure

[13:10:29 CST(-0600)] <Bosmon> Justin_o - or it could occur at top level - I guess if you already have a "createOnEvent" you might have to boil the creation event to also include "initSubPanels"

[13:11:26 CST(-0600)] <Justin_o> Bosmon: not sure i'm following completely.. but i'm guessing you are saying that some sub panels are created on another event.. say onSpeakText which is comprised of a model event and the initSubPanels event

[13:11:38 CST(-0600)] <Bosmon> Justin_o - something like that, yes

[13:11:54 CST(-0600)] <Bosmon> And you can write some more aux schema to gear that to a particular model change event

[13:12:04 CST(-0600)] <Bosmon> As well as gearing the destruction of the component to the inverse model change

[13:12:15 CST(-0600)] <Justin_o> Bosmon: two issues 1) the markup would still have been rendered even though it isn't usable, 2) how would you destroy it

[13:12:36 CST(-0600)] <Bosmon> Justin_o - shouldn't the algorithm be adjusted to not render markup for nonexistent components? : P

[13:12:58 CST(-0600)] <Justin_o> Bosmon: it's hard to know what a non-existent component would be

[13:13:07 CST(-0600)] <Justin_o> Bosmon: at the time of rendering they are all non-existent

[13:13:16 CST(-0600)] <Bosmon> Justin_o - that sounds a little crazy to me, and should be adjusted

[13:13:17 CST(-0600)] <Justin_o> since they are actually all created after render

[13:13:32 CST(-0600)] <Bosmon> How do you get a component tree out of them if they are non-existent?

[13:13:38 CST(-0600)] <Justin_o> Bosmon: they have to be created after render or the renderer will break all of their DOM bindings

[13:17:40 CST(-0600)] <Bosmon> Justin_o ^

[13:21:57 CST(-0600)] <Justin_o> Bosmon: i had thought i had changed this a bit for the pull request, but i guess not.. anyways.. here's how https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L144-L145

[13:22:21 CST(-0600)] <Justin_o> so you can see it is created onInit, but not rendered, then when it is rendered they are recreated

[13:38:40 CST(-0600)] <Justin_o> Bosmon: so i could probably do something so that it ignores components that don't exist on the component yet when rendering.. but, how will i destroy a component?

[13:38:53 CST(-0600)] <Justin_o> and prevent it from returning again

[13:39:29 CST(-0600)] <Justin_o> i imagine that subsequent afterRender events would trigger the recreation of the component

[13:44:24 CST(-0600)] <Bosmon> Justin_o it would have an different event for its onCreate, one which was only fired by a positive model change

[13:44:51 CST(-0600)] <Bosmon> And it would be destroyed by a listener attached to the opposite model change

[13:51:03 CST(-0600)] <Justin_o> Bosmon: but it would also have to be recreated after each rendering to ensure that any dom bindings are re-established

[13:51:21 CST(-0600)] <Justin_o> Bosmon: also i don't know how to destroy a component

[13:52:07 CST(-0600)] <Justin_o> Bosmon: i would assume that once it's being created by a render event, it will continue to be recreated even after i destroyed it

[13:58:11 CST(-0600)] <Bosmon> Justin_o - you call the "destroy" method

[13:58:27 CST(-0600)] <Bosmon> It is not created by the render event, but a boiled combination of the render event and the "model condition event"

[13:59:24 CST(-0600)] <Justin_o> Bosmon: sure, but once it's triggered won't it keep on recreating it.. on subsequent render calls

[14:00:02 CST(-0600)] <Bosmon> Justin_o - only if the same boiled event fires

[14:00:18 CST(-0600)] <Bosmon> I guess this issue is tricky since the existing boiling semantic doesn't cover this case

[14:00:22 CST(-0600)] <Justin_o> Bosmon: okay.. but then i'll have the opposite problem where rerendering will break it

[14:00:48 CST(-0600)] <Bosmon> You will have to have an event that fires i) on the rerender event, but ii) only if a particular model condition is true

[14:02:10 CST(-0600)] <Justin_o> Bosmon: right.. so it will not be a traditional aggregate event, but really an event handler for afterRender that checks the model state and decides whether or not to fire the other event

[14:02:35 CST(-0600)] <Justin_o> Bosmon: does that sound about right?

[14:05:33 CST(-0600)] <Bosmon> Justin_o - I think that is all we can do with the current framework, yes

[14:05:58 CST(-0600)] <Bosmon> But that it's quite right, since it actually also needs to listen to the model event and use it to fire afterRender itself

[14:06:01 CST(-0600)] <Bosmon> isn't

[14:06:37 CST(-0600)] <Justin_o> Bosmon: yes.. that's true.. but that could be done with a regular listener i would guess

[14:08:55 CST(-0600)] <Justin_o> so i still have a question about the more/less expansion.. which is the second level expansion of adjusters.. i would imagine that all of the extra adjusters would also be created at the same time, but some would be hidden with the more/less toggle.. how would i go about creating this, since the markup for the sub panels will be nested within this toggle..

[14:08:55 CST(-0600)] <Justin_o> meaning.. how do i keep it from rendering when it shouldn't since the markup for the toggle will likely be tied to the markup of the composite panel.. since it needs to be aware of the placement of the panels

[14:10:28 CST(-0600)] <Justin_o> i guess i could just bind it to a model event as well..

[14:11:22 CST(-0600)] <Justin_o> Bosmon: do you think this will just all end up being a lot more work for an integrator than just using straight configuration for hiding and showing elements based on model events.. it just seems like this will be a lot for an integrator to write out

[14:15:34 CST(-0600)] <Justin_o> Bosmon: I'm also worried that all this will make the auxschema quite complicated

[14:15:45 CST(-0600)] <Justin_o> both for us to implement and for an integrator to write

[14:16:56 CST(-0600)] <Bosmon> Justin_o - all of this will be encoded by a simple string in the aux schema

[14:17:06 CST(-0600)] <Bosmon> All the interpretation of it will go into an intelligent grade which you write

[14:17:16 CST(-0600)] <Bosmon> YOU will write this out, not the integrator....

[14:17:31 CST(-0600)] <Justin_o> Bosmon: how do you imagine it will look in the schema?

[14:18:05 CST(-0600)] <Bosmon> An annotation attached to a panel which says something like "renderOnModelPath": "textToSpeech" or something like that

[14:20:35 CST(-0600)] <Justin_o> hmm.. i guess this would only be specified in a composite panel, so would have to be added there..

[14:21:29 CST(-0600)] <Justin_o> Bosmon: okay.. i'll look into this.. thanks for the help

[14:22:07 CST(-0600)] <Bosmon> Good luck, Justin_o!

[14:22:22 CST(-0600)] <Bosmon> I'm flying out in half an hour but I will be around quite frequently in the next 2 weeks

[14:22:39 CST(-0600)] <Justin_o> oh okay.. didn't realize you were going somewhere. vacation?

[14:22:44 CST(-0600)] <Bosmon> yes

[14:22:57 CST(-0600)] <Justin_o> have a good trip.. i'll try not to bother you too much :0

[14:22:58 CST(-0600)] <Justin_o>

[14:52:30 CST(-0600)] <Justin_o> Bosmon: is it okay.. to have other options in the components block

[14:52:37 CST(-0600)] <Justin_o> other than type and createOnEvent

[14:52:50 CST(-0600)] <Justin_o> for example could i add a renderOnModelPath option there?

[14:53:04 CST(-0600)] <Justin_o> or createOnModelPath value

[14:53:57 CST(-0600)] <Bosmon> Justin_o somewhat, although this configuration would need to be interpreted "before" the component is instantiated and so couldn't necessarily be operated by a grade attached to the component afterwards

[14:54:16 CST(-0600)] <Bosmon> Since it will need to evaluate to a genuine "createOnEvent" field which appears in the subcomponent record one level higher up, rather than in the component's options

[14:54:27 CST(-0600)] <Bosmon> Perhaps this is another good reason for abolishing this level of containment in component trees

[14:56:05 CST(-0600)] <Justin_o> interesting.. i'm thinking if it's there i can automate the in the composite panel all the event binding and etc.. instead of having to offset this to the auxbuilder..

[14:56:33 CST(-0600)] <Justin_o> maybe it should just be in the auxbuilder though with support functions alongside the composite panel

[14:57:41 CST(-0600)] <Bosmon> Justin_o - you will write some "support grades", yes

[14:57:49 CST(-0600)] <Justin_o> hmm i guess it will have to go in the auxbuilder.. i think i just understood the issue you were raising with the fact that the createOnEvent would need to be set

[14:57:58 CST(-0600)] <Bosmon> And the function of the auxbuilder will just be to attach them with some munged configuration

[14:58:44 CST(-0600)] <Justin_o> the problem is that there may be multiple model paths to listen to... so we would have to have many events to bind

[14:58:50 CST(-0600)] <Justin_o> i don't think we could know all that in advance

[15:02:36 CST(-0600)] <cindyli> Bosmon: i added a unit test for the pull request for text field slider (https://github.com/fluid-project/infusion/pull/431). but this pull request is now dependent on justin's pull request https://github.com/fluid-project/infusion/pull/432 since that pull request fixed an issue with composite panels at rendering decorators from sub-panel protoTree.

Browser not supported