Implemented templating hooks

[alcinnz]

This commit adds extra properties to $$.fn.view which acts as hooks to integrate a templating service, as shown in tests/template.html. It is fully tested.

[alcinnz]

May I suggest that selectors in view.format gets documented? I've played with detecting jqXHR and jQuery.fn objects, but I have not found an easy way.

Well the templates are what I needed to be added to Agility.js for my interface design.

[arturadib]

Great, thanks for the contribution. I'm still thinking what's the best way to go about external HTML and templates. Also, I'll be incommunicado for the next 10 days or so, so I might not get back on this topic for a while.

I just wanted to jot down some thoughts I've had so far.

First, it'd be nice to be able to specify a jQuery element in addition to a format string:

var obj = $$({}, {
  format: $('div#theform')
});

That way the user won't need to use a separate template engine if all they want is to separate HTML from JS.

One of the problems with using an external template engine is that when a model property changes, the entire view needs to be re-rendered (that's how I understand the code above works). This might not be a problem with small views, but can become too slow for larger views. The built-in data-bind mechanism bypasses having to render the entire view by binding specific DOM elements to specific model properties.

So, I guess my conclusion at the moment is that offering a custom template engine solution will likely induce users to not use the built-in data-bind mechanism, and instead use the slower solution offered by the template engine.

Perhaps we should ship our own mini-template engine, which leverages data-bind but also introduces a few useful constructs, such as inline for and if? John Resig has suggested one such mini engine:

http://ejohn.org/blog/javascript-micro-templating/

@tristanls Any thoughts?

[alcinnz]

Theoretically, I think we can already pass jQuery objects to format because it's parsed using $() which accepts it. It just needs to be documented.

As for such a mini-templating system, it would definitely have to parse the HTML as well to work properly. I'll put some thought into this and get back to you. Thanks for feedback.

[alcinnz]

The thing with templating for me, is that I want to use Agility.js for my PyOfWave project in place of SproutCore or JavaScriptMVC. However, my interface design (http://pyofwave.info/sketches/desktop/) is so dense, everything means something, that it would render data-bind unusable.

Model sharing is also of interest to me.

[alcinnz]

That link's effectively the same as doT, except that with() is nice. So I'm familiar with that design.

As for templating, how about syntax defining $ to prefix model names, followed by ; for include, ? for if, and % for for. $! would close if's and for's. These operations must be confined to HTML content or value for those would be parsed as well, but may be surrounded by other content (a must for me).

[alcinnz]

O. K., I've given the implementation a thought and my conclusion is:

• The templates should be parsed into bindings, as this would be most efficient and compiling to a function would be intermediate processing.
• However, with the current system, I could not implement for's and if's, and to implement these "blocks", I'd need:
  • An object wrapper (which could be used to implement the other issue I'm interested in, cross component bindings).
  • A sequence of references representing bound data.

I'll commit these additional constructs then create the templating. This would endup with more code then this request, but would be better, however, I'll be as concise as possible.

While I'm here, I'd say that I'd have the ; would also include Agiilty objects.

[alcinnz]

Please look at my repo for plans for my next commits. Feedback's welcome.