templating without a templating framework

[Colin Clark]

Hey Eli,

Great topic to bring to the list. Thanks! Comments inline...

On 20-May-08, at 5:11 PM, Eli Cochran wrote:

> I'm thinking about how I want to handle the lightweight templates  
> that we use in our components. I'm not speaking here about any heavy- 
> weight data-driven templating such as what is being done with sData  
> in Sakai. I think that there is place for that. But this is for the  
> little pieces of DOM that we need to instantiate as we do stuff.

As a quick side note, Antranig has been working on a very interesting  
approach to unobtrusive templating on the client side. It's still  
pretty early, but we hope to have more to share soon.

Back to the point, you're right that this particular use case doesn't  
require a full-blown template renderer. Plain old jQuery will do the  
trick quite nicely.

> Obviously this needs to be pulled out of the main code into  
> something easy to customize and replace.

I totally agree. Code like that can get pretty hairy to maintain or  
customize, especially as more of it appears over time. Reminds me of  
the old servlet days. :)

In some cases there are performance benefits to doing it in code this  
way and using innerHTML to inject rows in bulk. However, given the  
nature of this component and the relatively small number of rows it  
displays, I don't think sacrificing the simplicity of your code for  
speed is necessary.

> But should it be carried around in the DOM or should it be somewhere  
> in the JS code. Both are equally easy to code and maintain.
>
> JS code advantage: Everything is in one place. No extra HTML on the  
> page, and what will be on the page will only be instantiated if  
> needed.
>
> HTML/DOM advantage: Most of the time we need to have HTML on the  
> page anyway. Designers can easily see and manipulate the template.  
> The clone() function. [OK, if you don't know jQuery, that might be  
> lost on you]

I'm in favour of putting markup in the DOM. It's a very natural place  
for it. :)

As you say, having all the presentational aspects of a component in  
one spot makes it really easy for anyone to make modifications to the  
markup without having to crack open the JavaScript code at all.

I imagine you'd have some hidden markup like this in the DOM when the  
component is loaded from the server:

<tr id="fileRow">
   <td class="fileName" scope="row">My file name</td>
   <td class="fileSize">12 Kb</td>
   <td class="fileStatus">Ready to Upload</td>
   <td class="fileRemove"><button type="button" class="removeFileBtn" / 
 ></td>
</tr>

And then in the component code, you'd have some simple, markup- 
agnostic code like this:

var fileRow = jQuery("#fileRow");
var firstFileRow = fileRow.clone();
firstFileRow.attr("id", file.id);
jQuery(".fileName", firstFileRow).text(file.name);
jQuery(".fileSize", firstFileRow).text(file.size);
firstFileRow.show();

Is this roughly what you were thinking, or am I missing a better  
approach?

> 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.

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org