Comments:
This is basically a summary of the same thing you said during the
last flamewar on this list concerning WebMacro where you tried to
assert several things, like that JSP couldn't be used to do
Model-View-Controller, etc. About the only positive thing
your paper highlights is the need for a more economical
iteration mechanism for containers, and perhaps, although it's
borderline, a more economical syntax for variable interpolation.
All the other benefits you assert are dubious.
Before I even start, I must note that MVC is only one possible design
pattern, and the Model 2 design is only one particular implementation
of it. You cannot criticize JSP by asserting the MVC paradigm because
it is not inherently good, while other techniques are evil. Besides
coupling the controller with the "Model", you can also couple it with
the "View". It depends on whether or not the view itself must alter
the nature of the request (see Swing's MVC paper) I use these terms
with quotes, because it's not even clear what MVC is supposed to mean
in the context of server-side logic, considering that it doesn't quite
fit the model put forth in the "Design Patterns" book.
Problem #1: Java Code too Tempting
You assert that using Java code in the page is bad, whereas
you think that using WebMacro template code is good. This is
faulty logic, however. The idea that putting code in the
view page is bad is based on the fact that the people
maintaining the view might be inexperienced and shouldn't
have to know Java. I assert that WebMacro is also "code"
and putting WebMacro syntax interspersed with XML/HTML
is also a no-no.
In this regard, JSP tag libraries and Apache Cocoon are superior
to WebMacro.
Regardless, your argument boils down to: "Java code looks ugly, WebMacro
code looks nice." That's your aesthetics, don't assume your aesthtics
are the same as everyone elses.
Problem #2: Java Code Required
You compare
<a href="<%= request.getContextPath() %>/index.html">Home page</a>
vs
<a href="$Request.ContextPath;/index.html">Home page</a>
Pardon me if I don't feel this is innovative, revolutionary, or
useful enough to abandon Java and adopt yet another syntax.
("Oh no! What if they forget the semicolon on ContextPath!!!!!" See
comments below)
Problem #3: Simple tasks are hard
quoting you:
---------BEGIN QUOTE----------
<% String title = "The Page Title"; %>
<jsp:include file="/header.jsp"/>
Your content here
<jsp:include file="/footer.jsp"/>
Page creators must not forget the semi-colon in the first line or the
odd slash /> in the second and fourth. Plus, the /header.jsp and
/footer.jsp must be made publicly accessible somewhere under the
document root even though they aren't full pages themselves. pIn
WebMacro including headers and footers is done easily:
#set $title = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
There are no semi-colons or slashes for designers to remember, and the
.wm files are found in a customizable search path, not under the
document root.
---------END QUOTE------------
Talk about grasping for non-existant straws. Many people would find
the XML syntax for including SUPERIOR to yours. I could just as easily
claim that some user would forget a quote or '#' symbol in your
example.
The chief difference with XHTML and JSP XML tags are that they can be
easily verified to be well-formed, and validated if need be. Not to
mention that EDITORS and other tools are much more likely to remind
the user and catch missing /> characters than they will missing '#' or
quote characters in WebMacro. Hell, IE4/5, Homesite, and
a myriad of other tools can do this RIGHT NOW.
Problem #4: Looping
Here, I'll give you a few points.
---BEGIN QUOTE---
Someday there will be custom tags for doing these
loops. And custom tags for "if" checks too. And JSP pages may look
like a grotesque Java reimplemented with tags. But meanwhile, the
webmacro loop is already quite nice:
#foreach $isp in $isps {
The next name is $isp.Name <br>
}
The #foreach directive could be replaced by a custom
#foreach-backwards directive fairly easily as well if such a thing
were necessary. Will custom tags really solve this problem? Probably
not. Here's a possible <foreach> tag.
<foreach item="isp" list="isps">
The next name is <jsp:getProperty name="isp" property="name"/> <br>
</foreach>
Which would a graphics artist prefer?
---END QUOTE---
Well, given the extreme popularity of Cold Fusion, I'd say they would
prefer the XML syntax. In fact, I know designers who worked on both
a WebMacro-like template language, and on Cold Fusion projects,
and they preferred Cold Fusion syntax.
Furthermore, atleast with a *REAL MACRO* facility (why is it called
WebMacro when it doesn't have any macros?) like Taglibs, you can
define much higher level constructs, as I have in the past.
Why write code using foreach constructs, when a designer would better
understand something like this:
<lists:define-list src="isps">
The next name is <lists:listitem item="name"/>
</lists:define-list>
For a given project, the architect, in designing both the model and
the view, would be sure to design high level constructs to rendering
output rather than relying on low-level iteration. If WebMacro
had a real macro facility, maybe users could automatically
"call" them.
I personally have written a library of beans that render Swing
models in HTML for tables, lists, trees, etc. They are sufficiently
pluggage and general enough to allow a designer to use an IDE
to customize the layout, and then drop them into a template with
a single line of code that is much easier to understand than
iteration code.
Problem #5: useless error messages
More of the same. "But what if the user leaves out a semicolon".
Let's turn this around. Because WebMacro lacks static typing,
what about those users who write code like
$foo.bar
when $foo doesn't have a bar property. Or those users who leave off
the '$'. or the '()'
Grasping... speaking of which
Problem #6: Need a compiler
This one is reaching very hard, I grinned, and almost laughed.
Come on, you know this is bogus. Besides the fact that
free Java compilers exist like GJ, there is nothing stopping
anyone from installing the JDK on the webserver. There is
*NO* barrier to getting a Java compiler for a webserver. None.
Zero.
Problem #7: Wasted Space
Come on, you're claiming that the compiler generated temporaries are a
problem? With today's disk prices? Get real. Secondly, the class file
need not embed the String constant pools, but can actually store
offsets into the JSP source file, and read them at run time. I have a
hack to GNUJSP that does this. The resulting class files are much
smaller, and *do not* occupy class-heap memory, so that with a little
change, the static String data can actually be GC'ed and re-read as
needed (by using SoftReferences)
Any commercial quality JSP implementation could easily address
all your concerns, and be far more scalable than WebMacro.
Template engines burn more heap memory per request than servlets.
Moreover, with dynamic sites, there usually aren't more than a few hundred K
of JSP source files because most of the real data is in the database, or
included from other sources.
Now let's talk about what I see as WebMacro's problems:
1) much slower than JSP/servlets
2) uses up more heap per request
(JSP translators can convert almost all of a JSP file into
OutputStream.print(byte or char array) with almost no
additional heap expended) Despite your claims, there's no
way your interpreter can match tuned-JSP unless it became
a translator/generator itself.
3) not standard, not widely used
4) not as powerful as Java, can't define subroutines, or build up
high level constructs.
5) POOR code reuse factor. Basically, all you can do is include
code snippets. Ah, the days of m4 and the C preprocessor are back.
6) not based on XML syntax, thus, no real chance of mainstream tool support.
7) It's nothing more than a poor TCL ripoff. Sorry, but TCL's been there,
and done that, and has a much more powerful interpolation mechanism.
Finally, you claim "templates are not well known."
Template languages were used on the web since the beginning. Let's
see: Dynamo, Popsite, Hahtsite, Metahtml, Frontier, Dynamic HTML, Cold
Fusion, W3-Mysql, content management systems like Vignette and IPS,
Sitetech, etc not to mention a bazillion perl hacks. Oh, and
every single one of them claimed to have a revolutionary approach by
"separating content from presentation"
I predict that JSP taglibs, and XML+XSLT will address all your points
in every respect in the next few months. In fact, I find XML datasets
and XSLT to be a far superior technique to separating model from view
than any kind of interpolation based approach.
My only question is, why do WebMacro supporters persist in coming
to this list with their JSP Jihad? I mean, it is a JSP list, and
JSP is the J2EE standard, along with XML/XSLT, they are supported by
the Apache Jakarta/XML projects.
If WebMacro was *vastly* superior to existing technologies, it might
be worthwhile to adopt it vs the standard alternatives, but the fact
is, it's not vastly superior (and might be inferior), and the benefits
gained don't justify the switching costs.
-Ray
> Hello everyone,
>
> I just posted a new article to Servlets.com titled "The Problems
> with JSP" that will be of particular interest to the people on
> this list. From the first paragraph:
[...]
>
> The article is available at:
> http://www.servlets.com/soapbox/problems-jsp.html
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
