--- Nick Bauman <[EMAIL PROTECTED]> wrote:
> Read Jon's article about the problems of JSP.
> 
> http://jakarta.apache.org/velocity/ymtd/ymtd.html
> 
> I read it and it made me rethink a lot of
> assumptions I had made about JSP.
> 

Without getting into the larger debate - actually
agree with many of the article's issues - the
following paragraph, though, bothers me:
-------
There are some fundamental issues that are being dealt
with in the generated .jsp template. The first one is
the class name. What happens is that the engine needs
to produce a name that is unique in order to work
around class loader issues that might crop up.
Therefore, each and every time one modifies a .jsp
page, a new file is created on disk in the temporary
directory. Unfortunately, this directory ends up
growing in size until someone decides to clean it up.
The engine could probably do this for you, except then
it might make the mistake of actually removing the
wrong file.
[from
http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html
]
--------
The above paragraph describes a 'fundamental issue'
that has absolutely nothing to do with the Java Server
Pages specification and, rather, entirely to do with a
particular implementation of the specification.  As
such, it has no legitimate argumentative value here
and seems quite gratuitous.  The statement 'The engine
could probably do this for you, except then it might
make the mistake of actually REMOVING THE WRONG FILE.'
(emphasis mine) is a blatant appeal to fear.  I highly
doubt this was intentional on Jon's part, but that is
what it is.

Jon - you do not need to do this to support your
arguments.  Please retract this paragraph from the
essay when convenient.

Also, in your discussion on error handling, the fact
that JSP's only catch Exceptions will be changed in
JSP 1.2 spec to include all Throwables.  And further,
it could be argued that many of your complaints about
poor compilation error messages are again, an artifact
of implementation (maturity), rather than
specification.  However, I (were I to argue such)
would have to concede that in that case the
specification is possibly incomplete (failure to
address standardizing the compile/debug part of the
cycle).

All-in-all, though, I won't argue with the basic
point: Java Server Pages do NOT provide a tool-level
separation between View and Control.  And I wish
others would stop pretending that it did.  

With my team, I try to stress that JSPs can (and
actually should) be used to implement both View and
Control aspects of MVC and to address this we have
adopted (hopefully) strong standards for how we do JSP
development.  There is more to it, but basically we
conceptually separate JSPs into four basic roles:
presentation control, presentation content, request
filtering and pure business.  We then enforce naming
conventions and required strategies to development of
JSPs in these roles.  I don't claim this is ideal, but
it seems to work very well.

I am interested in template solutions like Velocity,
though and intend to look at it closely.

Cheers,

Dr. Mel Martinez
[EMAIL PROTECTED]




__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Reply via email to