Ray Cromwell wrote:
>
> 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
(Note he later realized it was Justin Wells who made these assertions
previously.)
> Problem #1: Java Code too Tempting
>
> You assert that using Java code in the page is bad
Sun asserts this. I agree.
> whereas you think that using WebMacro template code is good.
It's a lesser evil. I'd rather see a simplified scripting language
used in the page than a strongly-typed unforgiving compiled language.
Different "languages" are better for different tasks. Java, as much
as I love it, is not ideal for scripting.
Other template engines can use whatever syntax they like and you like.
JSP leaves you effectively coding with XML.
> 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.
Sure, some people prefer JSP's syntax. I'm fine with that. I dislike
that in Sun's APM (and other sources) they assume everyone prefers JSP.
> 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.
You skipped the cookie example. It's more compelling than this first
example in my opinion.
> Problem #3: Simple tasks are hard
>
> Talk about grasping for non-existant straws. Many people would find
> the XML syntax for including SUPERIOR to yours.
OK. The JSP syntax is not my cup of tea, but it may be yours. Based
on students I've taught both technologies, I believe the WM syntax is
easier to remember. Most were thrilled to realize there was an
alternative to JSP.
> I could just as easily claim that some user would forget a quote
> or '#' symbol in your example.
Sure. But WebMacro appears consistent. For example, all keywords
begin with #.
JSP appears inconsistent unless you know what's going on underneath.
Things that begin <% end with semi-colons. Things that begin <%=
don't. Things that begin <%! have semi-colons. Why? Because of how
the servlet underneath is made.
> Problem #4: Looping
>
> Well, given the extreme popularity of Cold Fusion, I'd say they would
> prefer the XML syntax.
Perhaps. Again, I'm not saying WebMacro is the right solution for
everyone. I'm saying that JSP isn't always best. If you like XML
syntax, then get a template engine specializing in that. I don't know
much about Cocoon but it seems a likely candidate.
> Furthermore, atleast with a *REAL MACRO* facility (why is it called
> WebMacro when it doesn't have any macros?)
Because, according to Justin, macros have yet to be implemented.
Should be fun when they are.
> 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.
That syntax ain't half bad. Though, for my own site, I think I'll
finish the work faster using WM's built-in looping, and avoiding having
to write the tags above.
> Problem #5: useless error messages
>
> More of the same. "But what if the user leaves out a semicolon".
Based on students learning JSP, I've always had to reveal where the
src was being placed so that they could debug their pages. That's not
right.
> 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 '()'
Accessing an invalid property (or any template syntax error) generates
an error message to the console with an accurate description of the
problem, so you can fix it. Because there's no translation to a
servlet, the error messages can be fully accurate, unlike JSP error
messages.
> Problem #6: Need a compiler
>
> This one is reaching very hard, I grinned, and almost laughed.
Interesting. It's actually been a serious problem for the JSWDK (now
Tomcat). I've sat in long meetings at Sun where we tried to figure out
how to work around this problem so the server could ship supporting JSPs
out of the box. We couldn't initially get a license to ship Sun's
compiler, so we had to decree that users install the JDK and manually
set their classpath to include tools.jar or dev.jar or classes.zip or
whatever archive held the compiler on their system. That caused about
100 people to write the server feedback alias saying, "Your server's
broken" because they didn't read the instructions. That makes the
server look bad, and wastes our resources having to help people learn
that we couldn't provide a complete solution and there are steps they
have to take to make the server run.
This is a serious problem for corporations. Plus, the companies have
to support various Java compilers. No company likes supporting more
than they have to, especially a compiler they didn't write and may not
have seen before.
> Problem #7: Wasted Space
>
> Come on, you're claiming that the compiler generated temporaries are a
> problem? With today's disk prices? Get real.
ISPs don't give you Gigs. They give you something like 30 Megs. For
more you've got to pay more.
> 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)
Sounds like a complicated workaround.
> Now let's talk about what I see as WebMacro's problems:
>
> 1) much slower than JSP/servlets
Maybe. It works *way* faster for me because I can have the
servlet/template catch its own output and resend that cache on later
requests. Since my db query takes several seconds, this is a 99%
speed boost. I just regen the page when my db changes. It's
beautiful. JSP pages don't let you catch their output.
You also can't GZip your JSP output on the way to the client. That's
a trick servlets/templates can use to speed up slow connections.
> 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.
There's nothing to say a dedicated template engine has to waste the
heap.
> 3) not standard, not widely used
Hey, this could be a perk. You can be the fastest site designer on the
block since you use a secret weapon. :-)
> 4) not as powerful as Java, can't define subroutines, or build up
> high level constructs.
This can also be considered a benefit.
> 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.
I'm not sure what you mean here.
> 6) not based on XML syntax, thus, no real chance of mainstream
> tool support.
I don't see why you need XML syntax for a tool vendor to support you.
> 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.
Yeah, I like Tcl. Wonder what kind of template engine could be written
using a Tcl-ish (ha) base.
> 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.
If JSP solves all my problems, then I'll go back to using it.
> 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.
Well, you haven't used WebMacro so it's dubious how well you can
compare the two. I used JSP and WebMacro both to design sites and I
found WebMacro vastly superior. I just want to share that with people,
along with the places where I found it superior, so that people who may
be having similar problems with JSP know there's an alternative.
-jh-
===========================================================================
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
