cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam_Wal...@eFunds.com
Subject Re: Combining Cocoon with Struts Tag libs
Date Tue, 05 Feb 2002 15:45:03 GMT

Werner,

Thanks for your comments.

What do you think about using Cocoon as a Service to Struts to do the
Transformation in an Action?

This would keep the Action Servlet in control, but utilize control/view of
Cocoon.

Down side to this might be the memory overhead for both servlets.

But, you might have equal overhead trying to implement the same xml view
functionality using the same transform classes through Struts as a similar
Action.

-Adam


                                                                                         
                                                    
                      Werner Guttmann                                                    
                                                    
                      <Werner.Guttmann@morgans        To:       cocoon-users@xml.apache.org,
ldbledge <ldbledge@ms.com>                       
                      tanley.com>                     cc:                             
                                                       
                                                      Subject:  Re: Combining Cocoon with
Struts Tag libs                                     
                      06/17/02 12:46 PM                                                  
                                                    
                      Please respond to                                                  
                                                    
                      cocoon-users                                                       
                                                    
                                                                                         
                                                    
                                                                                         
                                                    




Adam,

not knowing XMLForms within Cocoon enough, I will simply try to address
your concerns/issues with regards to having Struts as part of the
equation. Please see below.

Adam_Waldal@eFunds.com wrote:

> Werner,
>
> The situation is this:
>
> 1) I need to accomplish a validation of a 5 part form that is validated
and
> filled incrementally.
> 2) Take the contents of this composite form and create one xml from it's
> contents.
> 3) Submit to a Transforming servlet that takes this xml and spits back an
> xml response after retrieving info from a Mainframe app.
> 4a) Display xml response as a page with 6 tabs ( one page w/ layers or
six
> pages with links to the others)
> 4b) If there are errors in the response for any of the six parts it needs
> to display the form with the corresponding inputs filled in for
corrections
> to be made.
> 5) Accept re-submission and re-validate
> 6) Submit reponse to back-end again, loop sequence.
>

If you have people out there that are comfortable with using Struts,
there's no reason to not use Struts. Lookig at the above task list, I
would argue 1) and 2) and 4b), 5) and 6) can be done easily using Struts
FormBeans and a short, custom-developed Action instance. 3) could be
done both from within a Struts action and a Coccon action .. should not
make a difference.

Re: 4a), me thinks that it would be easier here using Coccon and its main
concept, the pipeline, for the transformation required to produce
the final HTML. In the end, all that this is about is a transformation of
such (structured) XML to HTML. Nothing really difficult ... and
definitely easier than unmarshalling the XML received from step 3)
programatically in a JSP and producing the right HTML.

> This sequence is the bulk of the app.  There is security and other stuff,
> but that is the core of it.
>
> The debate is over performance, use of languages, and ease of support.

Suport, maintainability .. I agree. And in this context I prefer an
XML-based config file (whether with Struts or Cocoon does not matter) over
some logic hard-coded in a JSP or elsewhere .. in other words, using
frameworks such as Struts and Cocoon helps you creating maintainable
applications as many people have spent a lot of time with these issues ...
and have actually solved them. I really do not understand where
this myth that framework = complexity = slowness comes from. One would
assume that one's employeer would pay you for delivering applications
that are well-designed and maintainable rather than fast only ...

> With performance coming at the top of that list.

As always .. though this should not be the case .. ;-).

> One other concern I have about splitting the architecture into two
servlets
> is session management.  Where do I put the timeout logic is another
> question I need to answer?
>
> The developers not surprisingly are skeptic of anything that involves xml
> based coding, instead of what they are comfortable with(Model 2).

Well, you will have to bridge these their concerns .. ;-). You are dealing
with XML already, as the backend on the mainframe talks XML only.
As already said above, I thin it is easier to write stylesheets that
transform XML into (X)HTML than fiddling around with JSPs and dealing
with unmarshall the XML returned from the mainframe programatically. As an
aside, replacing Struts with XMLForms et alias still gives you MVC,
though a differrent flavour.

