On Fri, Sep 23, 2005 at 09:53:45AM -0400, MenTaLguY wrote:
On Thu, 2005-09-22 at 21:36 -0700, Bryce Harrington wrote:
The second was that mixing the <>'s for the template language with the <> from the data got extremely confusing. That's one of the reasons I like Template::Toolkit - since the templating commands are enclosed in [% %] it distinguishes it very clearly from the HTML or XML data.
Three things to bear in mind:
- most users of templates will be using the GUI, not editing them
directly; I don't think syntax nicities matter that much.
- abandoning pure XML syntax means we would no longer have a
well-specified data model -- right now we can rely on XML Infoset.
- similarly, we'd have to abandon pure DOM for our document/plugin
interface.
Unless JonCruz or someone beats me to it, I'll elaborate on my out-of-band XSLT comments later when I have time. Having thought about it more since last night, it is much cleaner and would require significantly less work.
But e.g. getting N copies of an SVG object with transformations is trivial in XSLT, particularly if Inkscape generates the XSLT for you behind the scenes (so it knows about e.g. object bounding boxes etc.).
(It's pretty much an issue of duplicating an XML subtree N times, appending an appropriate string to the transform= attribute for the root of each one.)
Okay, thanks for the info. For my own purposes I would be hand writing the template code, but you're right that in general a user would probably prefer editing them in the GUI. This answers my question of whether something like TT could be done within the existing DOM model.
Bryce