Quoting Vic Cekvenich <[EMAIL PROTECTED]>:
>
>
> Craig R. McClanahan wrote:
>
> >
> > One of the things people have said they liked about using a chain to
> decompose
> > RequestProcessor is that you could easily compose your own chains, adding
> your
> > own custom processing stages and so on. You can do exactly the same thing
> with
> > Filters by making each processXxx method its own filter, and using (say)
> the
> > request attributes to play the role of the Context object in
> commons-chain.
> >
> > Filters have an additional capability if you're building a
> servlet-specific
> > framework -- they can wrap the actual request and response objects that
> are
> > passed on to the next filter in the chain, so you can implement some
> > interesting things not directly possible with a chain based implementation
> --
> > such as caching or on-the-fly compression of the response.
> >
> >
> >
> > Craig
>
> I do not get chains, but Hookom posted this link:
>
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
>
> which I sort of get (sort of) and it's my favoirte chain impl.
>
InterceptingFilter (as presented in the Core J2EE Patterns book) is very similar
to the way standard filters work in Servlet 2.3 (and 2.4). The primary
difference from the way commons-chain works from the presented "Custom Filter
Strategy" is that a Filter cannot say "I have completed the response -- no need
to do anything more", which is exactly what you'd want for things like a "check
that the user has logged in" mechanism.
Doing chains the way that servlet filters do it (each filter explicitly calls
the next in the chain) would eliminate that problem, but has two potential
disadvantages:
* Somebody has to deal with the complexity of falling off the
end of the filter chain (i.e. a FilterManager or something)
* You end up with a stack frame per Filter (if you've ever wondered
why Tomcat's stack traces are so long, it's because the Valve
architecture inside Catalina follows this same design pattern).
> So if we can use filters or other chain, somone clever could write an
> "chainRequestProcessor" *interface*, that could be impledented for
> JSP2.0 filter... and then somone else could later write a JSP 1.2
> version, even non filter versions.
>
> ?
>
> So I like chain as interface, and action as interface.
>
In commons-chain, the Context, Command, and Chain APIs are all interfaces. You
can use one of the provided implementations and roll your own.
> I am thinking of fliping sides on FormBean as interface, I am now
> leaning against formbeans being an interface. FormBean is a concept
> (properties that map to form elements), plus this idea of XML as a
> FormBean. It could be a List or String or anything. As long as it itself
> does not do DAO, and it maps to a form, good. (but do have way to unit
> test it w/o a container)
> For starters so the JSTL x: tag can be used instead of c:out, plus some
> Stxx things.
> (Then maybe a way to make HTML tag submit XML Doc, multi row and all).
>
> .V
>
There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a "form bean" in the
conceptual sense:
(1) A set of typesafe field names and corersponding values
where the application doesn't have to worry about maintaining
values across requests.
- Variation: dynamically add and remove fields as needed
- Variation: allow non-typesafe fields
- Variation: allow fields that can have multiple values (arrays)
- Variation: represent data hierarchically instead of just
a name-value map (bean properties, nested expressions,
XML DOM, what have you)
(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation: hard coded logic for validations (i.e. the original
validate() method in Struts ActionForms.
- Variation: pointer to a configured set of validation rules
that is abstracted from presentation considerations.
(3) All of the above plus event handlers for UI events that change
the state of the field values -- perhaps in the same bean,
perhaps somewhere else.
A type (1) or type (2) form bean is really better thought of as an abstract way
to pass the input data for some sort of business transaction between tiers, or
within tiers. A type (3) form bean would definitely live in the presentation
tier, and not be used between them. For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only. Transaction Bean? Input Bean? Data
Transfer Object :-)?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
