Infusion Concepts and Help Topics: Review, please?

[Clark, Colin]

Hi Anastasia,

A few quick comments:

 * When Antranig talks about "transparent state programming," he's referring to our philosophy of not hiding away the essential model and state information for an application behind accessor methods or custom APIs. In contrast to the overzealous interpretation encapsulation that most object-oriented programmers employ today, Infusion takes a different approach--models are visible to the outside world, unmediated by function calls or particular inheritance hierarchies. Plain old JavaScript objects, which are a perfect match for JSON-based transport, as Antranig articulated earlier.

In Infusion, the model is the most important part of the architecture. Interestingly, it's typically the thing that's most important for interoperability--models typically get passed around between client and server, saved to databases or sent to Web services, and they're also the thing an implementer needs access to most when they're extending or adapting an existing design.

* I think there are probably two concept clouds missing: Inversion of Control as a concept (in addition to its concrete manifestation in our framework), and Events. Developers of Infusion typically assemble their applications declaratively through a combination of configuration options, events, and IoC, removing much of the code that is typically tossed into the Controller layer of traditional MVC architectures.

* I guess that also argues for the need to cover our idea of application architecture as lacking the "C" part of the MVC triad. "Not MVC"--we'll need a better name.

* I wonder about the connection between the box you have in grey called "Views" and the other box you've got connected to it called "view components." I guess they're really the same thing, and that everything coming out of the "Components" box represents the variety of component types we have in the framework today?

Hope this helps,

Colin


On 2011-01-31, at 4:15 PM, Antranig Basman wrote:

> 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 - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
http://inclusivedesign.ca