Hey!
Am I wrong in thinking that Generic Java would solve your problem?
I have not used this model yet. So I can't say from experience.
But from what I've read, it is completely compatible with Java.
It uses Java collection library and elimnates errors from type casting.
I believe some guys at Sun and Philip Wadler invented GJ.
Sans adieu,
Danny Rubis
Drew Cox wrote:
> The construction of our Servlet/JSP web application continues and I have
> found myself facing another implementation design decision for which I would
> greatly appreciate the benefit of other's experiece.
>
> <background-info>
>
> As discussed previously on this list, the app implements the single-servlet
> event delegation model (is there a recognised name for this?) for
> partitioning the application functionality. In this scenario the request
> URI (eg. /controller/login) specifies a particular "web action" (eg. login),
> which is mapped to a named action class (barrack.action.LoginAction) using a
> properties file loaded at application startup.
>
> All the action classes implement a WebAction interface which defines a
> perform(req, resp) method. This method does the actual work of processing
> the action, populates the required display beans, stores them in the Request
> scope and finally forwards to a JSP to render the display. The single
> controlling servlet simply manages the process of dispatching the request to
> the appropriate action class.
>
> This infrastructure is working now and appears to be very worthwhile. We
> can add functionality to the app (or build completely new apps) without
> touching any of this infrastructure. I can let the less experience
> developers loose on a web action class stub and a spec and they don't have
> to touch (ie. break) any of the "already-working" bits. Viva development
> partitioning!
>
> </background-info>
>
> So, on to the question (I think I will have to keep a copy of that for all
> my further queries...:-)
>
> The action class perform( ) method actually needs access to additional
> resources beyond the HttpServletRequest and HttpServletResponse shown in the
> simplified example above. In our case most need acces to the custom
> application logging service, security manager and database connection pool,
> all of which are stored in the application scope. This sort of requirement
> must be common for others out there implementing this model?
>
> Currently I am just having the controlling servlet extract references to
> these beans from the application scope and passing them as parameters to the
> action class perform( ) method.
>
> However, in the Sep 99 JavaWorld acticle on the above model, they
> recommended bundling these sorts of additional parameters into a "services"
> array of Objects, to pass them as a single parameter to the perform( )
> method. I can see some benefits to this, for example, you can readily add
> new services to this array without changing the WebAction interface and
> breaking all your existing implementing classes. However, I don't like the
> idea of hiding the identity of these service classes as positions in an
> array of Objects, then getting run-time ClassCastExceptions when I (or more
> likely one of the other developers ;-) get the positions wrong.
>
> I have also seen a slight derivation where the services are bundled into a
> Hashtable and passed to the perform( ) method. As I see it, you might as
> well just pass a reference to the ServletContext and let the action class
> extract the services themselves.
>
> So, if your still following (and awake), how do people handle this
> requirement. Should I just "keep it simple stupid" and stop thinking about
> it too much?
>
> Much appreciated,
>
> Drew Cox
> Barrack Consulting
>
> ___________________________________________________________________________
> 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
___________________________________________________________________________
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
