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 <[email protected]> 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 - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
