cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artur Bialecki" <ar...@digitalfairway.com>
Subject RE: [RT] Cocoon Integration Model
Date Mon, 15 Jul 2002 14:39:56 GMT

I think cocoon web application blueprints are a great idea.
I had to get around many cocoon quirks to get it working 
in a J2EE environment. I've always seen cocoon advertised
for web-publishing so I always thought that I'm not using
it for what it was intended. To be fair J2EE has many quirks
too which caused some of the problems.

Now, let's not do another PetStore, maybe something 
more along the B to B model?

Artur...

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, July 15, 2002 10:13 AM
> To: cocoon-dev@xml.apache.org
> Subject: [RT] Cocoon Integration Model
> 
> 
> Something that has been bothering me regarding Cocoon's web app model is
> how the webapp is supposed to be defined.  Cocoon started as a content
> publishing model.  At this, it is better than anything else out there.
> Using Cocoon for webapps has traditionally been troublesome.  As a
> result,
> we have been trying to extend it and make it a better platform for web
> applications.
> 
> The ways we extended it made it closer to an ideal, but never quite
> there.
> The J2EE blueprints, struts, and turbine all advocate an MVC approach.
> We have been trying to make that happen in Cocoon as well.  We have MVC
> for the presentation of information--model=XML,
> view=transformes/serializers,
> and controller=sitemap/actions.  However, that is not the proper
> division
> for a web Application.
> 
> * A proper model represents the application data.  Whether you use
> direct
>   SQL manipulation or an object model is up to you.  XMLDBs attempt to
>   represent the data in XML--which seems the best way for Cocoon.
> However,
>   XMLDBs are largely unproven in high transaction environments so
> traditional
>   shops want to opt for more traditional models.
> 
> * Cocoon itself is the ultimate view.  You can represent your
> information
>   in so many different formats it isn't even funny.  According to J2EE,
>   Servlets and JSPs are types of *views*.  Essentially, this makes
> Cocoon
>   as a whole just another view.
> 
> * Control is a more complex subject as different types of control work
>   together to represent a coherent application.  The J2EE blueprints
> have
>   Session EJBs handle the application logic, while the servlets handle
>   the presentation logic.  It is important to separate them out because
>   handling which page of a form comes next is different from what
> happens
>   when we approve something.  Cocoon works well for presentation logic,
>   but admittedly does not do well for application logic.
> 
> As a result, what we have now to overcome the basic deficiencies in the
> Cocoon integration picture is the inclusion of Transformers, Generators
> (XSP esp.), and Actions that all perform application level logic.  The
> two biggest culprits are the Action and the Generator.
> 
> I have developed a few webapps using Cocoon, and have boiled down how
> to come up with a Quick and Dirty (Q&D) setup rather quickly.  However,
> I have never been satisfied with what it takes to bring other developers
> on board.  By the shear quantity of information, component types, and
> now pipeline types, the average newbie spends much longer trying to
> understand Cocoon than they do actually using it.
> 
> When I wrote the first cut of the webapp tutorial, I had every intention
> of making it as useful as the "Developing with Avalon" document I wrote.
> Unfortunately, I ran out of time.  My arguments about Cocoon apps being
> easier to maintain and supporting simultaneous development went out the
> window when people I was working with in my office spent six weeks
> trying
> to come to grips with everything.
> 
> I tried to tell them that if you use the markup I developed everything
> would look like it belonged to the site.  I still had one stubborn
> developer
> who insisted on directly writing broken HTML.  I tried to tell them that
> they didn't have to worry about the sitemap--it was my responsibility,
> but still they tried to understand it.
> 
> It can be argued that the troubles I had were largely due to training
> or management decisions.  (Once I got a developer working with it
> properly, she and I cranked out the application in about two weeks).
> The problem is more fundamental than that.  The problem is that there
> is no proven or set way of creating web applications using Cocoon time
> after time after time.  That is what the J2EE blueprints are for.  To
> help developers not waste their time on harmful patterns, and
> concentrate
> on more useful aspects of J2EE.  As a result, it is a platform that
> works--maybe not the best, but it works.
> 
> Cocoon can definitely use its own blueprint.  A Cocoon Application
> Blueprint is an essential document that we need.  There are two ways
> of using Cocoon: integrated in with a traditional J2EE environment,
> and standalone.  The blueprint will define exactly what part of the
> puzzle Cocoon supports.  It will also define which patterns work well,
> why they work well, and the antipatterns which suck all your time.
> 
> A side-affect, and general improvement will be that Cocoon will begin
> to be shaped by the blueprint.  The proposals that are given will be
> there to enhance the model, or to overcome shortcomings.  As we state
> *how* Cocoon should be used, it's development effort will follow that
> pattern.  As of right now, the oppinions on how to get the best out
> of Cocoon are as varied as the number of developers on the list.
> 
> 
> "They that give up essential liberty to obtain a little temporary safety
>  deserve neither liberty nor safety."
>                 - Benjamin Franklin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message