Mark Minnoye wrote:
>
> Trying to use as less servlets as possible i'm experementing with the
> folowing:
> The formValues are posted to my Jsp-page.
> JSP-page:
> <USEBEAN NAME="myBean" ...>
> <SETFROMREQUEST="*">
> </USEBEAN>
> <% myBean.update() %> //i also have myBean.insert() & myBean.select()
>
> then myBean checks the values and make -or doesn't- the processing/changes
> to the DBase.
> I'm trying this model in order to keep as much logic at the same place
> (bean), and *not* to have a bunch of servlet each with one task.
>
> I don't know how others feel about this approach, any remarks?
>
Reducing the number of servlets has not been a high priority of mine. However,
I tend to keep all the logical processing related to a particular business
object (such as a customer) together in one servlet, and use either a "command"
parameter or extra path information to select which one to execute.
In fact, the actual code for these action procedures (your "update()" and
"insert()" and so on) is not embedded in the servlet code in my example.
Instead, I defined an interface called Action that includes a method called
execute() which accepts the servlet request and response. Each action
procedure is a separate object that can be individually updated.
In the servlet initialization parameters, I give it a list of command words and
the corresponding classes to create. The first time a particular command word
is used, a new object of the appropriate class is dynamically instantiated
(similar in spirit to how the servlet engine creates an instance of your
servlet the very first time you execute it). This design has proven to be very
extensible, and lets me add new action procedures, or modify existing ones,
with minimal impact on existing code. I see a few other benefits:
* Code of each individual command module is
extremely simple and focused, instead of being
buried in a huge servlet class file.
* Enforced separation prevents me from being
tempted to "cheat" by passing information through
servlet instance variables (and therefore messing
up my multi-thread safety).
* I can change how the command procedures actually
work without requiring any changes at all to the JSP
pages. For example, the logic of these action commands
could easily be moved to an RMI server, or even become
a stateless EJB, with very small amounts of code change.
One other feature of using a "real" servlet over the embedded nature is the
fact that a "real" servlet can choose the next page to display, and you can't
do this using the approach you've suggested. For example, you've (correctly)
included the requirement to validate the parameters before you perform the
update. That's fine, but what should happen next? In my designs, I've adopted
this approach:
* If the validation checks fail, go back to the page
that the user just filled out, adding an error message
explaining what the problem is. The form fields are
filled out exactly as the user did them, because they
are initialized from the bean properties.
* If the validation succeeds, do the update and then
go on to the application menu, or whatever the
appropriate next page is.
How do you deal with this kind of scenario if your update() method is embedded
in the bean?
> When you make use of the model adviced by Craig McClanahan (model 2),
> wouldn't it be usefull to let your bean extend the HttpServlet so you could
> have just one bean that can do the processing required by caling it using
> "http//server/servlets/myBean?command='insert' " and try to keep all
> possible procedures in that one bean.?
>
The only problem I see in making the bean extend HttpServlet (and therefore
using it both as a bean and a pure servlet) is the confusion of understanding
the flow of control. When you write the code, you have to be aware of the very
different ways it will be used. It seems cleaner to me to separate the
functions that can be invoked from a client directly (as servlets) and the
functions that can be invoked from a JSP page (as beans), using session
variables to communicate between them.
When I was first learning object oriented programming (coming out of a C
background), I used the style you suggest -- large "library" type modules that
combined multiple functions, because that is the approach I had grown up with.
I've found that dividing things into smaller pieces creates much more flexible
and maintainable code, because it minimizes the amount of other code that is
affected by changes.
>
> Mark
>
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
