 |
My suggestion for Servlet 3.0
Posted by felipeal on June 25, 2007 at 09:52 AM | Comments (6)
I have taught Java and web-tier (Servlets/JSP/taglibs) development to about 10 classes over the last 3 years. And everytime I teach servlet attributes, I face the same situation: first I explain what request attributes are, why they are useful, and which methods you use to manipulate them. Then, when I teach session, I have to explain that it has a similar concept, with the exact same methods. And when I get to the ServletContext topic - well, you got the picture...
Now, to make things worse, the Servlet API is taught a couple of weeks after the OO concepts, like interface. It's already hard to explain interfaces for people coming from non-OO backgrounds (you have to explain many concepts and analogies, like 'interfaces are contracts', 'an interface defines methods signatures that classes must implement', and so on...), and when they are finally understanding it, they face a situation where an interface would make sense, but it's not used.
So, putting A and B together, there should be an interface defining an object that handles user attributes, and both ServletRequest, HttpSession, ServletContext, and PageContext (from JSP) would implement it. Something like AttributeContainer (which is a bad name as container has zillions other meanings on Java EE), AttributeHolder, AttributeStore, etc (I honestly cannot think about a nice name for it).
This is a very simple change, as the classes already have the methods - it's just a matter of "making the contract official" by defining such interface. In fact, it's so simple that I believe the previous EG didn't think it would worth the effort (I had suggested it before, I believe in the 2.5 timframe) - they might think it doesn't bring enough value.
But I can guarantee it would help in at least 3 scenarios:
- Teaching attributes on Servlet courses
- Teaching interfaces (once you reach the attributes class, this is a good example of interface use)
- Provide an easy (although not necessarily more efficient) way to write code that store attribute in many different scopes (like JSTL set tag):
public void set( String var, String scope, Object value ) {
AttributeHolder holder = attHolders.getHolder( scope );
if ( holder == null ) {
throw new BlaBlaException( "invalid scope: " + scope );
}
holder.setAttribute( var, value );
}
I know the EG has more serious issues to handle, but this is a minor one, which would not hurt anyone. Besides, this is a new major spec release (3.0), so that's a good time to include some change (it could even deprecate the method that return the attribute names in an Enumeration, and provide an additional method that uses a Set, for instance).
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
That would also be a good opportunity to clean up any minor inconsistencies between the multiple definitions of the attribute-related methods.
Like the way HttpSession's removeAttribute explicitly states that it does nothing if there's no existing attribute for the specified name, but the ServletContext and ServletRequest removeAttribute methods don't say anything about this (do nothing? illegal?).
Or how ServletContext says names beginning "java.*, javax.*, and sun.*." are reserved names, but ServletRequest says its "java.*, javax.*, and com.sun.*" - whilst HttpSession doesn't mention this at all (not that any of it says what being "reserved" actually means anyway - can/can't you do for those names? read them? change their values?... and where you shouldn't, are calls ignored? illegal? etc etc).
But more generally, why not use a separate collection or object to contain the attributes? Then instead of ServletContext, ServletRequest etc each having several particular methods giving very limited ways of accessing the attributes, they'd just need a single getter for their set of attributes, and it could support all the usual "collection" facilities.
At its simplest, even something like "Map getAttributes()" might be sufficient - though in practice I suspect it would need a dedicated "Attributes" class so as to cater for listeners and any other specific requirements. You could still have your AttributeHolder/AttributeStore interface, but it'd be down to a single "getAttributes" method. I guess the existing methods would need to be retained, ideally deprecated but that might be controversial, but could be re-defined in terms of operations on the "Attributes" instance.
One could probably make similar arguments for "init parameters" on FilterConfig, ServletConfig and ServletContext. And there's also maybe a more general commonality between FilterConfig and ServletConfig that suggests a common "Config" concept.
Boy, once you start...
Posted by: mkaufman on June 25, 2007 at 06:29 PM
-
Sorry about the preceding splurge, I hit "post" when I meant to "preview" it, and it also lost all the formatting...
The "Map getAttributes" was, of course, meant to be generic with String and Object - let's try it again:
Map<String, Object> getAttributes()
Mike
Posted by: mkaufman on June 25, 2007 at 06:37 PM
-
Interfaces yes ++
Generics no --
KISS FTW
Posted by: rickcarson on June 26, 2007 at 04:33 PM
-
If I were to teach server-side web programming to students who struggle with OO concepts, I wouldn't teach servlets. That seems an awfully low-level concept. Why not start with a higher level web framework?
Posted by: cayhorstmann on June 26, 2007 at 04:45 PM
-
How about calling the interface 'Attributed'?
Posted by: bgoggin on June 26, 2007 at 05:53 PM
-
"Teaching interfaces (once you reach the attributes class, this is a good example of interface use) " Should be taught before the student ever sees a servlet...
"If I were to teach server-side web programming to students who struggle with OO concepts, I wouldn't teach servlets. That seems an awfully low-level concept. Why not start with a higher level web framework? " I'd send them back to that OO concepts course.
Posted by: jwenting on June 27, 2007 at 12:39 AM
|
java.net RSS Feeds
