Johnny Cass wrote:
> Jon Stevens wrote:
>
>> Velocity kick's JSP ass so badly, in so many ways, it is silly. I'm going to
>> start working on a page that just shows how bad JSP really is. Even combined
>> with nice toolsets like Struts, it still sucks.
>
>
> I've read a lot of opinions like this one all over the net (that JSP
> sucks). Though my intuition tells me that using Velocity *must* somehow
> be better than using JSP, I haven't actually been able to determine
> *why* this is the case.
When you have been using JSP about six months, in a real project, you
will notice that your code is harly manageable. Then you will think that
you should write taglibs (now) or inherit from a given base class your
pages (I did it this way, because when I was involved with JSP taglibs
were not available). And you should edit all of your pages refactoring
code and moving it out of pages. That will be the first real pain, and
it will hurt a lot if deadline pressure delays this refactoring until
when it is too late. Your second pain will be that your code, no matter
what efforts you do, will end being spaghetti code, and maintenance will
be very hard. Your last pain will be to redesign and redeploy the system
using better design (MVC or whatever pattern you choose).
I know, this is about software engineering, not about the JSP pages. But
the fact that JSP makes it easy to prototype without ANY previous design
effort makes this pain very big. OTOH, tools like Velocity and models
such as Turbine pull together make developers isolate View/style issues
from Model/logic issues. They give your mind the right conceptual frame
to think about the problem.
To stress it: JSP is about PAGES, while Turbine Pull is about WEBAPPS,
ACTIONS and TEMPLATES. Once the team get this mind frame, it does not
matter if you use JSP for your templates.
I have seen this problems happening with Microsoft ASP technology (be it
perlScript, JScript, or VBScript). Cocoon people had to control it with
XSP taglibs, since they were violating the principle of separation
between content, logic and style in their own examples. And they have
very sound engineering principles guiding their development.
I don't want this to happen with java technology, because if projects
fail, people will say "this crappy java tech is not worth the effort".
I'm also waiting for your paper, Jon :)
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
