Here is a snip moved from the parent page when ideas about a "single interface" approach were split off to this page.

We're looking for a name for the interface class. RequestProcessor is taken by the existing class and won't be replaced for backwards compatibility. "IRequestProcessor" or "RequestProcessorInterface" are not popular because there is no precedent for that naming style among other interfaces in Struts (or maybe David G has some other reason he doesn't like them!) RequestHandler was suggested on the list, but I'm not too keen on that personally. I think something to do with "Lifecycle" might work out. "LifecycleProcessor"? I'm not sure about that.

Perhaps "RequestDelegator" (which somewhat describes more of its implementation than it's absolute semantics). "RequestHandler" was suggested, which is more generic, but may be used somewhere else? I guess I'm a little concerned that the composability is not quite being manifested properly; something like "stackable" delegates ala filters might be a better concept. Hmmm... how about "ComposableRequestProcessor"? Very descriptive, not likely to collide, and yet evocative of the original.

Matthias Bauer provided an accounting of his shift from leaning towards the RequestProcessor/Composable model to the single-interface model in http://marc.theaimsgroup.com/?l=struts-dev&m=105471661016727&w=2 and offered this diagram:

http://www.livinglogic.de/Struts/requestProcessor.gif

See also RequestProcessor/Composable

  • No labels