templating without a templating framework

[Eli Cochran]

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.

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley