Incidentally, my XML editor complains about this as well (invalid <
character). I checked the Velocity source and found out that there are
alternate operands such as "lt". Nice!
<Worksheet ss:Name="Data" ss:Protected="1">
#if($cols < $mincols)
#set($cols = $mincols)
#end
<Table ss:ExpandedColumnCount="$cols" ss:ExpandedRowCount="$rowcount">
etc.
WILL
----- Original Message -----
From: "Will Glass-Husain" <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[email protected]>;
<[EMAIL PROTECTED]>
Sent: Thursday, August 25, 2005 10:33 AM
Subject: Re: Velocity Markup (was: Re: XML in templates)
Interesting thoughts from both Robert and Henning - thanks.
Robert, thanks for explaining how your XSL content management works. Very
interesting. I see why you want to do the XML processing before the
Velocity processing.
Henning, I don't think we need to implement a XML format for Velocity.
Just trying to see what's the most practical way to help users do XML
templates with Velocity. The Eclipse VeloEdit editor does a nice job of
supporting HTML and Velocity tags - there's no reason why an editor
couldn't support XML and Velocity as well. Ah, well - I don't do this
often enough to make a concerted effort to make a custom editor plugin.
(most of my Velocity work is HTML with only occasional forays into XML).
As a side note - in my latest project I've been using Velocity to generate
Excel spreadsheets with the Excel 2003 XML format. It's really
interesting to see how applicable this technology is now that more and
more of the world is moving to text formats.
Best,
WILL
----- Original Message -----
From: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
Newsgroups: hometree.jakarta.velocity.dev
To: <[email protected]>
Sent: Thursday, August 25, 2005 12:23 AM
Subject: Velocity Markup (was: Re: XML in templates)
"Will Glass-Husain" <[EMAIL PROTECTED]> writes:
I've been having the same issue using Velocity to autogenerate XML.
There's
a benefit to using an XML editor on the template (I'm using the XML buddy
plugin) since it does autocompletions, etc. But most editors choke on
the
extra-XML syntax (such as #if's).
Well, one thing that we have to think about is, that Velocity is not
just a "XML-ish" tool. I use Velocity to build free-form documents,
transform CSV lists and do many more things, that are not at all
related to any markup language.
Would it really make sense to have markups for the language?
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:velocity="something reasonable">
[...]
<body>
<velocity:if>some condition here</velocity:/if>
<velocity:set>a=0</velocity:set>
<velocity:else/>
<velocity:set>a=1</velocity:set>
<velocity:end/>
</body>
</html>
I think we should learn from the painful experiences with
Jelly. Writing a programming language in XML is not only not very
efficient; noone really likes to write programs by hand in XML and
trying to do multi-tag things like #if .. #elif #else #end in any sort
of markup leads to unspeakable horrors.
(There was a nice "letter to the editor" by Ralf Engelschall (ASF
member and author of mod_rewrite) in the 9/2005 issue of the german iX
magazine. It basically stated "XML is fine as long as there are
machines on both sides of a communication. As soon as a human is
involved, XML is not really the best solution". While I don't agree
totally with him, he does have a point.
The current Velocity syntax is quite readable even in larger
templates.
Anyone have other experiences?
To be honest: Velocity is such a widely accepted standard, that I'm
happy that most editors are able to deal with Velocity #tags. I have a
plugin for Eclipse and emacs can deal with it. :-)
One of the strong things about Velocity is that we do not have
open-tag .. close-tag constructs like PHP or JSP (shameless plug: see
http://henning.schmiedehausen.org/velocity/Jakarta%20Velocity.pdf,
page 6). Let's keep it that way.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]