JavaServer Pages (JSP) and JSTL - Web development with J2EE, a rant
So, it had to happen...after years of trying without really trying, I am finally involved in a project that deals with J2EE Web development to the nth degree...
I took the project from the ground up with the intention of using all best practices and state-of-the-art design methods.
I knew about MVC Model 2, so that was not new to me.
I initially mapped Model-View-Controller to JavaBean-JSP-servlet.
I figured I would use all the right patterns:
- Front Controller
- Dispatcher View
- View Helper
- Intercepting Filter
- Value Object (JavaBean flavored)
Since I wanted to give the whole approach a fresh start, I ignored all heavy frameworks: Struts, JSF, Spring, WebWork...and the hundred or so other frameworks that average 30MB of bytecode.
So, I decided to roll up my own MVC "framework", to better understand the issues all other frameworks claim to and fail to resolve.
This post is just to get a discussion started, so I will now list a few things that drive me crazy:
- Front Controller
Why would you go through a central controller servlet to access a page that does not depend on any application logic?
Example: I have a couple of JSPs that contain template XHTML and access some application context parameters via EL.
Why would I force clients to request that page through a Front Controller?
- JSP/JSTL
"Scriplets are evil because Web designers don't know Java."
"Scriplets are evil because they introduce application logic in the presentation layer."
"Scriplets are evil because they make debugging very difficult."
Well, I kind of agree with all that, but what JSP/JSTL offer in exchange just doesn't seem any better to me.
- Model/JavaBean
I isolated most of my application logic in a separate library that includes a handful of packages.
This library contains nothing that is Web-centric.
Classes in this library define objects that encapsulate data and behavior that efficiently implement my application logic.
My front controller dispatches requests to command objects. These command objects use the library to do what they need to do.
Resulting state needs to be encapsulated into JSP/JSTL-friendly recipients, which means my command objects spend a lot of resources transferring data from my library objects into JavaBean objects, maps, attributes of primitive types...entities that are easily accessible via expressions, EL, standard tags, JSTL tags, etc.
- View
Following the wisdom of some textbook, I felt compelled to add a "getModel" API to my Command interface.
My front controller calls "getModel" after calling "execute" in order to determine which JSP the request should be forwarded to after command execution.
I don't really have a problem with this. The fact "getModel" always returns the filename of some JSP is only a minor annoyance that makes me think something is not quite right.
So, there we are for a start...
Am I the only one to think some of these things are not quite right?
[3129 byte] By [
Dralta] at [2007-11-14]
Why would you go through a central controller servlet to access a page that
does not depend on any application logic?
For consistency.
You have a central point of entry that you can control
If you DO need to change this page and make it more complex at some point, so that it DOES depend on application logic, it is already in the standard form.
Well, I kind of agree with all that, but what JSP/JSTL offer in exchange just
doesn't seem any better to me.
I disagree with this statement, particularly if you have to mix a for loop in code, with a table. Particularly if it is nesting <% { %> <% } %> and html.
Resulting state needs to be encapsulated into JSP/JSTL-friendly recipients
What sort of conversion is necessary?
How much of it? I normally find that the bean hierarchies I define are very open to being accessed by JSTL / EL.
On the whole it sounds like you're doing ok.
I would probably have been against inventing the wheel (again). I would recommend taking a look at Struts for instance, and see how they solved the similar issues, or if they explain why they followed the certain patterns.
Cheers,
evnafets
Why would you go through a central controller
servlet to access a page that
does not depend on any application logic?
For consistency.
You have a central point of entry that you can
control
If you DO need to change this page and make it more
complex at some point, so that it DOES depend on
application logic, it is already in the standard
form.
OK, let's say my front controller is Controller.
I map *.do to Controller.
I have a display_user_record.jsp page and a login.jsp page.
The link for the display_user_record.jsp page is something like "PrepareUserRecord.do".
"PrepareUserRecord" is the command class that handles that request. display_user_record.jsp is the resulting view.
That looks nice and work well because displaying that page requires fetching data from a database and some other logic.
For the login.jsp page, which requires no application logic, what would the link be like? What would would happen in the controller?
Clearly, no matter what happens, accessing login.jsp directly would achieve the same effect.
Well, I kind of agree with all that, but what
JSP/JSTL offer in exchange just
doesn't seem any better to me.
I disagree with this statement, particularly if you
have to mix a for loop in code, with a table.
Particularly if it is nesting <% { %> <% } %> and
html.
Well, in many cases, you end up with things that look like this:
<exec:iterator condition=?lt;%= user.isActive() %>?gt;
It's barely better than Java code.
Add in page directives, directives accessed using the <jsp:directive tag, declarations, expression, EL expressions, an occasional scriptlet, implicit objects, JSTL tags from 2 or 3 different namespaces, standard JSP tags, EL functions, some custom tags...and you end up with something really scary...for a Web designer and a developer.
<div class="jive-quote">
Resulting state needs to be encapsulated into
JSP/JSTL-friendly recipients
What sort of conversion is necessary?
How much of it? I normally find that the bean
hierarchies I define are very open to being accessed
by JSTL / EL.
Well, my library classes are heavy, they contain a lot of processing logic that has no place in the presentation layer. Also, they are almost never beans.
So, I have this whole range of JavaBean classes whose sole purpose is to contain the state of library classes that is necessary and sufficient to my views.
Every time I extract data from my library objects to populate those JavaBean objects, I have the feeling of doing something very inefficient: Creating short-lived host objects for the sole purpose of making the data accessible by the presentation layer soup of tags and EL.
I guess I am looking for an elegant solution and it always end up very messy.
I wish there were a good book or reference on that topic.
Installing 30MB of bytecode just for a MVC framework is crazy as far as I am concerned.