> I need to come up with a good reason not to use Struts.

I do not think whether this should be the real decision: use Struts where
appropriate, especially in the areas where it offers strong support,
and maybe somebody else can comment on the features of XMLForms, the
ValidatorAction et alias and how they would be appropriate to replace
Struts inb the long term. Please bear in mind that this stuff has not been
released officially ... iow, somewhat adventerous to a corporate
cimate where people are used to deal with 3rd party vendor products only ..
;-).

>
>
> -Adam
>
>
>                       Werner Guttmann
>                       <Werner.Guttmann@morgans        To:
cocoon-users@xml.apache.org, ldexp-dev <ldexp-dev@ms.com>, ldwebdeb@ms.com
>                       tanley.com>                     cc:
>                                                       Subject:  Re:
Combining Cocoon with Struts Tag libs
>                       06/17/02 10:53 AM
>                       Please respond to
>                       cocoon-users
>
>
>
> Adam,
>
> there's a couple of alternatives you seem to have, one of them using
> XMLForms
> et alias to implement functionality of Struts in Cocoon. As this
> functionality
> has only become available in the recent past, we have taken a different
> approach using the XMLizable interface of Cocoon to integrate our
business
> domain model with both Struts and Coccon.
>
> In our case, an inbound HTTP request is
>
> 1) picked up by Struts, which a) populates its FormBean(s) , and b)
> forwards
> to a pre-configured Action for additional validation. If successful, we
> then
> forward control to an XSP ... in order to avoid introducing dependencies
> between Struts and Cocoon, we decided to implement our own set of
JavaBeans
> to
> keep the set of parameters as selected in the HTML form, which we
attached
> to
> the request/session scope as attributes.
>
> b) On Coccon receiving the HTTP request (forward), Coocon kicked in and
> invoked the relevant pipeline. That pipeline uses the ServerPages
generator
> to
> invoke an XSP that uses the following code fragment:
>
> <xsp:logic>
>    XMLizable xmlizable = new XTransformer();
> </xsp:logic>
>
> <some_entities><xsp:expr>xmlizable</xsp:expr></some_entities>
>
> Cocoon - when processing the <xsp:exp> element - will invoke the
> toSAX(ContentHandler) method on our XTransformer class, and expects this
> method to insert SAX events into the event stream. In our case, for each
> business entity we have a corresponding Transformer instance that uses
the
> aforementioned Criteria object, a business delegate and (potentially) a
> value
> list handler implementation to get a collection of business entities from
> our
> business backend, and render them to SAX events. From there on, it's
> business
> as usual with Cocoon executing the remainder of the pipeline.
>
> Now, having followed some of the traffic on this list re: XMLForms, etc.,
I
> am
> under the impression that most of the stuff could (and maybe should) be
> done
> through the use of XMLForms, ValidatorAction, etc. Unfortunately, I have
> not
> had the time to evaluate the various offering (yet).
>
> I hope this helps.
> Werner
>
> Adam_Waldal@eFunds.com wrote:
>
> > Cocoon-Collective,
> >
> > I am still trying to make architecture decisions.  I have a pretty good
> > understanding of both Struts and Cocoon architectures.  I have seen a
> > couple of other people inquire about a hybrid solution using the
> strengths
> > in both.  Has anyone considered or done this successfully and seemingly
> > painlessly?
> >
> > I guess this really comes down to a comparison of xsp vs. jsp and which
> to
> > use.  The other major consideration is performance, the system I need
to
> > build will be high traffic and transactional.  Does anyone have a
similar
> > situation or opinion that will help my decision process?
> >
> > Thanks,
> > Adam
> >
> > ---------------------------------------------------------------------
> > Please check that your question  has not already been answered in the
> > FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
> >
> > To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
> > For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>
>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>
>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>







---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message