templating without a templating framework

[Antranig Basman]

I think this is one of a large class of issues that we should
avoid being prescriptive on.

Personally I think in many cases there can be a lot said *against*
requiring anything "reusable" to be dumped in a common place, 
since this again raises all the old workflow issues about who
controls this common place and how jurisdiction and changes
are coordinated. 

We need to plan to be flexible both for "one-man-shops" where
a single mind is in control of all markup and the client, and
larger environments where "many hands are trying to make light
work".

Personally I think "cloneable HTML in or near its destination"
is a perfectly good model and I use it all the time :P

The workflow I imagine is that template rendering is essentially
"earlier" than all other substantial DOM operations, and has
the action of overwriting the "cloneable row" in the table - 
after this point it will no longer cause a hazard to shipping.

The return value from the "template" operation is a "compiled
template" which can be used for further cloning/rendering,
without requiring to make any further reference to the DOM.

This the "rendering" process can be seen as a multi-step one,
where at each step further "fidelity" is incrementally added
to the DOM/markup - the initial "template" is valid for
presentation, but may not be valid for live behaviours.



Here is some further reasoning, with both pros and cons for
"placeholder rows:"
Con (against placeholders):
  Keeps the DOM semantics clear, and avoids mixing infrastructural
with presentation material.
  Increases abstraction, and allows delivery of "meta-components"
which are ready to be repurposed more flexibly.

Pro (for placeholders):
  Fights DOM fascism, in that it provides a clear indication
of the DOM location where new rows are intended to be added.
  Minimises file count, and increases comprehensibility and
previewability of markup by increasing locality of reference
for developers.


I think the reasons on both sides are strong enough that we
need to be able to facilitate both ways of working and 
consider them "first class". A lot depends on the "social"
nature and purpose of the development in progress.

Just to make this discussion even more complex, note that
my workflow above separates the issue of "placeholders"
from the issue of "templates within target container" by
showing that the latter needn't imply the former.

Cheers,
A.



Eli Cochran wrote:
> 
> There are a few reasons that I was thinking of putting the HTML that
> you want to clone somewhere else and wrapped it's own, common, wrapper.
> 
> First the common wrapper...
> 
> I thought that it would be tidy if all Fluid components stuffed their
> templates in the same place.
> As well as being tidy, we would use a common CSS declaration to hide
> the templating code (and show the templating code when designing.)
> 
> The reason that I don't want to put the clone-able row inside the
> table is because it makes the code that parses the table more complex,
> as each parse needs to account for the placeholder row.
> 
> So for example to get the count of rows, instead of just being able to
> say:
> 
>         jQuery('tr',container).length
> 
> I have to say something like:
> 
>         jQuery('tr:not(".placeholder")',container).length
> 
> Not a lot of code, it's just that each time I reference my DOM I have
> to remember that I have this extra stuff inside my structure.
> 
> - Eli
> 
> On May 22, 2008, at 6:24 PM, Colin Clark wrote:
> 
> >> I think I'm sold on putting the  in the HTML. Should we wrap all
> >> our client-side templates in some agreed upon class name?
> >
> >
> > Hmm. Good question. What do you think the benefit of giving them a
> > particular class name is? Why wrap them up in a separate element? Is
> > it a documentation benefit? Or an easy way to hide them all on
> > startup? Something else?
> >
> > At first glance, it seems to me that the best place for this chunk
> > of markup is in context of the table it is a part of. Were you
> > thinking it would be in a separate section of the DOM? A shared
> > class name might be helpful for documentation and styling purposes,
> > though. I may be missing something here, so I'd love to hear more
> > feedback.
>