thoughts on rendering multiple presentations from same content?
colinbdclark at gmail.com
Wed Aug 19 23:20:49 UTC 2009
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
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-->
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
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,
Technical Lead, Fluid Project
More information about the fluid-work