thoughts on rendering multiple presentations from same content?

[Colin Clark]

Clayton,

This document is awesome. I'm still chewing on your ideas, but some  
preliminary thoughts in the meantime.

Cutpoints in the Renderer:

Yes, a better name is definitely needed. Antranig and I are working on  
some major improvements to the Renderer's interface, including the  
removal of colons to denote multiplicity and the unification of  
cutpoints with the DOM Binder. This naming issue is something we can  
address as part of that effort.

(Background reading for those who don't know the Renderer or Infusion  
well yet:
http://wiki.fluidproject.org/display/fluid/Renderer+Component+Trees#RendererComponentTrees-IDs
http://wiki.fluidproject.org/display/fluid/DOM+Binder)

Component trees and data:

It's pretty common for a component tree to consist of bindings into  
the model rather than the actual data. Bindings--EL paths-- are just  
path-based references pointing within a separate data model. So you  
can think of the architecture of a component as having three separate  
elements, each mediated by some kind of string-based indirection.  
Here's a dorky ASCII diagram that hopefully illustrates what I mean:

(Data Model)  <--EL paths--  (Component Tree)  --selector names-->  
(HTML template)

Roles and workflow:

In many cases, I expect that the boundary between the roles you've  
outlined will be very blurry, and in fact a single "swiss army knife"- 
type person will play several or all of these roles. Jason Eppink and  
Hugues Boily are great examples of these types of interdisciplinary  
Web designer/developer/content people at our partner museums. They  
create interactive content, manage the CMS, do some programming, and  
more.

Given this, I think the workflow often has a natural back-and-forth,  
either performed by a single person or a small team. In practice, this  
is how I've seen most Web development work, including the evolution of  
our own components. You talk to a designer, create a bit of markup,  
write a bit of code, bind them together, and iterate.

Antranig often likes to think about this separation of roles when he  
talks about use of the Renderer, but I think these roles are more of  
metaphorical value when thinking about architectural dependencies,  
rather than illustrative of an actual division of labour.

On 18-Aug-09, at 10:45 PM, Clayton H Lewis wrote:
> comments needed, for example, any point in developing the mashup  
> component idea that is described there?


Yes, I'm pretty intrigued by both of your Shared Template scenarios.

The idea of having a single, plain HTML version with some lightweight  
way of tagging regions of importance strikes me as appealingly direct  
and simple. I'm not convinced it would scale well to complex  
variations between desired behaviour on mobile vs. desktop, though.  
I'm thinking, say, of sprinkling on some extra semantic class names;  
simple and straightforward for some use cases.

The mashup component idea is really interesting. If I understand it  
correctly, you're thinking of a component that can branch and slice to  
produce the page. In other words, a component that,will assemble a  
different output document by slicing off some subcomponents, branching  
to different sub-templates, etc, based on the target device (or  
preference). It certainly seems doable within our existing  
infrastructure, if in a fuzzy way to me at this point.

I'll need to think a little bit about how this also relates to our  
ideas for framework-wide progressive enhancement, including the  
ability to control the process via user preferences.

I'd certainly be willing to pursue this idea further with you. The  
more I talk with museums, the clearer it becomes that one of the  
highest costs to working with something like Engage will be in the  
actual content creation. I think we're going to want to pursue  
possibilities that will make it easier for museums to rework and  
repurpose content for different medium while still delivering great,  
designed experiences.

Exciting stuff,

Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org