>>> Mark Galbreath <[EMAIL PROTECTED]> 19-Apr-01 5:58:17 PM >>>
>I disagree, though. I think Nic's looking at it
>from the wrong angle. While it's true that you
>often can't tell what a form does by looking at
>the form, who cares?
The designers who have to alter the code.
Also: the tools that might be developed to make life easier if it
weren't for this evil methodology.
>If you want to know what a form does, look at
>the servlet that supports it!
So:
- look at the form location and the directory context of the form
- work out the location that the form calls
- look at the web.xml file that declares the servlet mapping
- look up the servlet maping that matches the form call
- look up the servlet class that the mapping relates to
- look at the java source for the servlet and check out what it does
That's great! 3 files that you've got to open instead of one. I feel
like my life has been made a lot easier. Not.
The other thing is you have to be a java programmer to work out
what's going on. Possibly a good java programmer depending on who
wrote the servlet.
That's not much use if you have significant design input into your
site. Some designers can handle JSP code but the ones who are going to
be able to read a servlet are few and far between.
That means you're going to have to find other ways of expressing the
relationship between pages, a page plan or something. You're going to
have to maintain that and keep them involved in it. I don't know of a
good tool for doing that.
Lastly, you're going to have to ensure you have real tight control of
your source code when the designers need to do an update because one
wrong step merging in their changes and....
>I suspect his complaints may stem more from a weak
>business-layer than from MVC issues.
I can't see how this discussion has got anything to do with the
business layer. I'm complaining about the management cost of MVC in
large UIs. What my business layer looks like is neither here nor there
(and I've been an OO programmer for a while so my business layer is
fine thank you very much /8-)
The basic premise of MVC is a bodge. A FORM or an HREF actually is
part of the Control, not part of the view. It's a lie to say it's
separated by using servlets to recieve the submit. It's partially
separated.
>The JSP filter stuff is a new feature where you
>can chain pages. Basically, the inbound request
>is handed to the first filter in a chain, which decides
>what to forward to the next filter in the chain, and so
>on.
This isn't quite right... filters are *not* servlet chains.
>Eventually, the last filter in the chain forwards the data
>to the real target, which sends the response back through
>the filters in the reverse order.
Again, not quite right. The stack is only unwound on termination of
the service call. Output filtering can be achieved by overriding the
response handler to decorate the response stream but you don't need to
be doing that to benefit from filters.
>Typical uses include things like adding the header
>and footer to each page, or URL rewriting to get
>session state without cookies. I just don't see the
>advantage.
Because you don't really understand what a filter is. It's not a
servlet chaining system it's much more than that.
A filters can adapt the entire environment that the target recieves,
they can do that in a completly modular way and they do it without
interfering in the syntax of your page invocations.
For example:
- you could have a filter handle multipart submits and present them
to the target in a sensible way (maybe through some pre-defined
attribute or an additional method)
- a filter could extract elements from a database query leaving the
results in a hash on the request attributes, or directly accessible
through an extended request object
Filters can directly take over from servlets in an MVC model.
If we find a way of declaring dependancies between filters and JSP
pages (or whatever display medium is being used) then that will be a
further step in the right direction.
Nic
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
