> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>
> In Velocity, you achieve the same thing with #include() and #parse(),
> where you bring in the content that needs to be 'skinned' (I call it
> skinning...)
>
> <html>
> <body>
> <table>
> <tr>
> <td colspan=2> #parse($header) </td>
> </tr>
> <tr>
> <td>#parse($leftnav)</td>
> <td>#parse($contentbody)</td>
> </tr>
> </table>
> </body>
> </html>
>
> So you can design a set of look and feel templates, and as long as you
> agree on a set of references for the content ($header, $leftnav,
> $contentbody)...
>
> [...]
>
> Yes - but that's no different than an xsl file, right?
We will update Maverick's example Velocity app this way.
XSL is actually quite different. The lookAndFeel.xsl might look
something like this:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:output method="html" indent="yes" />
<!-- Identity transform allows XHTML (or other) tags to propagate -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<!-- The important part -->
<xsl:template match="/document">
<html>
<head>
<title> <xsl:value-of select="title" /> </title>
</head>
<body>
<table>
<tr>
<td colspan="2"><xsl:value-of select="title"/></td>
</tr>
<tr>
<td>
<!-- navigation bar goes here -->
</td>
<td>
<xsl:apply-templates select="content/*" />
</td>
</tr>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Thus the structure of the page, including the html and body elements,
are defined in the lookAndFeel file, not within each individual page.
If you wanted to, say, put the navigation bar on the right instead of
the left, there is only one file to modify. Here is what a
corresponding input document would look like:
<document>
<title>Hello</title>
<content>
<p>
Blah, blah, blah, blah, blah.
</p>
</content>
</document>
> [...]
> And read your last sentence - "some degree". The fact that its a
> standard doesn't matter if Netscape is broken and IE is
> twisting it for
> .NET or whatever...
Yup. And even if browser XSLT support was "up to date", the way it
works is not especially robust - one pass only. I expect that it will
be years before client-side transformation is really viable. But I do
sense that it's coming, eventually.
> [...]
> The problems I see is that to me, it seems that it's suffering from
> scope creep - there are many things that don't seem to adapt well for
> use in XSL (logic and control structures...),
Hmmm, I'm not sure I understand what you mean. XSLT was designed to be
a generic language for transforming node trees. It was built so that
XML documents can be converted into Formatting Objects, which is the
other half of the XSL specification (FO describe layout; you can even
build PDF files from them). It just happens to be that transforming to
HTML falls within the problem domain.
Especially coming from the world of taglibs, I was pretty impressed with
XSLT's logic and control structures. It has for-each, if, a switch
statment, and a very sophisticated expression language for tests. The
only thing I have found troublesome so far is that you can't iterate
over a set of values which weren't in the input document; if you want to
do the equivalent of a "foreach in 1..10", you have to use recursion.
Not pretty. But overall, I have been pleased.
> and I think that JSP
> suffers from the same thing. To solve in JSP, they adapted
> scriptlets,
> which are remarkable on two fronts (I believe). First, the JSP is no
> longer well formed [I am not an XML geek : I thought that the <% %> is
> not well formed XML... it may be some special escape character - I am
> not sure] and second, its recognized as dangerous to allow arbitrary
> java code to be executed. It's nice to see that people are
> getting away
> from scriptlets, but they can't seem to escape completely -
> if you look
> at what some of the taglib stuff is doing, they have to keep
> scriptlets
> for logical evaluation (which I think is a mistake).
Yup, I don't think JSP taglibs are ever going to be robust enough to
obviate scriptlets. As they are written today, they are just too
inflexible. By the time you finally get something sophisticated enough
to cover all the cases, they'll look like XSLT :-)
> Well, you are up on the list
>
> http://jakarta.apache.org/velocity/powered.html
Thanks!
> I am very happy that you support Velocity - I think that all
> it needs is
> a chance. There are many misconceptions about what it is (aside : I
> mentioned to a person I hadn't spoken to in a while that if
> he is doing
> web development now, he should take a look at Velocity. "No, I have
> tomcat and servlets." was the response... Need to do a little work
> there...)
Hehehehe
> If Velocity is all that we think it is, people will use it. If it
> isn't, but there are good ideas in the templating idea, then
> maybe that
> will be carried into the alternatives, like JSP and XSLT. I think we
> all win eventually.
Yep!
Jeff Schnitzer
[EMAIL PROTECTED]
