fluid-work IRC Logs-2011-04-27

[12:54:19 CDT(-0500)] <Justin_o> heidi: i think we forgot about removing the :focus overrides that were used before we scoped it to fl-focus
[12:54:30 CDT(-0500)] <Justin_o> i think i'll reopen FLUID-3880 for this
[12:54:54 CDT(-0500)] <heidi> Justin_o in the themes?
[12:55:09 CDT(-0500)] <Justin_o> in demo and component css files
[13:03:13 CDT(-0500)] <Justin_o> heidi: when you get a chance could you please take a look at my FLUID-4186 branch https://github.com/jobara/infusion/tree/FLUID-4186
[13:03:32 CDT(-0500)] <heidi> Justin_o will do
[13:03:35 CDT(-0500)] <Justin_o> thanks
[13:25:35 CDT(-0500)] <heidi_> Justin_o folks here cool with irc dev meeting
[13:25:52 CDT(-0500)] <Justin_o> heidi_: okay.. thanks
[13:29:51 CDT(-0500)] <Justin_o> fluid-everyone: For the dev meeting I'd like to talk about the FLUID Contributor Gallery.. in particular regarding FSS... is there anything else that anyone would like to talk about?
[13:30:33 CDT(-0500)] <colinclark> woah capital FLUID
[13:30:39 CDT(-0500)] <colinclark> That sounds like an interesting topic, Justin_o
[13:30:46 CDT(-0500)] <colinclark> I think Bosmon probably wants to talk about naming
[13:30:59 CDT(-0500)] <Justin_o> colinclark: sorry.. used to typing jira numbers
[13:31:04 CDT(-0500)] <colinclark> lol
[13:31:07 CDT(-0500)] <heidi_> haha
[13:31:11 CDT(-0500)] <colinclark> i'm just teasing
[13:33:34 CDT(-0500)] <Justin_o> should i start? or are people still getting ready?
[13:34:03 CDT(-0500)] <anastasiac> I think most are ready
[13:34:11 CDT(-0500)] <Justin_o> anastasiac: thanks.. okay..
[13:35:30 CDT(-0500)] <Justin_o> So I think we had talked about this a bit at a previous dev meeting. Basically we had decided that there will be some things that we'll want to share with our users but may not want to be part of Infusion itself. In particular this came up around some css contributions that we were going to get, which were good but maybe didn't fit under what FSS is meant to be.
[13:35:49 CDT(-0500)] <Justin_o> I've started a space on the wiki for these
[13:35:50 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/FSS+Contributor+Gallery
[13:36:09 CDT(-0500)] <Justin_o> in the future they will live somewhere else and be accessible through our build system, but this is a start for Infusion 1.4
[13:36:28 CDT(-0500)] <Justin_o> any comments about that page so far
[13:36:31 CDT(-0500)] <Justin_o> ?
[13:36:52 CDT(-0500)] <Justin_o> so what i'm really curious about right now, is what sort of standards should we have for here
[13:36:54 CDT(-0500)] <Justin_o> any requirements
[13:37:12 CDT(-0500)] <Justin_o> what other information should be present.. like which configurations is it expected to work in and dependencies and etc.
[13:37:15 CDT(-0500)] <Justin_o> any thoughts?
[13:37:24 CDT(-0500)] <anastasiac> a general comment: It might be nice to have some text describing what's in the contribution, etc.
[13:37:26 CDT(-0500)] <heidi_> i liked the template-for-contributions idea. a blueprint a contributor could follow to submit their styles
[13:37:44 CDT(-0500)] <anastasiac> heidi_, could you elaborate on the template idea?
[13:37:54 CDT(-0500)] <heidi_> i imagine in that template would be some sort of readme/howto/example and those might be meaningful to pull out and display in this contributor space
[13:38:08 CDT(-0500)] <Justin_o> anastasiac: there is a description there.. it jus doesn't look like one because i didn't know how to describe them well.. it's basically what that text under the screenshots should be
[13:38:31 CDT(-0500)] <heidi_> anastasiac we haven't fleshed out the template yet, just thought it would be a good thing to provide
[13:38:32 CDT(-0500)] <anastasiac> ah
[13:38:50 CDT(-0500)] <Justin_o> heidi_: would the template come with some sort of form or something to fill out?
[13:38:55 CDT(-0500)] <anastasiac> heidi_, is it a template for the actual css files? or for the wiki page?
[13:38:56 CDT(-0500)] <heidi_> not sure what all should be in it yet. i imagine a css file, a demo, and maybe a readme explaining how to use it or something?
[13:39:32 CDT(-0500)] <heidi_> for what they should give us and how... i imagine we'd then put it on the wiki. or do we want it to be more open than that?
[13:40:00 CDT(-0500)] <heidi_> Justin_o don't think it has to be a form. just like a "hello world" example of a contribution
[13:40:23 CDT(-0500)] <heidi_> but maybe that over-complicates?
[13:40:26 CDT(-0500)] <heidi_> not sure
[13:40:42 CDT(-0500)] <Justin_o> heidi_: if that's the case i wonder if the ones that are there now would serve as that example
[13:41:22 CDT(-0500)] <heidi_> basically so far the contributions we've received have a lot of extra styles and don't really align with fss much. so need a way to curb/direct a contribution to be more consistent with others, and with fss?
[13:42:02 CDT(-0500)] <heidi_> Justin_o i think the contribs so far still need cleaning/organising, no?
[13:42:15 CDT(-0500)] <Justin_o> heidi_: that's a good point.. we may want to talk about what we expect the contributions to look like
[13:42:24 CDT(-0500)] <Justin_o> and standards they should uphold and etc.
[13:43:08 CDT(-0500)] <Justin_o> heidi_: you're right the ones we have now could use some tightening up
[13:43:22 CDT(-0500)] <heidi_> Justin_o does a stripped down stylesheet with only pertinent css, a demo, and a readme sound ok? maybe not even a readme
[13:43:46 CDT(-0500)] <heidi_> do we want css in the fl- namespacE?
[13:44:20 CDT(-0500)] <heidi_> are there other contributions besides fss we will want to eventually include?
[13:44:51 CDT(-0500)] <Justin_o> heidi_: i think the css, demo, and readme would be good.. although the readme may not be necessary
[13:45:02 CDT(-0500)] <Justin_o> i'm not sure about the namespace.. anyone else have thoughts
[13:45:23 CDT(-0500)] <heidi_> i imagine somday there will be both an fss-contrib space and fluid plugin-gallery - not sure how consistent those two should be, if we need to look that far ahead now
[13:45:31 CDT(-0500)] <Justin_o> heidi_: as for other contributions we will eventually be expecting code contributions too i think
[13:45:39 CDT(-0500)] <colinclark> I think that's right
[13:45:52 CDT(-0500)] <colinclark> in the long run, we'll want to think about this as a general place for contributions to Infusion
[13:46:02 CDT(-0500)] <colinclark> be it FSS stuff or new components or anything else
[13:46:08 CDT(-0500)] <colinclark> we can always start simple now, though
[13:46:43 CDT(-0500)] <Justin_o> colinclark: do you know if we need licenses for the css?
[13:46:54 CDT(-0500)] <colinclark> Yes
[13:46:59 CDT(-0500)] <Justin_o> also should we require a specific type of license
[13:47:03 CDT(-0500)] <heidi_> Justin_o i think for css contributions, we'd want it so that another user could grab the contrib's .css file, drop it into their page, and use it. so a nice clean concise, commented css file
[13:47:04 CDT(-0500)] <colinclark> We should ensure that the contribution signs a CLA
[13:47:11 CDT(-0500)] <colinclark> and that their contributions are compatible with Infusion
[13:47:17 CDT(-0500)] <colinclark> doesn't have to be the same license as ours
[13:47:30 CDT(-0500)] <colinclark> but we wouldn't want someone else to get in trouble by combining two incompatible licenses
[13:47:31 CDT(-0500)] <Justin_o> heidi_: i agree... that makes sense
[13:47:43 CDT(-0500)] <colinclark> luckily, the combination of ECL and BSD make us pretty broadly compatible
[13:48:02 CDT(-0500)] <Justin_o> colinclark: if they sign a cla would that give us the copyright?
[13:48:06 CDT(-0500)] <heidi_> so someone would have to be emailed a CLA form, sign it, fax/scan it?
[13:48:08 CDT(-0500)] <colinclark> Nope
[13:48:26 CDT(-0500)] <colinclark> Our CLA doesn't ask people to give us copyright
[13:48:55 CDT(-0500)] <colinclark> It's just asserts that they own the thing that they are contributing, and that they agree to share it with others based on a compatible license
[13:48:59 CDT(-0500)] <colinclark> heidi_: Or email
[13:49:11 CDT(-0500)] <colinclark> The CLAs are available on the Web
[13:49:15 CDT(-0500)] <heidi_> ah cool
[13:49:23 CDT(-0500)] <colinclark> Are you thinking that's too onerous for a contributor?
[13:50:13 CDT(-0500)] <heidi_> yeah, even tho it's not
[13:50:14 CDT(-0500)] <Justin_o> colinclark: i think that's fine, but we may need an easier way to track who has signed it and etc.
[13:50:14 CDT(-0500)] <heidi_> ha
[13:50:30 CDT(-0500)] <heidi_> sounds like there's no way around it tho
[13:52:26 CDT(-0500)] <Justin_o> anyone have any thoughts about the namespace
[13:52:27 CDT(-0500)] <colinclark> I guess we could consider some kind of click-through license
[13:52:32 CDT(-0500)] <colinclark> we'd have to talk to a lawyer about it
[13:52:44 CDT(-0500)] <colinclark> pretty much every well-organized open source project I've seen has these CLAs
[13:53:22 CDT(-0500)] <Justin_o> colinclark: i guess it could be part of the submission package, that they will have to send in with there contribution
[13:53:28 CDT(-0500)] <colinclark> yeah
[13:53:29 CDT(-0500)] <Justin_o> so they could send us a zip with everything maybe
[13:53:40 CDT(-0500)] <colinclark> Other communities do make a distinction between core contributions and third-party stuff
[13:54:03 CDT(-0500)] <heidi_> Justin_o i like that idea
[13:56:06 CDT(-0500)] <colinclark> So, I guess we don't necessarily have to have people CLAs and the like
[13:56:30 CDT(-0500)] <colinclark> but if we do eventually want to integrate this into the Builder, then it might start to cause confusion for users
[13:56:42 CDT(-0500)] <colinclark> if these contributions aren't "vetted" in some way
[13:56:58 CDT(-0500)] <colinclark> I guess we should think about how we can avoid the jQuery problem
[13:58:06 CDT(-0500)] <colinclark> "The jQuery Problem" being the fact that their plugin community seems really amazing at first glance
[13:58:19 CDT(-0500)] <Justin_o> colinclark: i wouldn't mind setting some standards around the quality of the submission
[13:58:32 CDT(-0500)] <colinclark> I think we'll have to do that in a nice way
[13:58:40 CDT(-0500)] <colinclark> in other words, be really open about our submission standards
[13:58:45 CDT(-0500)] <colinclark> sort of like the reverse of Apple
[13:58:51 CDT(-0500)] <Justin_o>
[13:59:04 CDT(-0500)] <colinclark> Where you just know that there are some underpaid dudes in the basement in Cupertino randomly deciding whether or not your stuff gets in
[14:00:08 CDT(-0500)] <Justin_o> colinclark: i think if we outline what we are expecting then it should be okay... i guess as part of that template that heidi was mentioning
[14:01:13 CDT(-0500)] <heidi_> Justin_o i like the idea of including the CLA in the contrib pkg/template thing
[14:01:15 CDT(-0500)] <colinclark> right, that's a great idea, heidi_
[14:01:55 CDT(-0500)] <heidi_> Justin_o don't think the fl- namespace is necessary
[14:02:20 CDT(-0500)] <heidi_> as we've also learned, it's actually really tricky to name stuff with the fss naming layout
[14:02:23 CDT(-0500)] <Bosmon> yay for underpaid dudes in basements
[14:02:47 CDT(-0500)] <Justin_o> heidi_: i think that's correct.. we may want to discourage the use of the fl- namespace to avoid conflicts
[14:03:15 CDT(-0500)] <heidi_> and tell users of contrib files that conflicts could happen
[14:03:28 CDT(-0500)] <heidi_> not with fss, but custom styles
[14:03:51 CDT(-0500)] <Justin_o> heidi_: yes.. i guess that should be a warning.. although they should all be namespaced too.. so hopefully conflicts will be rare
[14:05:05 CDT(-0500)] <heidi_> Justin_o our template should also make it clear that demo-css shouldn't be in the contrib css, know what i mean?
[14:06:08 CDT(-0500)] <Justin_o> you mean css that is specific to the demo but not necessarily part of what they are contributing?
[14:06:36 CDT(-0500)] <heidi_> right
[14:07:11 CDT(-0500)] <heidi_> also i liked your thought to include a list of dependencies. if they're using fss-reset etc
[14:08:59 CDT(-0500)] <colinclark> heidi_: I've just been catching up on the logs, but your idea of a kind of "hello world" example showing the template or structure for how submissions should be organized is really smart
[14:09:03 CDT(-0500)] <colinclark> huge +1 from me
[14:09:13 CDT(-0500)] <heidi_> cool
[14:09:25 CDT(-0500)] <colinclark> and another huge +1 for encouraging users to use their own namespace
[14:09:47 CDT(-0500)] <colinclark> otherwise, fl- will just become the defacto global namespace and we'll be back to all the same problems
[14:09:51 CDT(-0500)] <colinclark> "Hey, you stole my name!"
[14:09:52 CDT(-0500)] <colinclark>
[14:09:59 CDT(-0500)] <heidi_> haha yeah. fl-fight
[14:10:35 CDT(-0500)] <colinclark> Is there any point in thinking about submissions from the perspective of a Git workflow?
[14:10:40 CDT(-0500)] <colinclark> Is that maybe asking too much from users?
[14:10:51 CDT(-0500)] <colinclark> I was thinking they could submit a repository for us to fork or something?
[14:11:56 CDT(-0500)] <Justin_o> colinclark: i think that could be a way, but maybe it shouldn't be the only way
[14:12:11 CDT(-0500)] <Justin_o> although it would encourage continued development
[14:13:20 CDT(-0500)] <heidi_> be good to have that choice i think
[14:13:31 CDT(-0500)] <colinclark> ok, i'm into that
[14:14:42 CDT(-0500)] <heidi_> Justin_o anything else about contrib space need clarifying?
[14:15:13 CDT(-0500)] <heidi_> i think the wiki page you've got is a good start... and yeah i think once formatted contributions come in, we'll have more content for it
[14:15:34 CDT(-0500)] <heidi_> demo/descriptions/tec
[14:15:35 CDT(-0500)] <heidi_> etc
[14:15:44 CDT(-0500)] <Justin_o> heidi_: yep.. we'll have to get the ones we have there fixed up a bit
[14:15:51 CDT(-0500)] <heidi_> ya
[14:16:04 CDT(-0500)] <heidi_> and create the fakey contrib
[14:16:13 CDT(-0500)] <Justin_o> at the moment that's all i can think of for the contrib space stuff
[14:16:21 CDT(-0500)] <Justin_o> heidi_: yes.. did you want to start that?
[14:16:44 CDT(-0500)] <heidi_> Justin_o if you have time, can you? am kinda swamped feeling with UIO styling
[14:16:56 CDT(-0500)] <Justin_o> heidi_: sure.. i had a feeling you would say that
[14:17:01 CDT(-0500)] <heidi_> thanks
[14:17:09 CDT(-0500)] <Justin_o> okay.. i think i'm done
[14:17:49 CDT(-0500)] <Justin_o> Bosmon: did you have naming stuff you wanted to talk about
[14:19:53 CDT(-0500)] <Bosmon> I mentioned some points in my mail of last night
[14:20:32 CDT(-0500)] <Bosmon> mostly relating to grades for RendererComponents
[14:21:44 CDT(-0500)] <Justin_o> Bosmon: what is the difference currently between IoCRendererComponent and rendererComponent
[14:22:33 CDT(-0500)] <Bosmon> The difference is that IoCRendererComponent, if it discovers any "fluid decorators" in the tree is it rendering, will automatically upgrade them to IoC-aware subcomponents of the parent component
[14:22:47 CDT(-0500)] <Bosmon> Whereas rendererComponent does what it always did, it just makes a call to invokeGlobalFunction
[14:23:27 CDT(-0500)] <Bosmon> I thought it had been nice for "backwards compatibility" to keep rendererComponent doing what it always did, but cindy and michelle's experience from yesterday evening shows that this old behaviour can often just be hazardous in the new world
[14:23:55 CDT(-0500)] <Bosmon> I can't actually think of a good argument why anyone would really want the old behaviour, so I am thinking of just renaming what is currently IoCRendererComponent to plain rendererComponent
[14:24:21 CDT(-0500)] <Bosmon> And then perhaps keeping the old behaviour around perhaps just driven by options
[14:24:27 CDT(-0500)] <Bosmon> I'm not even sure we need a grade for it at all
[14:24:46 CDT(-0500)] <Bosmon> THEN there is the issue of the so-called "antigenicRendererComponent"
[14:24:50 CDT(-0500)] <Bosmon> Which really DOES need a grade
[14:25:08 CDT(-0500)] <Bosmon> Now, this one applies to the component which IS the decorator's component, not the parent component
[14:27:33 CDT(-0500)] <Justin_o> Bosmon: antigenic components are those that can be initialized without their container, which can be supplied at some later point?
[14:27:41 CDT(-0500)] <Bosmon> That's right
[14:28:40 CDT(-0500)] <Bosmon> It is a silly name that was conceived in a tower in Boulder 18 months ago, which has still not been replaced
[14:30:06 CDT(-0500)] <Justin_o> Bosmon: will there be antigenic versions for all of the component grades that expected containers? and if so can this just be added as an additional grade?
[14:31:23 CDT(-0500)] <Bosmon> Well, it's a good question...
[14:31:33 CDT(-0500)] <Bosmon> I guess the "grade graph" will become a bit "lattice-like"
[14:31:57 CDT(-0500)] <Bosmon> I'm not sure it makes sense for something to be "antigenic" that doesn't also "render" somehow
[14:32:07 CDT(-0500)] <Bosmon> But the plan was to allow things to "render" that didn't necessarily use the renderer
[14:32:48 CDT(-0500)] <colinclark> Bosmon: I'm just catching up...
[14:33:00 CDT(-0500)] <Bosmon> That is, to formalise these various "micro-components" we have that have a property named something like "markupString" or whatever
[14:33:01 CDT(-0500)] <colinclark> In terms of rendererComponent vs. IoCRendererComponent, I think you're right...
[14:33:13 CDT(-0500)] <colinclark> Make IoCRendererComponent into rendererComponent, and then expose that old behaviour via an option
[14:33:20 CDT(-0500)] <Bosmon> colinclark - thanks
[14:33:25 CDT(-0500)] <colinclark> Then my world goes back to the way it was last week...
[14:33:34 CDT(-0500)] <colinclark> in that there is only one type of rendererComponent
[14:33:43 CDT(-0500)] <Bosmon> You mean, when you had never even heard there was a thing called "IoCRendererComponent"?
[14:33:44 CDT(-0500)] <Bosmon> right
[14:33:53 CDT(-0500)] <Bosmon> Then we complexify the world AGAIN
[14:33:54 CDT(-0500)] <colinclark> New Inventions
[14:34:11 CDT(-0500)] <Bosmon> As fast as one Invention is destroyed, a new one rises to take it's place
[14:34:20 CDT(-0500)] <colinclark> Is a rendererComponent the only place where antigenic characteristics are meaningful?
[14:34:22 CDT(-0500)] <Bosmon> Did you ever see the picture, "The Temptation of St. Anthony"?
[14:34:25 CDT(-0500)] <colinclark> I'm not sure that question quite made sense
[14:34:26 CDT(-0500)] <Bosmon> colinclark - no, it isn't
[14:34:29 CDT(-0500)] <colinclark> ok
[14:34:34 CDT(-0500)] <colinclark> tell me more about that, then
[14:34:53 CDT(-0500)] <Bosmon> We had been talking (in my mail, and just now) about the "grandfathering in" of these "micro-components" that just render markup using literal strings
[14:34:56 CDT(-0500)] <colinclark> ah, I see Justin_o already asked this question
[14:35:04 CDT(-0500)] <colinclark> I'm sorry for being so out of it
[14:35:26 CDT(-0500)] <Bosmon> Even if these don't have any conception of the renderer themselves, they may STILL productively cooperate with an overall rendering pass that IS using the renderer
[14:35:37 CDT(-0500)] <colinclark> I think that makes a lot of sense
[14:35:55 CDT(-0500)] <Bosmon> As I mentioned in my mail, in the "wider rendering pass" these would be converted into fictitious UIVerbatim components in the wider tree
[14:36:01 CDT(-0500)] <colinclark> right
[14:36:04 CDT(-0500)] <Bosmon> This is the innovation that would avoid "twinkle" in places like CSpace
[14:36:17 CDT(-0500)] <Bosmon> Right now this "twinkling" consumes a fair amount of CPU time I think
[14:36:26 CDT(-0500)] <colinclark> interesting
[14:37:01 CDT(-0500)] <Bosmon> Since even though we render a HUGE BULK of markup using the renderer, we then "twinkle" all the way through it, creating dozens of little things like inlineEdits, autocompletes, and number patterns
[14:37:14 CDT(-0500)] <Bosmon> Each of these incurs the full DOM locking overhead each time...
[14:37:54 CDT(-0500)] <colinclark> So, can you remind us again of the key phases of an "antigenic" component?
[14:38:10 CDT(-0500)] <Bosmon> So I am imagining that "antigenic component" would be a direct descendent (or perhaps even a sibling) of viewComponent
[14:38:22 CDT(-0500)] <Bosmon> Although I think it needs to be a descendent, since it overrides key aspects of viewComponent
[14:38:39 CDT(-0500)] <Bosmon> So, when an antigenc component is constructed, it initially takes NO container
[14:38:47 CDT(-0500)] <Bosmon> Despite having all the other aspects and configuration of a view component
[14:38:59 CDT(-0500)] <Bosmon> I guess we would formalise this by making the container not even appear in its signature
[14:39:28 CDT(-0500)] <Bosmon> Now we have "argumentMap" configured by the grade, this is actually thinkable, although I guess it might still trip people up who are making the component without IoC
[14:39:57 CDT(-0500)] <Bosmon> Ah... wait
[14:40:13 CDT(-0500)] <Bosmon> I guess we need to be clear that an antigenic component is only POTENTIALLY antigenic
[14:40:30 CDT(-0500)] <Bosmon> So, for example, the inlineEdit component - MIGHT be invoked with a container... and might not
[14:40:43 CDT(-0500)] <Bosmon> Ok, so the signature needs to stay fixed
[14:40:56 CDT(-0500)] <colinclark> Meaning antigenic-ness is a contextual thing
[14:41:00 CDT(-0500)] <Bosmon> Yes
[14:41:20 CDT(-0500)] <Bosmon> The component still needs to be capable of exposing a "one-step" workflow for people who just want to construct one immediately
[14:41:55 CDT(-0500)] <colinclark> Okay, that's really interesting
[14:42:31 CDT(-0500)] <Bosmon> Perhaps we will have a special fluid.NO_CONTAINER argument that is fabricated by the renderer
[14:42:40 CDT(-0500)] <colinclark> ... was just going to say
[14:42:46 CDT(-0500)] <colinclark> some kind of "placeholder container"
[14:42:50 CDT(-0500)] <Bosmon> To distinguish the case where there is no container now, but there will be one later, from the case where there is not one, and never will be one
[14:43:15 CDT(-0500)] <Bosmon> fluid.DEFERRED_CONTAINER perhaps
[14:43:58 CDT(-0500)] <colinclark> Is there really a case where there will never be a container?
[14:44:10 CDT(-0500)] <Bosmon> Well
[14:44:17 CDT(-0500)] <Bosmon> We designed in that there would be one
[14:44:22 CDT(-0500)] <Bosmon> I can't say I ever heard of anyone using it
[14:44:36 CDT(-0500)] <Bosmon> But that's not necessarily "evidence"
[14:44:57 CDT(-0500)] <Bosmon> It was probably one of those things we thought were a "cool idea" round about the Fluid 0.6 timeframe
[14:46:11 CDT(-0500)] <colinclark> wait
[14:46:20 CDT(-0500)] <colinclark> I don't really have any memory of this
[14:46:28 CDT(-0500)] <colinclark> A View will freak if it gets no container, no?
[14:46:32 CDT(-0500)] <Bosmon> no
[14:46:36 CDT(-0500)] <Bosmon> It will return null
[14:46:40 CDT(-0500)] <Bosmon> it is OTHER things that might freak
[14:46:45 CDT(-0500)] <Bosmon> If they were expecting to be given a component
[14:46:52 CDT(-0500)] <colinclark> Ah
[14:46:59 CDT(-0500)] <colinclark> I think actually we added that feature for some reason
[14:47:04 CDT(-0500)] <colinclark> though the reason is lost on me
[14:47:05 CDT(-0500)] <Bosmon> Dimly, yes
[14:47:16 CDT(-0500)] <Bosmon> It might have been to do with allowing the pager's configuration to be markup-driven
[14:47:18 CDT(-0500)] <colinclark> when we first wrote fluid.container(), it would just explode on sight of a falsey container
[14:47:21 CDT(-0500)] <colinclark> interesting
[14:47:30 CDT(-0500)] <Bosmon> For example, it has the capability of having several pager bar components
[14:47:42 CDT(-0500)] <Bosmon> But if the markup doesn't match for one or more of them, they will just "go away"
[14:47:59 CDT(-0500)] <Bosmon> I guess it is one of these epicyclic "white elephant features" a bit like "reverse options merging" in the Reorderer
[14:48:28 CDT(-0500)] <Bosmon> At the time, the renderer and IoC system were too immature to achieve effects like these through other means
[14:48:37 CDT(-0500)] <Bosmon> All the same, the behaviour has been in our contract for maybe 2 years now
[14:49:02 CDT(-0500)] <colinclark> hopefully it's something we can eventually deprecate
[14:49:12 CDT(-0500)] <colinclark> ok, so keep going
[14:49:43 CDT(-0500)] <Bosmon> So yes, we have established that "antigenicness" carries no change in signature
[14:49:55 CDT(-0500)] <Bosmon> One of these components either may, or may not, accept a container on startup
[14:50:21 CDT(-0500)] <Bosmon> If it gets no container, it exists in a kind of "skeleton mode"... in "Lifecycle phase 1"
[14:50:28 CDT(-0500)] <Bosmon> It has no markup, its events are not bound to anything, etc.
[14:50:56 CDT(-0500)] <Bosmon> It can respond to up to 3 things - a request for "produceTree", "produceMarkup" or "templateResources"
[14:51:16 CDT(-0500)] <Bosmon> At some later time, it will receive a call to a method, perhaps named "bindContainer"
[14:51:28 CDT(-0500)] <colinclark> So basically, we're starting to take the responsibility away from View components to manage their own lifecycle
[14:51:41 CDT(-0500)] <colinclark> and in Skeleton Mode, they're simply asked by the framework for information about what they want to render
[14:51:42 CDT(-0500)] <Bosmon> Yes, we always like to take responsibility away from things
[14:51:47 CDT(-0500)] <colinclark>
[14:53:01 CDT(-0500)] <Bosmon> So I guess I saw "3 lifecycle phases" here but in some histories, it is really only two
[14:53:24 CDT(-0500)] <Bosmon> So, an "old-style" renderer component could be said to start in "lifecycle phase 2" - it has a container, but has not PUT anything into it
[14:53:36 CDT(-0500)] <colinclark> So, to reiterate, in Phase 1, the framework asks an antigenic component to "give me your markup," or more commonly, "give me your tree and templates, and I'll render you"
[14:53:44 CDT(-0500)] <Bosmon> At some later phase, it receives "refreshView" and goes on to phase 3 where it is fully constructed and ready to go
[14:53:49 CDT(-0500)] <colinclark> right
[14:54:05 CDT(-0500)] <Bosmon> Whereas one of these antigenic renderer components passes from this new phase 1, directly to phase 3, when it receives "bindContainer"
[14:54:14 CDT(-0500)] <Bosmon> Since it assumes that its markup has fully arrived
[14:54:54 CDT(-0500)] <colinclark> So, in phase 3, a component has the chance to do things with a live DOM...
[14:55:01 CDT(-0500)] <Bosmon> I mean, I see no reason for "bindContainer" to not immediately perform the "back half" of the workflow of "refreshView"
[14:55:03 CDT(-0500)] <colinclark> like bind event handlers, were they not specified as decorators, etc.
[14:55:17 CDT(-0500)] <colinclark> The back half being...?
[14:55:23 CDT(-0500)] <Bosmon> The bit doing "bindEvents"
[14:55:37 CDT(-0500)] <colinclark> ok
[14:55:43 CDT(-0500)] <Bosmon> Really I imagine that it will just all be a listener to "afterRender"
[14:55:59 CDT(-0500)] <Bosmon> And that "bindContainer" will immediately fire an "afterRender" event
[14:56:25 CDT(-0500)] <colinclark> ok
[14:56:35 CDT(-0500)] <colinclark> Phase 1 is "give us your markup"
[14:56:47 CDT(-0500)] <colinclark> Phase 3 is "here's your live DOM"
[14:56:52 CDT(-0500)] <colinclark> Phase 2 was what, again?
[14:57:03 CDT(-0500)] <Bosmon> Phase 2 is "You have a container, but no markup in it yet"
[14:57:13 CDT(-0500)] <Bosmon> Which is only operated by our contemporary renderer components
[14:57:14 CDT(-0500)] <colinclark> Where "give us your markup" is really "give us the stuff we will use to make markup for you"
[14:57:19 CDT(-0500)] <colinclark> ok
[14:57:53 CDT(-0500)] <colinclark> So, to get back to my earlier, poorly-phrased question, it sounds like antigenic-ness is really very View-specific
[14:58:04 CDT(-0500)] <colinclark> in that it defines lifecycle points for rendering a component
[14:58:09 CDT(-0500)] <Bosmon> Right, you mean, rather than "renderer-specific"?
[14:58:30 CDT(-0500)] <Bosmon> Although antigenicness only can be operated in the context of an "overall pass of the renderer"
[14:58:44 CDT(-0500)] <Bosmon> Even if the antigenic component itself is not specifically "renderer-aware"
[15:02:48 CDT(-0500)] <colinclark> yep
[15:02:48 CDT(-0500)] <colinclark> cool
[15:03:30 CDT(-0500)] <colinclark> So, Bosmon, is there anything else you think is noteworthy about antigenic renderer components, in terms of our naming discussion?
[15:04:01 CDT(-0500)] <colinclark> I think it probably will be key to give it a name that conveys its phased-ness
[15:04:02 CDT(-0500)] <Bosmon> I guess we've talked about everything that they do
[15:04:18 CDT(-0500)] <Bosmon> "in themselves" they appear "multi-phase"
[15:04:32 CDT(-0500)] <Bosmon> But this multi-phasedness is there, in order that the global rendering operation can be "uni-phase"
[15:04:37 CDT(-0500)] <colinclark> right
[15:04:44 CDT(-0500)] <colinclark> meaning, some rendering process happens...
[15:04:54 CDT(-0500)] <Bosmon> "all at once"
[15:04:55 CDT(-0500)] <colinclark> gathering up all the instructions for how to render a whole tree of components
[15:05:00 CDT(-0500)] <colinclark> and then it renders once
[15:05:00 CDT(-0500)] <colinclark> right
[15:05:03 CDT(-0500)] <Bosmon> Of course, this is a crucially important capability on the SERVER
[15:05:11 CDT(-0500)] <Bosmon> WHen you really only HAVE one time to render things
[15:05:14 CDT(-0500)] <colinclark> Since there will never be a Live DOM
[15:05:32 CDT(-0500)] <Bosmon> The "GIANT STRING FORM" is the last form you will ever see
[15:06:41 CDT(-0500)] <colinclark> right
[15:06:48 CDT(-0500)] <colinclark> Okay, so I'm probably the worst person to ask about naming
[15:06:55 CDT(-0500)] <colinclark> despite never failing to have an opinion
[15:07:04 CDT(-0500)] <colinclark> But I think we've outlined all the characteristics
[15:08:50 CDT(-0500)] <colinclark> For anyone else still paying attention, now is a good time for ideas and suggestions
[15:08:59 CDT(-0500)] <colinclark> I'm curious if anastasiac has any thoughts
[15:09:24 CDT(-0500)] <anastasiac> I'm musing...
[15:09:42 CDT(-0500)] <anastasiac> if we think of uni-phase as phase-less, then multi-phase would be thought of as phased
[15:09:49 CDT(-0500)] <colinclark> I guess the simplest name would just be something like "phasedRendererComponent" or "multiphaseRendererComponent"
[15:09:51 CDT(-0500)] <colinclark>
[15:09:53 CDT(-0500)] <anastasiac> so maybe "phased" as opposed to "mulfi-phase"
[15:10:11 CDT(-0500)] <anastasiac> definitely -1 for "mulfi" anything
[15:10:22 CDT(-0500)] <Bosmon> I agree
[15:10:38 CDT(-0500)] <Bosmon> Although "phased" still sounds a bit too Star Trek-y for me
[15:10:38 CDT(-0500)] <colinclark> no mulfi
[15:10:50 CDT(-0500)] <anastasiac> "staged"?
[15:11:39 CDT(-0500)] <colinclark> "managedRendererComponent"?
[15:11:52 CDT(-0500)] <Bosmon> managed has horrible smells of .NET
[15:11:58 CDT(-0500)] <colinclark> Something about how rendering is taken care of by the framework?
[15:12:02 CDT(-0500)] <colinclark> yeah
[15:12:05 CDT(-0500)] <Bosmon> "staged" makes me think of cowboys... or else musicals
[15:12:11 CDT(-0500)] <colinclark> lol
[15:12:32 CDT(-0500)] <anastasiac> -1 for managed; everything is managed!
[15:12:37 CDT(-0500)] <Bosmon>
[15:12:51 CDT(-0500)] <Bosmon> Increasingly many things are managed, for sure
[15:13:03 CDT(-0500)] <Bosmon> And how can you have "managed code", in a world where there is no longer any code
[15:13:27 CDT(-0500)] <anastasiac> LOL
[15:16:42 CDT(-0500)] <anastasiac> ok, pulling out the thesaurus, some synonyms: phase, stage, step, level, point, stop, stop
[15:27:15 CDT(-0500)] <heidi_> what are we naming?
[15:27:38 CDT(-0500)] <anastasiac> the antigenic renderer component - "phased" is too star-trekky
[15:27:44 CDT(-0500)] <anastasiac> "staged" seems to theatrical
[15:28:18 CDT(-0500)] <heidi_> antigenic ? woah
[15:28:26 CDT(-0500)] <anastasiac> yeah
[15:47:03 CDT(-0500)] <Bosmon> I mean, "phased" seems the best of the options proposed so far
[15:47:08 CDT(-0500)] <Bosmon> But it still doesn't seem particularly great to me
[15:52:58 CDT(-0500)] <colinclark> I like phased best so far
[15:53:18 CDT(-0500)] <colinclark> call me less of a star trek nerd
[16:00:20 CDT(-0500)] <Bosmon> colinclark: Do you have time to talk about options chewing, or shall we leave it until after Thursday?
[16:00:30 CDT(-0500)] <colinclark> I'd say we're into next week
[16:00:35 CDT(-0500)] <colinclark> We need to talk about it
[16:00:38 CDT(-0500)] <colinclark> or the world will end
[16:00:40 CDT(-0500)] <Bosmon> I will be away then
[16:00:44 CDT(-0500)] <colinclark> oh shoot
[16:00:46 CDT(-0500)] <colinclark> I'm away on Friday
[16:00:47 CDT(-0500)] <Bosmon> Hopefully we can talk about my slides before then
[16:00:50 CDT(-0500)] <colinclark> okay, let's keep our fingers crossed
[16:00:50 CDT(-0500)] <Bosmon> Or else the world will also end
[16:01:03 CDT(-0500)] <colinclark> that this proposal will get done soon
[16:01:15 CDT(-0500)] <colinclark> and let's book a meeting to chat about both things at 2 pm tomorrow
[16:01:16 CDT(-0500)] <colinclark> 2 pm EDT
[16:01:56 CDT(-0500)] <colinclark> seem good, Bosmon?
[16:02:23 CDT(-0500)] <Bosmon> Ok
[16:02:30 CDT(-0500)] <Bosmon> That's cool
[16:02:34 CDT(-0500)] <colinclark> Lemme put it into my calendar now
[16:02:45 CDT(-0500)] <colinclark> Options chewing and Infusion JSConf presentation
[16:02:46 CDT(-0500)] <Bosmon> A *CATT* is rolling over to be tickled
[16:02:56 CDT(-0500)] <colinclark> You should tell the community about the fact that you're giving a Big Presentation
[16:03:09 CDT(-0500)] <Bosmon> TICKEL TICKEL TICKLE *ELKK*!
[16:03:16 CDT(-0500)] <colinclark> erm
[16:03:25 CDT(-0500)] * colinclark sneaks away
[16:03:29 CDT(-0500)] <Bosmon> hahaha
[16:03:41 CDT(-0500)] <Bosmon> The barely audible, shameful words
[16:04:37 CDT(-0500)] <Bosmon> How do we deal with the awkwardness that a "phasedRendererComponent" might not actually be a renderer component?
[16:05:08 CDT(-0500)] <Bosmon> To draw the "inheritance diagram" - there is some "child" of viewComponent, which is the "antigenic rendering" one
[16:05:41 CDT(-0500)] <Bosmon> And then there is a "mixin", perhaps "phasedRendererComponent" which inherits from the standard rendererComponent and this child
[16:05:47 CDT(-0500)] <Bosmon> At least, I think that is the arrangement we want
[16:06:53 CDT(-0500)] <Bosmon> At least, we need some form of "covariant hierarchy"
[16:07:09 CDT(-0500)] <Bosmon> viewComponent, "phasedViewComponent", rendererComponent, phasedRendererComponent
[16:07:15 CDT(-0500)] <Bosmon> Forming a kind of "square"
[16:07:26 CDT(-0500)] <Bosmon> Which on its side, might look like a kind of "diamond"