Architecture proposal: Downward-matching CSS-like context selectors ("Luke Skywalker Options") - FLUID-4873

[Antranig Basman]

Hi Justin - thanks for these questions.

On 19/12/2012 06:43, Justin Obara wrote:
> Thanks for putting this up Antranig, and I like the name IoCSS. Currently I have issues with IoC when I need to find some relative component, i.e something that is neither an ancestor, descendant, or direct sibling. Would this new system help for those cases too?

In the end, IoC can't spare you from making design decisions - it can only help to create a structure in 
which to make them :) In the end it's to your benefit to not have every component visible to every other 
one, otherwise you will end up with an exponentially crowded namespace in which searches are slow, 
collisions are frequent and you can't find anything. As I think you found in Decapod, it's not too onerous 
to hoist up "relay" components or events to points of common visibility to get distant components into 
communication, and it helps clarify the design in some cases too. Since this generally doesn't require code, 
we think that it evades the "brittle base" problem that are the natural consequences of this kind of 
"dependency hoisting" using traditional design technologies like OO (referred to in our IoC paper)

That said, from the absolute top of the "IoCSS" tree, you will be able to find EVERYTHING using a suitable 
selector (assuming you can somehow get it there) so that it another possibility for finding faraway components.

> As for the syntax below:
>
> Where does the id come from? Is it the one generated by the framework, or is there a way to set an id on the component?

Yes, it is the framework-generated id. As a stray comment in the JIRA suggests, we expect this kind of 
selector to be only useful when generated by the framework itself, since users aren't able to anticipate 
their own ids.

> Just to clarify, when you say "any" do you mean all, or just one of the set of all possible elements matching the criteria?

Yes, all, just as in the CSS/jQuery model

> Thanks
> Justin
>
> On 2012-12-19, at 4:55 AM, Antranig Basman <Antranig.Basman at colorado.edu> wrote:
>
>> I've drawn up a JIRA summarising the immediate motivations we might have for such a system (our upcoming UIOptions refactoring work), a potential syntax, and some other use cases for it at
>>
>> http://issues.fluidproject.org/browse/FLUID-4873
>>
>> As a "potted summary", the proposal is to support this very tiny subset of the CSS selector syntax (almost the same as that supported within the Fluid Renderer system for "cutpoints") for what we might call "IoCSS" selectors which are capable of making downward assertions about the matching of a component or group of components below a component tree root:
>>
>> * - matches any component - universal selector
>> E - matches any component holding a context name of E - special support for the string "that" as in current IoC context matching
>> E#myid - matches any component with a context name of E with id equal to myid
>>
>> And the following two descendent rules:
>>
>> E F - Matches any F element that is a descendant of an E element.
>> E > F - Matches any F element that is a direct child of an E element
>>
>>
>> Please supply comments, suggestions, questions, and improvements - if we have some time at today's community meeting we could also discuss this a bit -
>>
>> Cheers,
>>
>> A
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>