It would be quite lengthy to answer all items, so I'll respond to the questions in turn. 1. That's essentially how it works. When the chain ends you no longer forward, and this is effectively a return to the caller. I have seen two variations of this implementation approach: One that always forwards the message on to the next in the chain, and one that allows each handler determine whether or not the message should be forwarded. I prefer the former approach in most cases, but I've seen arguments for both.
2. I'm not quite certain what you mean by Decorating a Front Controller. In what manner are you attempting to decorate a Front Controller? Please ignore my request for clarification if others know to what you are referring. If I understand your request correctly you would be employing something analogous to the Intercepting Filter pattern you linked to implement a Front Controller. This would facilitate an ability to apply logic to user requests in an extensible manner before forwarding the request onto the handler. I've implemented this on many occasions when I have a complex array of preconditions that must be met by the user before they are forwarded to the appropriate handler. The Front Controller gives you a consistent manner by which you forward the user, apply conditions to their request, etc. The Intercepting Filter would provide the means to extensibly create and apply this logic in the Front Controller. The result in both cases would be centralization of logic, drastic decrease in potential code duplication, etc. 3. It depends on what you mean by "responsible." In the context of a web application they are responsible in that their HTTP GET/POST request contains the information necessary to enter the Front Controller and process all the filters on their request. I would say that the client generally has the responsibility of either having a context or a means by which you as the controller can identify the context. Hope that makes sense. A discussion like this would be better suited for a white-board with interactive conversation.... Regards, Chad On Apr 12, 2005 11:33 AM, Bill Bassler <[EMAIL PROTECTED]> wrote: > > I've posted a less focused form of this question before. Based on the > responses I got a lot of ideas which opened up things to new and hopefully > more refined questions. > > To recap. I'm trying to determine the most appropriate design pattern(s) > to > implement a solution to the following problems. > > 1. When applicable, determine filter chaining configuration based on some > message content. Where possible determine filter chaining based on a set > of > business rules. > > 2 .Define a set of specific xml message processors for requests for both > document inputs and outputs. > > 3. The processors support a common message I/O interface that can allow > processor chaining. > > 4. To chain message processors in a flexible/configurable way. > > 5. Some processing chains result in a final submission to another > processor > that doesn't easily support the interface defined in 3. Some do not. > > Based on the suggestions a think some form of Content based router along > with an Interception Filter pattern is pretty close to a fit. > > See Figure 7.1 represents the Intercepting Filter > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter > . > html > > Questions/implementation Confusions: > > 1. Does the message processed through the chain always have to be > forwarded > to a "Target" in these patterns or can the final process just be a > converted message that's returned to the caller without a Target? > > 2. Does the Decorator around a front controller variation have > advantages/disadvsantages over the filter chain variation? The filterChain > looks more easily configurable from an xml file i.e. deployment descriptor > file. See link below. > > 3. Should the client always be responsible for supplying the processing > context within a request or is it O.K. to apply this on a request by > request basis. Does this fit? > > e.g. > > For input requests: When looking at your input data message I see that > you're customer type "A" so I'll process your message through filters A & > C > then send the transformed message to a target to complete message > processing. > > For output requests: When I'm looking at your request for data message I > look up in my data tables and I see that you'r customer type "B" so I'll > retrieve your data process you data message through filters A & C and just > return the document back to you. > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
