5 ms·
There were a whole family of older template systems that worked on this model. They suck because in practice they are much more restrictive, difficult to work w
by _wmd 12y ago
There were a whole family of older template systems that worked on this model. They suck because in practice they are much more restrictive, difficult to work with, and in most cases inefficient, since fundamentally they are working in the domain of a fully parsed node graph, instead of simply being lightweight control structures for basically memcpy().
See e.g. https://en.wikipedia.org/wiki/Template_Attribute_Language https://en.wikipedia.org/wiki/Template_Attribute_Language
On the flexibility front, the same template language (and especially ones with good whitespace control, e.g. Jinja2) can be used for any text-like format. If browser or device quirks force you to emit invalid XML to trigger some desired behavior, you don't end up in a fight with your perfectionist templating system (and probably resorting to regexes over its output) to achieve the desired result.
I'd say (and probably, a younger version of myself turns in his grave as I say it) that in this case, worse turns out to be much better.
- DonHopkins 12y agoTAL as it was implemented for ZOPE was a total abortion (especially when they threw in other crap to make up for its gaping weaknesses like TALES, METAL, and those goofy expression what were not anything like any other language, plus "acquisition" which was a terrible and useless approach to scoping). The ZOPE stack's approach to templating and scoping and components and their entire way of thinking about it was totally demented and wrong headed. I used it a lot in my wild and crazy ZOPE days, and I hated it then and won't ever go back. On the other hand, there are other similar attribute based xml templating languages that are much much better, because they didn't try to reinvent the wheel out of tapioca and rusty iron filings, but instead they simply acted as a thin veneer over Python, so everything you knew about and could do in Python applied without any distortion or unnecessarily creative reinterpretation. Specifically, TurboGears used the "Kid" templating language, the next generation of which was re-implemented as "Genshi". I have used both extensively, and although they do have some problems and limitations (many of which Genshi addressed), I really like them a lot, and they are easy to use and think about, and not so full of surprises and disappointments as the horrible stuff from ZOPE that they (distantly) descended from. I've used Kid and then Genshi in large template-heavy projects over many years, and I still use Genshi and like it. It is actually quite elegant and minimalistic, and super easy to learn. http://genshi.edgewall.org/ http://genshi.edgewall.org/ Genshi operates on pure clean XML internally, has real Python loops, conditionals, variables, functions, parameter passing and extensibility, and has plug-in serializers for various formats like XML, XHTML and HTML5, that know about all the formatting rules and conventions and browser quirks and superstitions like <BR />, and never produce incorrectly quoted or formatted content. You can also use it to product plain text as well as markup.
- bryanlarsen 12y agoYet client-side React is faster than string template languages for most practical purposes. And rarely is speed the most important attribute of a template language. If it was, we'd be writing all of our server code in C. At least for DRYML, it only requires valid XML on input, it can emit any string on output. But in essence, you're right. String templating languages have been more successful than TAL or DRYML. But my belief is that's because we just haven't done it properly yet. TAL suffers XML disease, and DRYML has other problems.
- ufo 12y agoDon't you avoid needing to work on a fully parsed node graph if you proccess data using streams/events? Kind of like how SAX parsers avoid creating a DOM tree in memory. I think Genshi does something similar to this but I'm not 100% sure.