cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Guttmann <>
Subject Re: Combining Cocoon with Struts Tag libs
Date Mon, 17 Jun 2002 17:46:17 GMT

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. 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:,
ldexp-dev <>,
>             >                     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
> 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.     <>
> >
> > To unsubscribe, e-mail:     <>
> > For additional commands, e-mail:   <>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <>
> To unsubscribe, e-mail:     <>
> For additional commands, e-mail:   <>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <>
> To unsubscribe, e-mail:     <>
> For additional commands, e-mail:   <>

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message