Craig,
"Craig R. McClanahan" wrote:
> Hi Dan, see intermixed ...
>
> On Fri, 16 Mar 2001, Dan Malks wrote:
>
> > Jorge,
> > Just catching up some email.
> >
> > Jorge Ribeiro Jordão wrote:
> >
> > > Has anybody read Sun Java Center J2EE Patterns
> > > (http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/)
> > > yet ?
> > >
> > > For those that did, it seemed that Struts is pretty much an implementation
> > > of the "Front Controller" pattern (no surprises so far), using the
> > > "ServletFront", "Command and Controller", "Multiplexed Resource Mapping" and
> > > "Dispatcher in Controller" stategies.
> >
> > You've done an excellent job of understanding this pattern and describing the
> > aspects of Struts it describes!
> >
> > The one minor clarification is about the 'Dispatcher in Controller' strategy.
> > While I'm not a Struts expert, I believe that Struts uses a separate mapping
> > mechanism that sits outside of the controller servlet, does it not?
> >
>
> Well, I hope that I qualify as a Struts expert :-)
>
> Struts relies on the servlet container's mapping rules to ensure that all
> interesting requests are mapped to the controller -- either by path
> mapping ("/execute/*") or by extension mapping ("*.do"). Then, it strips
> out the "*" part of the path to look up an internal <Action> that tells
> the controller what code to execute.
>
> > If the controller is delegating to an external component in order to do view
> > mgmt (ie:choosing the view) and navigation (ie:actually dispatching to that
> > view) then I probably wouldn't describe it as using the 'Dispatcher in
> > Controller' strategy. This strategy is meant to describe more simplistic cases
> > where the controller inlines the work itself, for example if it just grabs a
> > string and a requestDispatcher instance and forwards things on their way.
> >
>
> Interesting timing ... I just added exactly that feature over the last few
> days.
>
> When defining an <Action>, you know have three choices for how to specify
> what functional code gets executed:
> * "type" - The Java class name of an Action class (the original pattern)
> * "forward" - The context-relative path of a webapp resource to which
> control is directed via RequestDispatcher.forward().
> * "include" - The context-relative path of a webapp resource to which
> control is directed via RequestDispatcher.include().
Right. That indeed sounds like the 'Dispatcher in Controller' strategy.
>
>
> The latter two resulted from cases where I wanted to integrate some
> functionality that was already built on servlets, but take advantage of
> the controller's support for form beans. Now you can do this quite
> easily, without having to write a two-line Action that does it for you.
Makes sense.
>
>
> > See the 'solution' section of the 'Service to Worker' pattern for a bit more
> > discussion on this issue. 'Service to Worker' is a pattern that combines a
> > couple other "smaller" patterns in the catalog into a larger one.
> >
> > Let me know if I got anything wrong wrt to the discussion of Struts in this
> > email :-)
> > I'm interested in any other comments on this issue (or others related to any of
> > the Pattern material in the above URL - pls feel free to email the provided
> > aliases, if you'd like to discuss outside of this list).
> >
>
> I must confess I haven't had time to study the patterns docs in detail,
> but I will (I've got three sessions at ApacheCon in a couple of weeks, and
> am just finishing up the last one :-).
I understand and welcome your feedback once you've had a chance to have a look.
Jorge's initial comment is interesting, given the fact that as Ralph Johnson, Doug
Schmidt, and Mohamed Fayad state in 'Building Application Frameworks', Wiley 1999
"Patterns are the architectural elements of frameworks.". I agree with this
sentiment, and it is good to see this relationship between the Struts Framework and
the J2EE Patterns catalog.
In fact, I've gotten some emails recently asking me to write a paper about the
relationship of an existing framework and the Patterns. Describing the synergy
between Struts and the J2EE Patterns might be an interesting example of the
decomposition of a specific framework into some of the component patterns from which
it is composed. Craig, any interest in working together on something like this? (I'm
too busy at the moment too, but maybe sometime in the not so distant future ;-)
Anyway, not sure if this would be of interest to the community at large, but I think
it might be...
Thanks,
Dan
>
>
> > Thanks,
> > Dan
> >
>
> Craig
--
Dan Malks Sun Java Center
Enterprise Java Architect 703.208.5794
