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.
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.
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
