You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jorge Ribeiro Jordão <jo...@telecelvodafone.pt> on 2001/03/14 19:50:37 UTC

Struts and Sun's J2EE Patterns

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.

What do you think ?


---------- 
This message may contain confidential information or privileged material,
and is intended only for the individual(s) named. If you are not in the
named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. 
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses.  The sender therefore does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission. If verification is required please
request a hard-copy version. 

Re: Struts and Sun's J2EE Patterns

Posted by Dan Malks <da...@sun.com>.
Ted,
Sounds good.
Let me know once you've started to incorporate the patterns and I'll have a
look.
Thanks,
-dm

Ted Husted wrote:

> I've started a new piece about building a Strut's application from
> scratch. I'm now thinking about how to work the J2EE patterns into what
> I started. The work in progress is at
>
> < http://husted.com/about/struts >
>
> under Coming Soon.
>
> Any notes or ideas people might have about this would be appreciated.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/

--
Dan Malks                            Sun Java Center
Enterprise Java Architect            703.208.5794



Re: Struts and Sun's J2EE Patterns

Posted by Ted Husted <hu...@apache.org>.
I've started a new piece about building a Strut's application from
scratch. I'm now thinking about how to work the J2EE patterns into what
I started. The work in progress is at 

< http://husted.com/about/struts >

under Coming Soon.

Any notes or ideas people might have about this would be appreciated.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Re: Struts and Sun's J2EE Patterns

Posted by Dan Malks <da...@sun.com>.
Hi Craig,

"Craig R. McClanahan" wrote:

> On Fri, 16 Mar 2001, Dan Malks wrote:
> [snip]
> > 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
> >
>
> I would be interested in working on something like this.  The next three
> weeks are totally impossible (I'm speaking at both O'Reilly Enterprise
> Java Conference and ApacheCon, and have some "real work" to get done along
> the way :-), but would have a little time to talk about this in April.
>
> > >
> > >
> > > > Thanks,
> > > > Dan
> > > >
> > >
> > > Craig

April's come and gone and I've been too busy to even think about writing something, as I
imagine you have been. At the same time, would you like to discuss an outline at some
point, so we can consider doing this?

Let me know what you think.
Thanks,
Dan

>
> >
> > --
> > Dan Malks                            Sun Java Center
> > Enterprise Java Architect            703.208.5794
> >
> >
> >
>
> Craig

--
Dan Malks                            Sun Java Center
Enterprise Java Architect            703.208.5794



Re: Struts and Sun's J2EE Patterns

Posted by Dan Malks <da...@sun.com>.
Craig,

"Craig R. McClanahan" wrote:

> On Fri, 16 Mar 2001, Dan Malks wrote:
>
> >
> > 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
> >
>
> I would be interested in working on something like this.  The next three
> weeks are totally impossible (I'm speaking at both O'Reilly Enterprise
> Java Conference and ApacheCon, and have some "real work" to get done along
> the way :-), but would have a little time to talk about this in April.

Understood.
April is possible, but let's just see how the workload goes for each of us.
Good luck with your presentations!
Dan

>
>
> > >
> > >
> > > > Thanks,
> > > > Dan
> > > >
> > >
> > > Craig
> >
> > --
> > Dan Malks                            Sun Java Center
> > Enterprise Java Architect            703.208.5794
> >
> >
> >
>
> Craig

--
Dan Malks                            Sun Java Center
Enterprise Java Architect            703.208.5794



Re: Struts and Sun's J2EE Patterns

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Fri, 16 Mar 2001, Dan Malks wrote:

> 
> 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
> 

I would be interested in working on something like this.  The next three
weeks are totally impossible (I'm speaking at both O'Reilly Enterprise
Java Conference and ApacheCon, and have some "real work" to get done along
the way :-), but would have a little time to talk about this in April.

> >
> >
> > > Thanks,
> > > Dan
> > >
> >
> > Craig
> 
> --
> Dan Malks                            Sun Java Center
> Enterprise Java Architect            703.208.5794
> 
> 
> 

Craig



Re: Struts and Sun's J2EE Patterns

Posted by Dan Malks <da...@sun.com>.
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



Re: Struts and Sun's J2EE Patterns

Posted by "Craig R. McClanahan" <cr...@apache.org>.
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().

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.

> 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 :-).

> Thanks,
> Dan
> 

Craig


Re: Struts and Sun's J2EE Patterns

Posted by Dan Malks <da...@sun.com>.
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?

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.

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).

Thanks,
Dan

>
>
> What do you think ?
>
> ----------
> This message may contain confidential information or privileged material,
> and is intended only for the individual(s) named. If you are not in the
> named addressee you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses.  The sender therefore does not accept
> liability for any errors or omissions in the contents of this message which
> arise as a result of e-mail transmission. If verification is required please
> request a hard-copy version.

--
Dan Malks                            Sun Java Center
Enterprise Java Architect            703.208.5794



RE: Struts and Sun's J2EE Patterns

Posted by Philip Hart <ha...@ubusiness.co.uk>.
Are my postings not reaching the list? I'm sure I posted an informational on
this subject over a week ago!

Philip Hart

> -----Original Message-----
> From: Jorge Ribeiro Jordão [mailto:jorge.jordao@telecelvodafone.pt]
> Sent: 14 March 2001 18:51
> To: 'struts-user@jakarta.apache.org'
> Subject: Struts and Sun's J2EE Patterns
>
>
> 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.
>
> What do you think ?
>
>
> ----------
> This message may contain confidential information or privileged material,
> and is intended only for the individual(s) named. If you are not in the
> named addressee you should not disseminate, distribute or copy
> this e-mail.
> Please notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed,
> arrive late or
> incomplete, or contain viruses.  The sender therefore does not accept
> liability for any errors or omissions in the contents of this
> message which
> arise as a result of e-mail transmission. If verification is
> required please
> request a hard-copy version.
>