> Quoting root ([EMAIL PROTECTED]):
> Interesting. Do you always read mail as root on your box?
Nah, it was an accident, that's why my post never showed up on the
JSP-INTEREST list. I actually read mail through my service, MsgTo.com
(just for reference, 100% java: servlet/jsp, smtp, pop, imap, and
webmail Database is also custom written 100% java. End result is up to
2 million messages handled per day on a dual processor Solaris x86
box. XML+XSL used for skins/themes.)
> There is a lot of pressure coming from Sun that JSP should be considered
> the primary, almost only, tool for building web-pages. Evidence this
> silly notion that if you want to do MVC design you should do it within
> the context of JSP.
Why is it silly? First of all, I see no such claims that JSP is the
"one and only" from Sun, giving that they are also pushing servlets,
and are now starting to push XML/Metadata initiatives. In fact, their
own whitepapers list several so-called "application models"
Second of all, you keep implying that you can't do MVC with JSP which
is incorrect. MVC is a *DESIGN PATTERN*, independent of implementation
language. MVC exists everywhere, in Smalltalk, C++, Java, and any
other language. So the impliciation that JSP can't do MVC is quite frankly,
absurd.
Now, maybe you believe that WebMacro can *enforce* MVC whereas JSP
can't. That may be (although I see plenty of room for abuse of
direct method calls in WebMacro), but this is not the holy grail
of MVC anyway. The whole idea of applying MVC terminology to
server side programming is fraught with problems. MVC, as
known in the GUI/design pattern literature consists of the Observer,
Composite, and Strategy design patterns. Its main purpose is to
establish a publish/subscribe mechanism to allow views to get
notified when underlying data models change.
Since server side code doesn't usually push HTML updates to a client
as soon as the data model changes, nor does WebMacro support the
Strategy pattern in its syntax, nor does it seem to permit effective
View Nesting or reuse, I would hesitate to call it MVC. The whole
idea of trying to call it MVC, seems to me, to be simply a marketing
attempt to try to capitalize on the success of JFC's evangelizing.
> Each imposes its own different set of restrictions on the kind of
> design you can pursue while using it. In some situations, the design
> conditions imposed by a tool like WebMacro will turn out to be
> wrong and you'll want to switch to a kona/ECS type solution. In
> other situations that would be wrong, and instead you'll prefer
> to use a template system like WebMacro.
I'm still waiting for someone to give me an instance of where you would
even want an ECS type solution. There is only one example I can
possibly think of, which is a compound collaborative editing system
which persists HTML pages as objects in a database, and allows one
or more users to "lock" a TAG, and eddit a TAG, and edit it or its children.
POET uses this approach to allow collaborative XML editing with revision
control down to tag level granuality. Of course, POET's implementation
is light years above ECS's simply CGI.pm like approach.
CGI.pm in Perl had one other reason to use a few ECS like calls, and that's
when you were printing INPUT/FORM tags, and wanted CGI data automatically
inserted into the VALUE attribute, and escaped.
But the "build up hundreds or thousands of objects in memory, just so
you can print them out" approach has a severe impact on scalability,
and frankly, is a bitch to maintain.
> I don't presume to talk down to anyone. I think JSP made a big mistake
> ignoring all the history you are describing and breaking with that
> model of programming.
What model of programming? I can't find any MVC in Perl/Python/PHP/Cold Fusion.
All I see is direct calls to the DB via DBI/ODBC/Markup. JSP is not
a departure from tradition.
> WebMacro prevents you from making design errors in the overall structure
> of your servlet by architecturally keeping you from burying important
> business logic in the middle of some ugly block of HTML.
And so does JSP, or even servlets, by using an application server approach.
All you need to do is simply place all business logic in EJB, CORBA, or
RMI accessible objects, and make data simply inaccessible from the servlet
or JSP page by not providing a JDBC driver, or using a policy file.
I can, and have, used this approach. By making it impossible for the
presentation code to access any data except invoking application server
methods.
> > Likewise, JSP provides a mechanism to achieve what you are talking
> > about, naming the USEBEAN/BEAN tags, and the 2.2 Taglet mechanism,
> > just like JRun's taglet mechanism. However, JSP allows you to
> > "fall back" to Java fragments if needed. JSP is a superset.
>
> How do you prevent someone from putting code into the HTML portion
> of a JSP template? If you can't, it doesn't offer you support.
What's wrong with putting code into the HTML portion? WebMacro does
it. WebMacro *IS CODE*, sitting smack dab in the middle of HTML.
Perhaps you mean "how do you prevent them from putting business
logic in the middle of HTML code". The best you can do is eliminate
access to data models, you can't prevent business logic. Neither
can WebMacro, because WebMacro's #if command, combined with #set,
or method calls, can quite easily be used to write important business
logic in the view layer.
In fact, if I quote the WebMacro documentation, we see an example of
this:
#if ( $Customer.owesMoney() && ($Customer.Name != "Fred") )
{
Pay up, or else!
} #else {
Thank you for your patronage.
}
or my own example
#if ($shoppingcart.isTotalOverLimit())
{
#set $shoppingcart.discountEnabled = true
$shopppingcart.updateDb()
}
Since WebMacro lacks a ">" operator (couldn't find it in docs)
how I *limit* my view of a container. What if I wanted to scan through
a container and render only the odd rows in one column, and the
even rows in another?
> > Worse, WebMacro doesn't support rapid prototyping or the iterative
> > development model.
>
> That's the most ridiculous thing I've ever heard. WebMacro was
> designed to support rapid development:
Sorry, you misunderstood. Rapid Prototyping means being able to
write your DB calls/business logic in the HTML view, test it,
make sure it works, and then "refactor" it out into a bean or
servlet. A rapid prototype should be doable in a few hours to
a day's time vs a real prototype.
> -- Your page designers go off and play with the webpage, your
> programmers go off and start turning some of the hashtable
> data into real data from the real source
This is simply rapid prototype of HTML, not rapid prototype of
business logic.
> FreeMarker takes this approach. I took the view that the work of
> creating all these adapters winds up getting in the way of rapid
> development, iterative development, and prototyping, which you
> were just propounding the merits of a few minutes ago.
and surely you must realize that WebMacro also gets in the way of iterative/rapid
development, since one must edit 2 or more files to do something quickly,
and probably recompile something, and restart the server. This can't
possibly be as "rapid" as ASP or Cold Fusion, where someone can write
a page to do a SELECT and dump a table in about 3-4 lines of code
and have it working in 60 seconds.
> > Instead, WebMacro allows one to set variables and call any public
> > methods on objects, which opens up its own can of worms when it comes
> > to design.
>
> Not true. You can only access objects that are inside your context,
> and it's up to your controller to decide what objects you get access
> to, and whether or not they are readonly.
But you still can't prevent calls to public methods right? The bean
may have public methods that the servlet has a right to call, so
they are declared public, but you can't stop $container.methodCall(foo)
> It is only in JSP where the nightmare you describe above is the
> natural way to do things. Yes, if you were evil you could use WebMacro
> in ways you shouldn't to violate the encapsulation--but it doesn't
> come naturally, you have to work at it. You won't do it by accident.
> With JSP it's easy to stick a few lines of code into your HTML, as
> needed, to update your objects, to grab that extra bit of information
> from the database, etc.
No it isn't. It is quite trivial to prevent database access in Java,
Java's security ensures that. A JSP scriptlet can't access *ANY* data
that the servlet container doesn't want it to. This is all controllable
from the SecurityManager or AccessController. You seem to think that
a JSP environment can just trivially say "get a DB connection, or open a file,
and start accessing data", when in fact, setting up a JVM to allow
this in the first place is a great source of angst for many people who can't
even get a JDBC driver to connect properly.
WebMacro's MVC has *nothing* over the application server model of
JSP<->RMI/IIOP. In fact, Java's built in security seems to be far
more secure than WebMacro's "security through obscurity" approach.
(a WebMacro can access anything reachable from Bean's public methods, and
not just those "put into the Hashtable" context)
> I don't see XML+XSL as competition for WebMacro. I see it as a very
> important and useful solution for the kinds of problems that WebMacro
> is not good at solving. I see WebMacro as the correct way to go when
> dealing with the kinds of things that XML+XSL doesn't do well.
Please list some problems that Servlets+ XML + XSLT can't solve that
WebMacro can. Since I have already used it to implement a very scalable
messaging system and "skin/theme" my whole website, plus, I have used it to
implement an e-commerce store by rendering XML representations of
result sets and shopping carts, I'd like to know.
I have modified GNUJSP so that my servlet/JSP code outputs XML, which
is then run through an XSLT stylesheet before output. For performance,
direct calls are made to SAX events (no parsing needed, all done at compile
time), and streamed directly to an XSL processor which transforms them.
(Cocoon is proposing to use the same technique)
Thus, I can write the following in JSP
<msgs>
<message num="1" uid="475533654" from="Ray" subject="JSP vs Servlets" .../>
<message num="2" ..../>
</msg>
And GNUJSP transforms this *at compile time* into
handler.startElement("msgs", attrs);
attrs.clear().
attrs.set("num", "1");
attrs.set("from", "Ray");
...
handler.startElement("message", attrs);
handler.endElement("message");
...
Which is streamed into the XSLT processor.
So I use JSP/Servlets to fetch/create any XML result set I
like, and then use XSLT to render the output. The end result
is that the presentation editor only has to deal with styling
the data. I can even allow end users to upload their own
stylesheets (not allowing it yet), in which case, there is
less of a security risk than allowing people to make direct
Java method calls or impact business logic.
Since there will soon be lots of visual editors for XSL, I'd
say its alot easier than editing mixed code/html views.
> With WebMacro these issues only come up if the servlet programmer decides
> to allow them to come up by choosing to place dangerous objects in the
> context, making them accessible to the template.
And you're saying that JSP can always get ahold of dangerous objects?
Patently false. I refer you to the Application Programming Model
as defined by Sun.
> The servlet programmer has complete and total power to decide what types
> of objects, in what form, and under what conditions the template can
> access them.
Servlet authors only have as much power as the servlet container
provides. Same as applet.
> This is one of the biggest problems I have with JSP: by trying to be
> too much, it winds up having to be a total replacement for the Java
> programming language.
JSP *IS* Java. Can't you see that JSP is nothing
more than a way to "escape" HTML syntax and embed it in Java?
>
> That would be preferable, in my view. If they released it under a
> sensible license (as opposed to SCSL) then everyone would be willing
> to contribute to it, and we wouldn't have all these different
They released it under the Apache License!
> > So? JSP Taglets allow far more rigorous design restrictions by enforcing
> > a DTD, but with runtime performance that will blow WebMacro's implementation
> > out of the water.
>
> This is a lot of nonsense. XML parsing is fairly expensive, even with
> some of the fast XML parsers now available. But the big point is that
> in either case, once something has been parsed, it doesn't matter. Both
> JSP and WebMacro parse only once, so this isn't ever likely to become
> a performance issue for anybody, ever.
XML parsing can be done at compile time, as I have implemented in my
GNUJSP hack. XML parsing is way less expensive than parsing WebMacro
code if all you require is well-formedness. I've seen XML parsers
in 3-5 lines of Perl.
My GNUJSP hack compiles XML into SAX calls inside a Servlet at compile
time.
JSPs are compiled to a Java servlet at compile time.
JSP+TAGLETS are also compiled to pure Java code at compile time.
WebMacro seems to be parsed into a parse-tree once and *evaluated* during
each page rendering. You can't possibly be suggesting that WebMacro's
parse-tree evaluator is as fast as compiled Java methods that simply
invoke out.print() ? Now, there's nothing stopping WebMacro from
using the same "code generator" approach, I'm just pointing out, that
JSP1.1's Taglib, which generates code, and compiles it, is faster
than the Cold Fusion/Web Macro approach which is to evaluate parse
trees.
That said, WebMacro is a fine piece of software with a nice syntax
for iterating over Enumerations, Iterators, and bean collections,
and frankly, I wish such syntax was added to Java itself, or
operator overloading was added. Java's creators recognized that
String processing is fundamental, and added an operator (+), for it.
They should realize that collections are also fundamental types and
add a way to use convenient syntax for them also.
However, I just don't buy this anti-JSP MVC argument. In my view,
you are feeling the heat from JSP, and fear that a soluton from Sun is
going to wipe out all the small players. It may, or it may not.
The real solution is not to bitch about JSP, but join the Jakarta
project and help JSP evolve towards those goals that you see WebMacro
solving.
-Ray
===========================================================================
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
