Justin Wells wrote:
>
> Quoting Eduardo Pelegri-Llopart ([EMAIL PROTECTED]):
>
> > The "template" systems that I am aware can be seen as very simple cases
> > of JSP tags. Essentially they provide syntactic sugar for something
> > like <x:templateEval "expr"/>,
> > where "expr" is an easier to write syntax for a combination of getters
> > on implicit objects. I have not mentioned before, but custom actions
> > can create new implicit objects, with different types of lifescope.
> >
> > This is not to underestimate the value of simple syntax, specially when
> > writing pages in a POTE (plain old text editor) like vi, or even
> > (x|gnu|)emacs.
> >
> > I'd be interested if the characterization above is missing.
>
> Well I'm obviously biased against JSP because I wrote a template
> system (http://webmacro.org) precisely because I found JSP too limiting.
> On the other hand, you get paid to be biased in favour of JSP so I
> suppose we're even on that score.
Everyone is entitled to their own opinion, so since I prefer JSP, I've added
some comments below.
> Template systems have several architectural strengths lacking in JSP:
>
> 1. They are not monolithic. By this I mean that their use is driven
> by a servlet, and the servlet can choose if and when to execute
> a template. The same servlet may return some documents using
> a template, and others using an XSL processor. In other words,
> they are a tool in your toolbox, not a replacement for servlet
> programming as JSP is.
JSP can also be combined with servlets, as well as JavaBeans and Enterprise
JavaBeans, so I see the same possibilities with JSP as you describe for templates.
For instance, you can (should) separate the request processing from the
presentation. One common way of doing this is to let a servlet receive the
request, use and create beans to process the request, and then select an
appropriate JSP page for presentation of the result. Different JSP pages can
be used for different client types, such as HTML, WML or XML. Or you may
pick the JSP page based on the user's preferred language, or any other criteria.
> 2. Template systems do not require non-standard extensions to
> Java, which is what JSP is. They work in any webserver with
> an ordinary JSDK and Java runtime. The same cannot be said
> of JSP (which emphasizes standards because it is non-standard).
I'm not sure I understand this argument. Both the Servlet API and JSP are
standard extensions (packaged in javax packages). JSP works in any web
server that supports the Servlet API.
> 3. Template systems intentionally limit what you can do inside the
> template in order to enforce an MVC architecture. In JSP you can
> manually adhere to MVC, but nothing forces you to. The consequence
> is a constant temptation to violate your design, requiring vigilence
> at every step. I think trying to do MVC design with JSP is akin to
> doing OO design in C. You can do it, but why? I'm also not saying
> that you can't find a way to abuse a template, just as it's possible
> to violate OO design principles in Java if you try.
Like you say, it's possible to do a bad implementation with any technology,
not just JSP.
> 4. Most template systems offer you stronger ways to model your data
> and interact with your data than is afforded by the JavaBeans
> spec. FreeMarker, for example, has a fairly rich set of modelling
> adapters. WebMacro (mine) performs class analysis that goes beyond
> what JavaBeans mandates to facilitate the use of arrays, vectors,
> and other common Java data structures that are difficult to access
> in JSP because they are not totally bean-like.
>
> Note that #4 means that template systems are doing far more than JSP
> and thus not just syntatic sugar over some tag system. You shouldn't
> push misinformation like that.
Have you looked at what you can do with custom actions (tag libraries) in
JSP 1.1? I have implemented a number of custom actions that can iterate over
a number of data types, such as arrays, Vector, Enumeration, Hashtable.
They can easily be extended to support all the new Collection API types
as well. With a set of custom actions I'm pretty sure you can do anything
that you do in WebMacro.
> In my view the primary advantage that JSP has over templates is that it
> is similar to ASP and EmbPerl, and thus is a more familiar environment
> for people new to Java who have come from that background. However, I
> don't necessarily think that model of programming is well suited to
> Java, even though it's no doubt strategically important.
Looks like we're almost in agreement about this point. Like I said, I like
JSP and don't see the disadvantages you see, and one of the most important
advantages with JSP over any of the template systems is that it's formally
specified and included in J2EE. This means it will be covered in classes,
books, endless web sites, etc. And therefore be familiar to a lot of people.
This makes it a lot easier for an employer to find people that do not need
to get additional training, makes it easier for developers to share experience,
creates a market for both Open Source and commercial custom action libraries,
allows web design tool vendors to provide great integration, etc. In short,
all the advantages of a broadly supported standard.
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
