> I do like the look of HTMLTemplate, it's sensibly data-driven, which I think is definitely the way to go if you put any special markup in your template.
I suppose the template compiler could be described as 'data-driven', in that you feed it data - HTML markup with embedded compiler directives - and it outputs an object model whose structure (node positions and types) is determined by those embedded directives. Usage is thoroughly code-driven, however, with the Python-based 'view controller' taking Model data and injecting it into template object model.
With better introspection support in template nodes, it would be possible to provide an optional add-on layer that provides a data-driven API for common cases: feed in a dict or class instance and it'd pull info out of its attributes and stuff it into correspondingly-named template nodes for you. I've played a little with this in an experimental fork, but I've too many other projects taking precedence to work on it more right now.
If you want an example of a data-driven DOM-style engine, check out Amrita for Ruby:
http://amrita.sourceforge.jp/
This type of architecture wouldn't be my choice as I reckon it'll be easier to create a code-driven engine and then build data-driven extensions on top than vice-versa. (I'm a big fan of the 'lots of simple little layers' philosophy where you can go in at any level(s) you want.) But it'll give you an idea of how a DD API might look and act.
> Think ZPT with only simplified path expressions, or ClearSilver without the gunky *SP-style syntax. This is what we've learned the hard way to do in ZPT anyway.
I'll confess, I totally did nick the "let's hide things inside tag attributes" idea from ZPT. :) Moving all the rendering logic elsewhere (the only thing left in tag attributes is the node's type - 'con' or 'rep' - and name) came from Apple's non-standard but very effective concept of MVC.
...
Truth is, I originally wrote me a typical 'embedded mini-language' templating system just like everyone else was doing at the time. But after killing myself for a few months trying to develop it beyond the basic feature set, I realised I wasn't a good enough programmer for the task and had to find a much quicker and easier approach PDQ.
One of the, um, advantages of being relatively stupid is that it really forces you to find and follow very rigorous "less is more" strategies. If you try to dive in at the deep end like the smart folk do it really, really hurts. :)
HTH
has
dumber is better :-)
Posted byslinkpat
2006-02-07 12:20 PM
Hi Has! As I like to complain recently, ZPT is written by and for smart people. Too much so.
Maybe data-driven was the wrong word for HTMLTemplate. It seems to use a "push"
model rather than a "pull" model - i.e. the app has to compute data and push it into
the template; the template doesn't otherwise have access to pull anything from the environment.
I came across an interesting quote at http://www.stringtemplate.org/about.html :
"The pull method requires that programmers do a topological sort in their minds anticipating any order that a programmer or designer could induce. To ensure attribute computation safety (i.e., avoid hidden dependency landmines), I have shown trivially in my academic paper that pull reduces to push in the worst case. With a complicated mesh of templates, you will miss a dependency, thus, creating a really nasty, difficult-to-find bug."
See, by being dumb, you are doing the smart thing ;-)
Now if only there was a java port of HTMLTemplate, we could use it at work. Portability of templates is mandatory here.
I suppose the template compiler could be described as 'data-driven', in that you feed it data - HTML markup with embedded compiler directives - and it outputs an object model whose structure (node positions and types) is determined by those embedded directives. Usage is thoroughly code-driven, however, with the Python-based 'view controller' taking Model data and injecting it into template object model.
With better introspection support in template nodes, it would be possible to provide an optional add-on layer that provides a data-driven API for common cases: feed in a dict or class instance and it'd pull info out of its attributes and stuff it into correspondingly-named template nodes for you. I've played a little with this in an experimental fork, but I've too many other projects taking precedence to work on it more right now.
If you want an example of a data-driven DOM-style engine, check out Amrita for Ruby:
http://amrita.sourceforge.jp/
This type of architecture wouldn't be my choice as I reckon it'll be easier to create a code-driven engine and then build data-driven extensions on top than vice-versa. (I'm a big fan of the 'lots of simple little layers' philosophy where you can go in at any level(s) you want.) But it'll give you an idea of how a DD API might look and act.
> Think ZPT with only simplified path expressions, or ClearSilver without the gunky *SP-style syntax. This is what we've learned the hard way to do in ZPT anyway.
I'll confess, I totally did nick the "let's hide things inside tag attributes" idea from ZPT. :) Moving all the rendering logic elsewhere (the only thing left in tag attributes is the node's type - 'con' or 'rep' - and name) came from Apple's non-standard but very effective concept of MVC.
...
Truth is, I originally wrote me a typical 'embedded mini-language' templating system just like everyone else was doing at the time. But after killing myself for a few months trying to develop it beyond the basic feature set, I realised I wasn't a good enough programmer for the task and had to find a much quicker and easier approach PDQ.
One of the, um, advantages of being relatively stupid is that it really forces you to find and follow very rigorous "less is more" strategies. If you try to dive in at the deep end like the smart folk do it really, really hurts. :)
HTH
has
Maybe data-driven was the wrong word for HTMLTemplate. It seems to use a "push"
model rather than a "pull" model - i.e. the app has to compute data and push it into
the template; the template doesn't otherwise have access to pull anything from the environment.
I came across an interesting quote at http://www.stringtemplate.org/about.html :
"The pull method requires that programmers do a topological sort in their minds anticipating any order that a programmer or designer could induce. To ensure attribute computation safety (i.e., avoid hidden dependency landmines), I have shown trivially in my academic paper that pull reduces to push in the worst case. With a complicated mesh of templates, you will miss a dependency, thus, creating a really nasty, difficult-to-find bug."
See, by being dumb, you are doing the smart thing ;-)
Now if only there was a java port of HTMLTemplate, we could use it at work. Portability of templates is mandatory here.
Replies to this comment