I do not agree with many of your assertions. In fact the separation you
speak of is exactly what I do and have been doing with JSP since day one.
The simple fact that one can and does embed scriptlet code with a JSP page
for presentation purposes, does not mean that stuff is being lumped
altogether. Putting restrictions in what one can do with JSP smells like a
terrific way to cripple JSP in favor of other approaches... such as
webmacro. It doesn't make the specification better, or JSP more useful and
flexible.
I also take offense in your suggestion that webmacro supporters, and
webmacro creators for that matter, "tend to be a bit more experienced than
everyone else". So you have an opinion - great - but spare us the assertion
that JSP programmers can't be trusted to make appropriate architectural and
programming decisions.
And BTW, you said it: webmacro is a product. JSP is a specification. Does
Java Report even have a category for Best Java Specification? I'd win the
award for my company's Best Java Developer if we had one, but that's equally
irrelevant to the discussion.
Dan
> ----------
> From: Justin Wells[SMTP:[EMAIL PROTECTED]]
> Reply To: Justin Wells
> Sent: Tuesday, November 09, 1999 11:20 AM
> To: [EMAIL PROTECTED]
> Subject: Re: In what ways does JSP score over Servlets ?
>
> Quoting David Geary ([EMAIL PROTECTED]):
> > Hi Justin,
> >
> > I've been following this thread, and I've even looked at the WebMacro
> Web site, but
> > I still have no idea what the advantages of WebMacro are over JSP. You
> seem to
> > imply that JSP has shortcomings which WebMacro addresses, but I don't
> understand
> > what the shortcomings are or how they are addressed by WebMacro.
> >
> > Care to elaborate?
>
> It's very simple. WebMacro, or any other decent template system such
> as FreeMarker (so you know I'm not just plugging my own product),
> enforces a separation of concerns that I view as fundamental to
> web development:
>
> HTML/script on the front in the template (view)
> +
> 100% pure Java servlet on the back controlling the web session
> +
> Business model implementing the business logic
>
> This way of organizing things is generally called "Model/View/Controller".
> In a tempalte system like WebMacro or FreeMarker, this amounts to the
> only sensible way to think about your application. The architecture
> enforces it, pushing you in the right direction.
>
> JSP does not offer very good support for this design.
>
> The most natural thing to do in a .jsp file is lump it all together
> in one big chunk. That's what the language encourages you to do.
>
> People who are a bit more savvy will move as much of the business logic
> as possible into Java beans, thus getting a two level separation of
> concerns. You're encouraged to do this in Sun's documentation, though
> most .jsp code I've seen in my consulting practices doesn't really
> work this way.
>
> Where things really get nasty is if you try and get the full three
> level separation out of your JSP application. You will find yourself
> sorely tempted to mix session logic with presentation logic in a
> single .JSP file. JSP offers almost no help in trying to resolve
> this, and you are more or less on your own--having to remember this
> fundamentally important design decision every time you write any
> line of code anywhere.
>
> The consequence is that nobody ever manages to pull this off. There
> always winds up being some mixing of session logic with presentation
> logic in JSP--it just slips in there, eventually.
>
> This is bad. You really do need architectural support for your designs
> from your tools.
>
> By analogy, think of the "private", "protected", and "public" keywords
> in the Java language. They impost restrictions on you, and stop you from
> getting the information you want when and where you want it. If you
> marked something "private" but you need to access it somewhere else,
> you have to make a design decision. Java forces that on you. This
> restrictive behavior is a GOOD THING because it forces good design
> on you.
>
> C programmers retort that they are such good programmers that they don't
> need annoying restrictions from the language--they can just remember
> what methods are supposed to be private, and not call them.
>
> That position is fairly well refuted. Programmers make mistakes. You
> need support from your tools to enforce your design.
>
> WebMacro, and other similar products, give you that support. JSP does not.
>
> Many people see the value in what I'm writing here. Probably by and large
> WebMacro supporters tend to be a bit more experienced than everyone else:
> people who have been around long enough to realize the importance of
> these kinds of issues.
>
> I think this is why WebMacro was recently selected as one of the best
> three products of 1999 by the Java Report. (Current issue).
>
> Justin
>
> ==========================================================================
> =
> 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
>
===========================================================================
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
