Taken a while to get back to this...
but more comments below:
"Craig R. McClanahan" wrote:
>
> See below for inserted comments.
>
<dispatch and other details snipped>
>
> That is a good description of the way I use actions. They primarily adapt from the
> HTTP-centric view of the data (requests with parameters) to the JavaBeans-centric
>view
> of the data used by the rest of my application logic.
Which would allow the replacement of http-centric requests with those
for WAP, or interactive tv, or SMS ? or some sort of weird email
dispatcher.
I've no idea what protocol some of those take, but the point is made :)
(Especially if I can play with a Dreamcast or Playstation 11 - purely in
the sake of R & D at work of course...)
<snip>
> > have stateful business objects, like "Customer", "Order" etc (and why do
> > we _always_ use Customer and Order as the examples... ;),
>
> That is the curse of e-commerce systems ... everyone knows what they are :-)
>
> 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.
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.
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.
Any thoughts on this?
> 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).
<snip>
>
> Great minds think alike! :-)
Or fools seldom differ.... nah, lets go with "great minds"... ;)
<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 :)
>
> 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?
===========================================================================
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
