Jari Worsley wrote:
>
> >
> > For validation, it works the way I described in my previous response -- the
> > CustomerBean includes a validate method that returns either an error message
>string, or
> > a null (if everything works right).
>
> I have a problem with the validation the way its described. It seams to
> be more complicated than
> just having a "validate" method on a CustomerBean. (a "punter" bean
> maybe ? ;) As was pointed out in another
> message in this thread, the Customer is potentially a "heavyweight"
> object. Also, by putting validation
> logic into the customer, then potentially the customer bean needs to
> "know" about the UI, which is a _bad_ thing.
>
Customer is often a "heavyweight" object, but might not be. CustomerBean is not -- it
is
sort of an adapter layer on top of the persistence layers. In particular, I would
never use
an EJB as a CustomerBean, because of the potential overhead of all the remote calls.
Perhaps a better way to think of CustomerBean is the server-side representation of the
contents of an input form, which (in the servlet/JSP case) might be spread across
multiple
HTML pages because of its complexity. You've got to cache the answers that are being
accumulated somewhere, and it made sense to me that there be a single bean for this
purpose.
Where to put validation is always an issue. Doing validate() the way I describe is a
compromise, and is discussed further below.
>
> For example - if you wanted to use 3 drop down boxes to make up a "date
> control" on a form (for ease of use and a sanity check
> on the returned values - i.e. no "aldadxfla" :), then you need some way
> of joining up the 3 values to make one date.
> This seems like generic code that has no place in a "customer" business
> object, but is more analagous to the sort
> of visual controls that Delphi or Swing give you. I can see merit in
> writing encapsulations like the date example,
> and others for numbers, currency etc, to come up with a set of
> "controls" to aid in building and validating a UI. Of course they
> can only perform a "sanity check" on the value, so that you know when
> you get a date from a control it will be valid,
> or when you get a currency or number object it is at least in the range
> you expected.
>
> So I can see two ways of doing this
> 1. Have a set of server generated "UI controls" (any idea for a better
> name?), that can perform sanity
> checking of values, and combine multiple fields on a form to generate
> one value. Use these to do a
> "pre-validate" of form values, and aggregation of results from multiple
> fields to build things like
> Date objects. Then pass these values to the "Customer" (can't we use
> "punter") object for the
> business level validation.
>
Such tools could easily be utilized inside the validation functions of a CustomerBean
type
thing.
>
> 2. Write business object specific view validation classes, like
> "CustomerView Bean", to deal with the issues
> brought up above, like dealing with multiple input fields to a single
> value, and potentially range checking.
Every "real life" case I have run into has been more like this -- there are
business-object
specific validations that need to be performed. Format validation stuff is really the
trivially simple case (and can be done with utility classes because it's common). But
an
OrderBean check that the delivery date has to be after the order creation date (if
that is
one of your business rules) is going to be businses object specific, no matter where
you put
it.
>
> Any thoughts on this?
Let's look at the "transaction lifecycle" of an update transaction that requires
multiple
input form pages, using the approach I suggest:
* User navigates through the various
pages of forms for this tranaction,
filling out things as they go.
* Each time they navigate to a particular
page (either directly or because a validation
error sent them there), the most recently
entered values for that page are displayed.
This matches user expectations about how
interactive programs should work.
* As each page is submitted, the input
fields are cached in the corresponding
bean, in the user's session. Simple
format-based validations (like valid
dates) can be applied here, but you cannot
necessarily check everything.
* When the user finally presses "Save"
(or whatever), the validate() method is
called. Any failure in passing the business
rules causes an appropriate error message
to be returned.
* When all the rules pass, then and only then
does the CustomerBean object interact with
the persistence layer below it (to update the
database or whatever).
Note a couple implications of this approach:
* Detecting errors is one thing -- saying something
meaningful to the user is quite another. It seemed
to me that accumulating an error message in the logic
that is detecting it (the validate() method) was the
easiest way to handle this, but it's not necessarily
optimum.
* There are no interactions with the underlying database
until the save() method is called, unless validate() needs
to do some lookups ("does the customer id specified
in this order exist?"). This should improve scalability
and performance, especially if the persistence layer is
something accessed across the network like EJB entity
beans.
* Like any database update application, you need to deal
with the possibility that someone else has updated your
persistence layer information during the process of
accepting user input. The same techniques you would use
in a client-server app are applicable here (detect and
abort, detect and report, detect and report and try to
resolve discrepancies, etc.)
>
> > Now that servlet 2.2 is out and becoming available, I will happily start using
> > container-managed security and never have to worry about this stuff ever again.
>At the
> > moment, the integration between the servlet container and your authentication
>database
> > is specific to each container vendor, but it's not too tough to centralize these
> > dependencies into a single class.
>
> Hmmm, back to the specs documents for me again I think... (to check on
> the container
> capabilities).
>
Yep -- this is really going to reduce the burden on web app developers, if they will
only
take the time to understand its power.
Now, it would be neat if we could standardize an interface between a servlet container
and
the underlying security realm. Hmm, there just happens to be an interface in the
"Catalina"
proposal (on the Jakarta Tomcat source tree) that does just that ....
>
> <snip>
> >
> > Great minds think alike! :-)
>
> Or fools seldom differ.... nah, lets go with "great minds"... ;)
>
I agree! :-)
>
> <snip>
> > > allows the protect action to run. This "chain" could be extended to
> > > include things like site logging, or user tracking etc. What I can't
> > > decide is if this behaviour belongs in the "Actions" or whether at a
> > > more business focused level (or everywhere).
> > >
> > > So should actions be chainable?
> > > More thoughts on chaining? and action granularity?
> > >
> >
> > I've written a lot of applications over the years, and have never really found much
> > value in "chaining" as you describe at the application level. I prefer to keep my
> > application layer functionality as simple as possible (although you could say that
>my
> > use of the controller servlet to implement authentication checking is sort of
>chaining
> > in the sense you describe).
>
> Although you could make a case for things like authentication, logging
> and other tasks
> being at an "architecture" level rather than application. I've got no
> strong opinions here
> really - write it and see how it goes for some of these things (as long
> as the main bits a good
> bean, then you're onto a good start :)
>
The difference isn't how you write it, it's whether you have to write it at all. If
you use
container level support for authentication and access control, here's a partial list
of what
you get to stop coding:
* User login screens (although you can create one
for form-based authentication if you want).
* Checking for a valid user on every single request.
* Figuring out what a particular user is allowed to do,
based on the data you have in your persistent user
database.
* Checking whether a particular logged in user is
allowed to access the page he/she requested.
It's a very different viewpoint. Using container-managed security, all of the above is
dealt with in the web application deployment descriptor.
In certain cases, you might want to do role-based things within a page (like show a
"Manager" and a "User" different sets of fields on the same page. You can do that as
well
-- by calling request.isUserInRole("Manager") -- but that will tend to be the exception
instead of the rule.
>
> >
> > However, at the server level (I'm currently authoring a proposal for the insides
>of the
> > Tomcat servlet engine in the Jakarta project -- http://jjakarta.apache.org), the
> > ability to add layers of request processing functionality is very valuable. For
>
> Not quite off topic, but do you know of any interest groups devoted to
> architecture and the web?
Not really. SERVLET-INTEREST and JSP-INTEREST have had lots of discussions along this
path,
and I imagine the EJB and J2EE related lists probably would as well. The "design
patterns"
world is sort of expanding to cover architectural designs, but I haven't looked much.
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
