Hi Anastasia - nice maps :)
Here are some comments -
There is in general insufficient linkage to what you could call "transparent state programming" or what is
leballed "model-directed programming". In general EVERYTHING on the left hand side of your diagram is an
example of this in some way or other and perhaps this should be made clearer by having a general overall box
or region rather than just a lump at the top left with arrows.
Although IoC *uses* Resolvers in its implementation I'm not sure that is very important for our users -
whereas the fact that it operates EL references which refer to transparent state is. Similarly, component
trees for the renderer make EL references in just the same way.
The extra concept introduced by IoC into this mix is the concept of a "context" which should be represented
in this diagram somehow. That iso, to be specific, the difference between EL references which can appear in
a component tree and those which appear in an IoC tree are that IoC EL references use a context appearing in
{} as a base.
I'm not sure what a "Helper" is - it sounds like a somewhat dangerous concept to me (from previous
experience in Saka) :P
A "concept" which is gradually solidifying in my mind is the forms of "JSON dialect" which we support.
Increasingly, I think, you can see our use of JSON as a form of "grammar" applied to a DSL (Domain-specific
language) - the difference is that this "language" is "pre-parsed" - that is, its syntax tree is directly
embodied in the JSON rather than requiring to be parsed out of a stream of flat text or tokens. In terms of
the dialects that we recognise, we have i) IoC trees (with the subsets of component options and demands
blocks), ii) renderer trees, and to a certain extent iii) merge policies, iv) Colin's upcoming "model
transformation documents".
The Renderer also needs a link to Markup Agnosticism.
On 31/01/2011 13:53, Cheetham, Anastasia wrote:
On 2011-01-31, at 1:40 PM, James William Yoon wrote:
Under the concepts mindmap, would it be possible to highlight the concepts that
are most crucial (or start toward a draft of it)? I imagine, for instance, that
while 'framework' and 'helpers' both reside on the same level, 'framework' has
more weight/importance.
James, excellent question! And in trying to do as you ask, I've realized I need
a new mind map :-)
I've posted a new diagram to
http://wiki.fluidproject.org/display/fluid/Documentation+Redesign+Mind+Maps
identifying features or services offered by the framework (concrete things actually
present in the code), and how they relate to concepts or principles (ideas we espouse).
I've tried to indicate what I view as "core" features, but I would *really*
like more input on this.
Colin? Antranig?
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
