views:

320

answers:

1

I'm using jQueryUI and jQuery-tmpl, but I believe the advice I'm looking for is broad enough it'd apply to any sort of templating library.

The problem I have is that I'll often have some sort of CRUD widget in my template

<script id="some-widget-template">
<div class="some-widget">
 <input name="NameField"/>
 <button id="some-widget-save">Save</button>
</div>
</script>

That leaves me with a very readable widget I can go back and edit, etc. Except that it is ugly. Using jQueryUI I can make the button very pretty, but it requires some Javascript. So in my corresponding Javascript controller, my code will look like this:

$("#some-widget-template")
        .render( arrayOfDataObjects )
        .appendTo("body");
$("#some-widget-save").button();

For that very simple example, this works fine. My controller, however, will quickly become cluttered the more elements that need transforming. It also feels like this should be the concern of the view / templating engine, not to mention having magic strings ("#some-widget-save") that degrade the maintainability of the code.

What's the best way to go about this? Surely I can't be the first person to run into this problem. I've hacked together jquery-tmpl so that before returning a jQuery object, it'll scan for a button element, and if it encounters it, to transform it to a proper button element. This seems slow, as it'll have to traverse each element in the template. Any ideas?

Edit: I found that when using CSS3, 90% of my problems were eliminated. When building for non-CSS3 compliant browsers, I make use of the factory method.

+3  A: 

Disclaimer: the first time I've heard of jQuery-tmpl is while reading your question.

Based on my understanding of your problem, I would try to structure my widget instantiation such that the changes are set to happen automatically and broadly for all elements on any given page that match certain parameters.

You could include a UI initialization function in your framework that, when called, looks at all the elements of the DOM that you tell it to, and then turns them into jQuery UI widgets. The flow would go something like..

  1. jQuery-tmpl goes through and converts all your data into the appropriate templated output.
  2. After jQuery-tmpl has run its course, a call to your instantiation method - let's say "renderUI()" - is made.

jQuery-tmpl would spit out a series of structured elements based on your data...

<div class="some-widget">
    <input name="NameField"/>
    <button class="reset-button">reset</button>
    <button class="save-button">Save</button>
</div>

<div class="tabbed-widget">
    <ul>
        <li>one</li>
        <li>two</li>
        <li>three</li>
    </ul>
</div>

The instantiation method could look something like...

function renderUI() {

    $('.some-widget > .save-button').button({/* options */});
    $('.tabbed-widget > ul').tabs({/* options */});
    /* ... continue any other types of widget instantiation ... */
}

If you are instantiating UI elements selected by class, rather than ID, you can put as many of them as you want into the document, and they'll all get instantiated "at once," since jQuery will select all of them and apply the UI Widget constructor to them.

If you need to run some pre-processing code (such as jQuery-tmpl) before those widgets get instantiated, you can encapsulate your initialization of widgets and call it once all the jQuery-tmpl processing is out of the way.

Anyway, I hope this helps!

P.S. Maybe this is something related to jQuery-tmpl (although I can't fathom what), but it appears that your widget is composed of DOM elements within a script tag. Something about that seems extremely irregular to me ;P

cdata
Thanks for your detailed response. This is the route I went initially, the drawback is that not all my templates are rendered on initialization of the widget. Different events will trigger additional templates after first initialization. I guess what would be best would be a jQuery live like functionality, though I don't know how that would be accomplished.
chum of chance
Ah, I understand. One alternative solution I can imagine is to actually create an event-dispatching (or, perhaps alternatively, callback-enabled) factory that handles creating the template elements from your raw data. You can pass the data to a method on the factory (i.e. factory.buildTemplate('data')), and the factory could respond with a callback or event triggering a function that would automatically apply a UI widget based on attributes and properties of the DOM node passed to it. Let me know if this sounds reasonable to you, and I'll write some psuedo-code =]
cdata
Oops it looks like you only got half the bounty. Sorry about that, this was my first bounty ... I thought all I had to do was mark the best answer.
chum of chance
No worries - just glad to be helpful!
cdata