Use dynamic class loading to your advantage. Create an interface
representing processing of a request--containing the method you
need to call. Create several implementations of it, one for each
way of processing.

Then create a "reactor" which loads and dispatches these handlers.
ie: You supply a key to the reactor (from your form var) and it looks
up the right handler for you--possibly out of a hashtable, or by
searching a directory, or, easiest, by calling Class.forName().

Next either you or the reactor call the method on the returned
implementation.

The other way WebMacro does it may also be suitable for you:

Declare a superclass servlet which does the generic processing for
you and then calls an abstract method. Make one subclass of this
for each different mechanism.

WebMacro manages some static data in the abstract superclass so
that database connections and other expensive resources can be
shared between connections and servlets. Thus is a bit tricky,
because you must carefully reference count the statc data and
clean it up when the last subclass instance is destroyed. Do this
by incrementing a count on init() and decrementing on destroy().

WebMacro is free, so you can download it and look at the code for
more details.

Look at the Reactor.java and WMServlet.java classes, and things
related to them.

WebMacro is at:

  http://www.webmacro.org/Download.html

Justin

Quoting Lewis, Grant ([EMAIL PROTECTED]):
> I currently have a servlet that handles several different HTML forms from
> its doPost method.
> Currently, I check a hidden form element to determine which form was just
> posted then I call
> one of a number of private methods on the servlet to process the form.
>
> This is working fine, but there is the possibility I may need to add
> additional form processing
> and I don't want to continue adding additional methods every time a new form
> is added.
> The servlet in question is acting as the controller of a HTML wizard used to
> build a fairly
> complex Javabean used in the application.
>
> Any design ideas on effective ways to decouple the controller from the form
> processing would be
> appreciated? I have a couple of ideas myself, but I'd like to hear what
> others have to say on the
> subject.
>
> Grant
>
> ___________________________________________________________________________
> 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

Reply via email to