> Hi Has! As I like to complain recently, ZPT is written by and for smart people. Too much so.
Poor things can't help being so intelligent, you know. ;)
The thing about smart folks is that they're extremely good at dealing with complexity, so they're not under nearly as much pressure to simplify, simplify, simplify... and then simplify some more. They can dive straight in and whip up the first thing that comes to mind, then use it no problem at all. Which is great for them (and best of British, I say) although it can leave them a bit perplexed as to why merer mortals' heads keep going 'Pop!' :p
> 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.
Of course, it all depends on how you define "template" in the first place. The template DOM is 'push', but it's tightly coupled to the presentation logic which, in a good MVC design, is entirely 'pull'. Folk using macro-style engines consider both the HTML markup and the presentation logic as the 'template', since they're both embedded in a single file. You can regard DOM-style systems in the same way too. It's a handy perspective for proving its MVC credentials, where the UI-to-Model interface must be pull only.
Alas, the biggest problem with DOM-style engines isn't that they're hard to understand or use, it's that they're a menace to explain to other folks raised on the macro-style approach. The latter can encourage some funny mindsets, like "Everything in the HTML file is the UI. Everything in the C/Java/Python files is the Model code." Lots of potential for misconceptions to form, unfortunately. :/
> Now if only there was a java port of HTMLTemplate, we could use it at work. Portability of templates is mandatory here.
It's under 500 lines of Python code, which I imagine falls within the realms of possibility. Though not being a Java head I've no plans to do a port myself. Of course, if "portability" means "not just your markup but its control logic too" then I fear "template portability" probably isn't going to mean that much in practice. Then again, if 9/10ths of your Java code is Model logic anyway then what's another few lines' work porting the presentation logic separately?
Poor things can't help being so intelligent, you know. ;)
The thing about smart folks is that they're extremely good at dealing with complexity, so they're not under nearly as much pressure to simplify, simplify, simplify... and then simplify some more. They can dive straight in and whip up the first thing that comes to mind, then use it no problem at all. Which is great for them (and best of British, I say) although it can leave them a bit perplexed as to why merer mortals' heads keep going 'Pop!' :p
> 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.
Of course, it all depends on how you define "template" in the first place. The template DOM is 'push', but it's tightly coupled to the presentation logic which, in a good MVC design, is entirely 'pull'. Folk using macro-style engines consider both the HTML markup and the presentation logic as the 'template', since they're both embedded in a single file. You can regard DOM-style systems in the same way too. It's a handy perspective for proving its MVC credentials, where the UI-to-Model interface must be pull only.
Alas, the biggest problem with DOM-style engines isn't that they're hard to understand or use, it's that they're a menace to explain to other folks raised on the macro-style approach. The latter can encourage some funny mindsets, like "Everything in the HTML file is the UI. Everything in the C/Java/Python files is the Model code." Lots of potential for misconceptions to form, unfortunately. :/
> Now if only there was a java port of HTMLTemplate, we could use it at work. Portability of templates is mandatory here.
It's under 500 lines of Python code, which I imagine falls within the realms of possibility. Though not being a Java head I've no plans to do a port myself. Of course, if "portability" means "not just your markup but its control logic too" then I fear "template portability" probably isn't going to mean that much in practice. Then again, if 9/10ths of your Java code is Model logic anyway then what's another few lines' work porting the presentation logic separately?