struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adolfo Miguelez" <pell...@hotmail.com>
Subject RE: the context
Date Wed, 17 Jul 2002 14:34:00 GMT
Thanks for the feedback Robert,

it seems actually similar. Probably the only difference in our approach is 
that we use a unique typed DTO, with all the application data. All the app 
data is centraliced in a only component, created with the info of a XML 
file, which follows data model for the app quite close to the real world.

I was thinking what about if in struts-config could be defined the fields of 
this unique component rather the fields of the ActionForms.  Struts could 
itself auto-create the ActionForms with Strings versions of the parameters 
equivalent to the typed ones in the unique DTO.

Our extended framework, could work out itself the ActionForms with 
dynabeans, as its parameters are defined in the config, make the usual 
validation and populate the DTO (which loose the data TRANSFER focus, as it 
becomes in a data holder), ready for usage in Action clases.

I think someone has suggested some thing similar before.

Thanks,

Adolfo.


>From: "Robert Taylor" <rtaylor@mulework.com>
>Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
>Subject: RE: the context
>Date: Wed, 17 Jul 2002 09:37:22 -0400
>
>Adolfo,
>
>I have been working on a model architecture for my current project and have
>been using a similar concept. I'm not sure if everyone would agree its the
>right way of going about things, but to me it seems to provide a clean
>separation of responsibility. I have been heavily influenced by Chucks
>Caveness book, especially Chapter 6 where he discusses the model layer.
>
>I won't go into the whole architecture, but the following is how I handle
>user input data in the various layers.
>
>-Data is input by the user and the browser (HTTP protocol) handles getting
>the raw data to the web server.
>
>-The presentation framework (Struts) packages and validates the data using
>some flavor of ActionForms.
>  My XXXXActionForms implement a particular "view" interface which provides
>the necessary getters and setters and
>  importXXXX() and exportXXXX(), where XXXX is the name of the DTO (data
>transport object). DTO are simple data
>  structures which contain the types that are native to the business layer
>(int, long, Date, etc...).
>  The importXXXX() and exportXXXX() leverage the BeanUtils package to do 
>the
>conversions. All data members in
>  the XXXXActionForms are Strings and therefore all input and output
>parameters to the getters and setters on the
>  "view" interface are Strings.
>
>-Struts ActionServlet delegates the request to the XXXXAction class defined
>by the action mapping.
>
>-The XXXXAction class gets the appropriate "service" to handle the business
>logic. My XXXXAction classes
>  are simply proxies to my business layer. They delegate processing 
>requests
>to a "service". The "service"
>  is just a business object that is very course grained where each 
>operation
>expects the appropriate "view" interface.
>
>-The XXXXAction class casts the XXXXActionForm into the appropriate
>interface and invokes the required operation on
>  the "service" passing the "view" interface.
>
>-The "service" invokes the appopriate exportXXXX() on the "view"
>implementation which extracts the appropriate DTO.
>
>-The "service" leverages other more fine grained business components which
>carry out the appropriate logic passing
>  around the DTO.
>
>Notice that each layer handles the data in accordance with its particular
>responsibility in the architecture.
>  - The browser deals with data in the HTTP request
>  - Struts deals with data as ActionForms
>  - Services deal with data as "views"
>  - The internal fine grained business logic deals with data as DTO
>
>The business layer only knows about "views" and DTOs; it is ignorant of
>anything in the web layer. There is no cross layer dependency
>between objects which reduces coupling and increases the cohesion.
>
>So I end up with something like the following in the XXXXAction class.
>
>  public ActionForward execute(ActionMapping mapping,
>                                  ActionForm form,
>                                  HttpServletRequest request,
>                                  HttpServletResponse response)
>         throws Exception {
>
>      MyView view = (MyView)form;
>      MyService service = null;
>
>      try {
>
>           service = this.getMyService();
>
>           // assume simple validation passed
>           serivce.doSomething(view);
>
>
>
>
>      } catch (SomeException se) {
>
>          // do something
>
>      }
>
>
>}
>
>
>and in MyService...
>
>
>public void soSomething(MyView view) throws SomeException {
>
>     SomeDTO sDTO = view.exportSomeDTO();
>     AnotherDTO aDTO = view.exportAnotherDTO();
>
>     // perform complex validation
>
>     // execute business logic or throw some exception
>
>
>
>}
>
>
>This keeps all my logic for a set of common business requirements
>encapsulated in a "service"
>which can be used with any presentation framework because my "service" just
>knows about the
>"views".
>
>
>HTH,
>
>robert
>
> > -----Original Message-----
> > From: Adolfo Miguelez [mailto:pelly69@hotmail.com]
> > Sent: Wednesday, July 17, 2002 8:35 AM
> > To: struts-user@jakarta.apache.org
> > Subject: Re: the context
> >
> >
> >
> > Following up with my own thread, I have thought that such a
> > context could be
> > useful for storing the info of the data in their native format,
> > Date, ints,
> > floats, .... leaving the ActionForms to hold data in String format, 
>ready
> > for the presentation layer.
> >
> > In some thread time ago (3/4 months), I remember someone suggesting to
> > duplicate the info of the input data in the ActionForm, one for
> > the Strings
> > format and another one for the native format, and maybe making
> > the casting
> > in the validate() method.
> >
> > e.g. for each input parameter, 2 methods:
> >
> > public Date getDate();
> > public String getDate();
> >
> > and their setDate() versions.
> >
> > In such a way, Actions could get the data already casted from
> > String to its
> > native java object from the ActionForm.
> >
> > What do you think about extracting such a duplicated info from the
> > ActionForm to this "context"? Any opinions please?
> >
> > >From: "Adolfo Miguelez" <pelly69@hotmail.com>
> > >Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > >To: struts-user@jakarta.apache.org
> > >Subject: the context
> > >Date: Tue, 16 Jul 2002 13:31:32 +0000
> > >
> > >Hi All,
> > >
> > >we are are developing a framework based on Struts, and adapting
> > Struts to a
> > >propietary middleware which, in turns, as usually, deals with
> > the backends.
> > >Struts would make up the presentation layer, more or less, delegating 
>in
> > >other layers for the business stuff.
> > >
> > >It has been suggested a patter model, which I did not know before, and,
> > >approximately, it is based in a XML which holds all the
> > application data in
> > >a tree structure grouped by functional roles. In that way, the
> > data is not
> > >spread all around the app, but it is wrapped in this functional
> > >abstraction. It could be seen as a central structure for holding all 
>the
> > >model (and i.e. the state) of the app. It is termed THE CONTEXT!!!!
> > >
> > >Actions fills the context, and send it to the middleware, which,
> > in turns,
> > >sends it to business layer. It has empty fields for the data
> > that has not
> > >been obtained yet (actually all the app data is wrapped inside the
> > >context). Business layer fills the new data into the context,
> > and the whole
> > >context is sent back to the action which, in turns, extract the
> > output data
> > >from it to fill the value objects and send this to the JSP for 
>rendering.
> > >
> > >Well, we are having actually, quite a lot of problems in
> > integrating  this
> > >new element with Struts, with the ActionForms, with the validator.....
> > >
> > >It is actually as a huge value object holding all the data of the app,
> > >travelling forwards and backwards along the app layers.
> > >
> > >My questions are:
> > >- has any of you seen a similar pattern? Any pointer is welcome.
> > I do not
> > >identify anything in the GoF patterns, but maybe I am not
> > realising of some
> > >of them.
> > >- what is your opinion about it?
> > >- could Struts, in future releases, include a context for
> > wrapping the data
> > >model for the app?
> > >
> > >Thanks in advance and sorry for the philosophical question,
> > >
> > >Adolfo
> > >
> > >_________________________________________________________________
> > >Chat with friends online, try MSN Messenger: http://messenger.msn.com
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> >
> > _________________________________________________________________
> > Join the world’s largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com
> >
> >
> > --
> > To unsubscribe, e-mail:
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
><mailto:struts-user-help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>




<HTML>
      <HEAD>
             <TITLE>Adolfo's signature</TITLE>
      </HEAD>
      <BODY>
             <center><b><em>Adolfo Rodriguez Miguelez</em><b></center>

      </BODY>
      </HTML>





_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message