If the list of extension grows (Tiles, Worklfow Extension, Expresso, ...) the number grows exponentially. You need to implement a class for each possible combination of extensions:
1. your extension alone 2. your extension + tiles 3. your extension + workflow 4. your extension + tiles + workflow 5. your extension + expresso 6. your extension + expresso + tiles 7. your extension + expresso + workflow 8. your extension + expresso + tiles + workflow
You need to make a decision in your app about what technologies you will use. When you add a technology you will modify the processor accordingly. You don't need a class for every combination, just one for the combination being used in your app.
David
...
I agree, that a filter-like approach will not the the right way. I am just wondering whether work can be reduced by making composition more configurable. I think it is necessary to split up the request processor into mulitple classes (one that generates the action instance, one that instantiates the form, ...). Then parts of it can be replaced more selectively. That's what Jeff Robertson is talking about and it sounds good to me.
Thus, by now I believe the request processor architecture should be changed more fundamentally to allow a more selective change of functionality. Maybe they should be working more like servlet filters, so they can be chained?
I'm against mimicing Filters because that's the container's job. If we want Filter behavior then we should design the RequestProcessor as a set of Filters.
--- Matthias
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
