Doctor it hurts when I do that Then don't do that!
A lot of places in the Struts framework, simple inheritance is used. Some places because it's the simplest thing that might possibly work, other places to avoid unwanted flexibility (ActionForm). When the simple solution is starting to feel awkward or even hurt, it might be time to consider a more complex, but more flexible solution, often by using some sort of composition/delegation (like splitting up the ActionServlet), since we have chosen to use a language without multiple inheritance. There seem to be a consensus, that the RequestProcessor is indeed an improvement over the old ActionServlet, but it's starting to hurt. Most people also seem to agree that some sort of composition is the next logical step. A lot of people seem to disagree about HOW to implement decomposition best. The most obvious solution seem to be an interface for each of the 16 (??) methods and someway to configure which implementations to use where. It might be possible though to keep the solution a bit simpler by grouping some of the methods in the same interfaces, methods that are seldom overwritten, or methods that tend to be overwritten together, or methods with tight cooperation. This would be a step forward in flexibility, but with a small increase in complexity. One danger with this solution is, that some of the methods tend to depend on each other, and thus the aforementioned solution might contain too many degrees of freedom. But maybe it's just FUD. Ted pointed out the similarity between the Validator and a composable RequestProcessor. It could be a way to restrict the freedom by defining some sort of dependencies between the processing methods (both by somehow defining a lifecycle, and by somehow defining dependencies between implementations. It might be unneccesary, it might be too complex, it might not be the best solution, and it might not even work! The question is: The validator and a composable RequestProcessor have some similarities conceptually. Are these so big, that they should result in similarities in the implementation, or would that be a bad idea? But I guess this is just speculating about hte future. Maybe the best solution is to create a simple composable RequestProcessor for 1.2 and then see what the future might bring? - Kent Ted Husted <[EMAIL PROTECTED]> wrote: > Jeff Robertson wrote: > > Wow. Mr. Husted, this may seem like an obvious conclusion > to you, but to me > > (and probably others as well) this is a big "hey, why > didn't I think of > > that!" moment. > > I know the feeling -- I just got it reading the latest docs > for the > Struts Workflow extension =:0) > > IMHO, Matthais is pointing out a very real issue with the > current > architecture. It's moving in the right direction, but > doesn't go far > enough. In order to bring out extensions like Workflow, he > has to do a > special Tiles version. People really shouldn't have to do > that, and the > implication is either the Tiles or RequestProcessor > implementations are > falling short of the mark. > > I don't know when a version of Struts based on Filters will > be > available. But I do know that if someone came up with a > implementation > of a composable RequestProcessor that worked like the > Validator, I'd > probably commit it. > > One day, this work all may be obviated by Filters, but until > then, it > would be a good way to see how Filters might be used in > Struts 2.0. > > I also think that given the codebase for the Validator and > the existing > RequestProcessor, it's not that much of a stretch. If we > define the > interface right, we should be able to keep the original > RequestProcessor, so the whole composible thing becomes a > bleeding-edge > option, and not a required implementation. > > -Ted. > > > > > ------------------------------------------------------------ > --------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
