cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Cocoon and web applications
Date Mon, 26 Feb 2001 20:34:30 GMT
Stefano Mazzocchi wrote:
> First of all, sorry for the major crosspost but I believe that it would
> be extremely beneficial for everybody (heck, we are all parts of Apache
> communities after all!) to discuss ways to integrate, avoid overlap and
> reduce duplication of effort.


> The only thing that needs to be addressed is web application support,
> which is likely to overlap with existing solutions in the Apache world.

Cocoon does have the beginnings of this support, but it is not documented
well, or (possibly) not fully thought out.

> In the last few weeks, I evaluated almost all existing web technologies
> (ranging from Perl to PHP, ASP to JSP, Turbine to Struct) and I believe
> that the design concepts Cocoon is based on are *almost* orthogonal to
> the design concepts that web-app frameworks are based on.

Ok. I can buy that.  Since Web Applications are what I do, I agree to
this point.  I prefer the clean separation between form handling and
form display.

> Why so? Well, Cocoon is totally agnostic on how content is generated.
> Cocoon provides an abstraction following the IoC pattern (IoC =
> Inversion of Control), just like the Servlet API. Turbine does the same
> with screens. Struct does the same with JSP as views.
> A question can be posed: where does Cocoon stand in the model1/model2
> concept? nowhere! It's just like a servlet engine: it's up to you to
> write the generator!

Another possibility is to use Turbine to aggregate separate serialized
Cocoon streams....

> Cocoon provides a huge amount of machinery to
> adapt/transform/change/serialize/mount/map/match in order to eliminate
> the need for you, generator writer, about these things.

Having worked on it in depth, I can tell you that the machinery is
well-oiled with one exception: Cocoon 2 XSP generation is curiously
slow.  I am still looking into it to figure out why, but everything
else is blazingly fast.

> This said, it is obvious that frameworks that reside at "generation
> stage" cannot call the container without breaking inversion of control.
> It's much like the old getServlet() method that was deprecated from the
> Servlet API.

I agree.

> Ok, you say, but why is this different from the Servlet API 2.3
> Filtering support? Why isn't Cocoon part of Tomcat directly?

Well filters are great for invisible form handling (theorhetically).

> Let's find out where the overlap is:
> 1) turbine is both a framework for web applications and a collection of
> services. This doesn't overlap with Cocoon directly, rather with Avalon,
> which is intended to be a framework for componentized serving
> applications, thus is able to perform the same service functionalities
> that Turbine does, with a few more capabilities (like component
> versioning, dynamic componentization and the like).
> It would be extremely cool to factor out turbine services into avalon
> components since:
>  a) it would provide more 'meat' for the avalon component pool
>  b) remove duplication (Avalon contains a few services that overlap with
> Turbine functionality, clearly a nonsense since they belong to the very
> same community of developers!)
>  c) increase productivity and visibility of both projects by unifying
> the noosphere.
>  d) increase functionality (ever thought of mail-applications? turbine
> as a Mailet? you should since JAMES is built on Avalon and provides
> almost all messaging needs including POP3/IMAP4 support!)

I would keep them as part of Turbine, but simply letting them take
advantage of Cocoon Components and Configurations will help give real
feedback on how to make Avalon more usable, and provide the facilities
to Cocoon--as long as the Roles are well defined.

> Is there a reason to maintain Turbine separated from Avalon? I honestly
> don't know, so I'm asking you. On the "well, we don't know what this
> means" side, I'm sure there will be tons of people willing to help from
> both the Avalon and Cocoon project for such a refactoring to take place.

Yes.  Avalon is a generic framework, Turbine is a specific framework.  There
is nothing that says that Turbine can't be built on Avalon, nor is there
anything that says that pieces of Turbine could be included in Avalon.

It depends on what the facility is.

> 2) turbine as a framework doesn't overlap with Cocoon since Cocoon
> doesn't care on how you end up generating your content. All the concepts
> such as model2, model2+1, MVC, pushMVC, pullMVC, HMVC, etc.. all concern
> the generation stage.
> The only overlap between Cocoon and Turbine is XSP, which is our
> solution to custom generator creation.
> XSP 1.0 is a model 1 solution tuned for XML: I fully agree with Jon when
> he states that XSP is nothing different from JSP in many situations
> where lots of logic must be present.

XSP is really nice, but there are some aspects I would like to see
improve.  Since this isn't the forum for that, I will leave the details
out--I need to formulate what I *really* want vs. stream of consciousness
rambling anyways.

> In fact, evidence in the Cocoon user community clearly shows that XSP
> are great for publishing (that is HTTP GET actions only!), but rather
> painful for web applications (where POST and GET actions mix). The
> reason? XSP 1.0 were not designed with MVC in mind, but to allow easy
> generation of dynamic pages to be published.

Here, Here!  One thing I liked about ColdFusion (general mayhem ensues)
was that it was easy to separate Pure content and Pure logic sheets
with a simple relocation between them.  However, due to some bad experiences
with ColdFusion and the differences in the way some Web Servers handle
(or mishandle) relocation, it was not a real solution for me.

My introduction to Cocoon, and I was hooked.  I had a template displaying
how to reformulate the existing webapp into a Cocoon webapp shortly followed.
It quickly became apparent to me that in the Cocoon 1 framework, there
was no way to separate these concerns.  This is frustrating because SoC
(Separation of Concerns) is one of the founding patterns used in Cocoon
and Avalon.

With the Action framework introduced in Cocoon 2, I have the best of both
worlds--although it could be made easier to use.

> In the past, Cocoon design was criticized for some XSP design holes, I
> would like to enphasize that this is equivalent of criticizing the
> Servlet API design for some JSP design faults. Even more: unlike the
> Servlet API/JSP, great care was taken in both making Cocoon completely
> generation agnostic (the XSP component is itself a generator!) as well
> as configuration semantics (unlike the Servlet API deployment
> descriptors).
> XSP have been proven extremely valid for publishing needs, it doesn't
> fit for web-apps, at least not in its current shape.
> What to do?
> Well, there are several alternatives:
> 1) add MVC strategies in XSP

This has promise, although I would have to give some time to research
the Turbine MVC patterns.  There is alot that could be learned here.

> 2) turn Turbine into a generator and use directly Turbine stragegies

Again, I have to research what Turbine strategies will afford me, and
how they would be integrated

> 3) factor out Turbine strategies and make Cocoon components out of this.

This is relatively easy to do, though it has the most impact on Turbine.
Again, I don't know a whole lot about Turbine.

> 4) ???

Actions.  Actions are unique to the Cocoon 2 framework in that they allow
for two distinct advantages:  They allow you to talk directly to the
sitemap to control flow (based on administrator settings), and they allow
you to perform invisible form handling without using clumsy relocation

They are currently very specific to Cocoon, but seeing as they are
Cocoon Components (and Avalon Components by extension), they provide
most of the functionality that is missing in the Cocoon Webapp sphere.

What would be possible is an Turbine StrategyWrapper in the form of
an Action.  It would allow Cocoon to seamlessly use already developed
Turbine Strategies, as well as even the burden of development between
the two projects.

> I honestly don't know which out is the best for everybody: refactoring
> Turbine into Cocoon components and Avalon components might tear the
> project's identity apart and I don't this this is useful. There must be
> a project focused on the development of web-app specific guidelines and
> paradigms, neither Cocoon nor Avalon can do this as effectively.

+10000.  However, that project can't be ignorant of either Avalon or
Cocoon--just as the others should not be ignorant of Turbine or even
Struts.  I must admit that I am guilty of this, and should look at how
the projects can work together better.  It is important to look at the
same problem from different viewpoints.

Avalon provides a framework and a view from the nuts and bolts side of
things: more of a structural view.

Cocoon provides a publishing framework and a view from URL contract
management (sitemap) and publishing.

Turbine as I understand it provides a view of WebApp organization
and building.  I haven't found ANY documentation on this other than
API docs--at least that I can browse on the web.

> On the other hand, once Cocoon2 and Avalon API stabilize, making Turbine
> a Cocoon-based and Avalon-aware web-app sub-framework makes perfect
> sense to me: it gives the 'turbo boost' for web-apps that neither Cocoon
> nor Avalon alone can provide.

The APIs are fairly close to stable...  Cocoon 2 will most likely add
some components, but other than that, the overall API has been pretty
solid for a few weeks.

> Ok, you might ask: this requires users to install yet another thing down
> below and what for?
> Well, there are a few things you get for free: caching and content
> aggregation, for example, advanced publishing capabilities become
> available transparently and your web-app can almost instantly be turned
> into a WAP-app by simply changing the stylesheets that transform the
> content.

If the end result is reduced time to market, then I am all for it.

> Ah, I forgot: another critique that was moved against Cocoon was the
> fact that XSLT is a difficult language and many don't like to be forced
> to use it and like their own solutions better.

XSLT is a pain in the butt.  That aside, there are ways you can convert
a regular HTML mockup into a "skin" for aggregated markup.

> Well, just like we did for generation, even transformation is totally
> language-agnostic: it is entirely possible to drive a transformation
> process either directly (I mean: you write the java code that performs
> the transformation) or interpreting a transformation language of some
> sort (in that case, you have to write the interpreter). It is entirely
> possible to use Anakia's velocity-based procedural transformation
> language instead of declarative XSLT which some find less readable.

There will be serious advantages for SAX based alternatives than something
that requires a discrete transformation step.  In other words, If you have
to cache all the SAX events before transformation, then you are creating
a performance issue--especially with large documents.

> Again, even if Cocoon ships with an XSLT-based transformer, the overlapp
> architecture was designed to avoid lock-in even for open standards and
> allow you to personalize the component pipeline generation to the
> granularity you want.

I have found that using hand crafted Transformers will out perform XSP
right now.  This is unfortunate, but won't be long lived.

> Another critique was the concept MVC is powerful enough to avoid the
> need for transformation. That is: the controller can choose different
> views depending on runtime parameters.

In some ways absolutely.  However, Cocoon will allow you to use ephemeral
Models.  By this I mean SQL ResultSets, [Enterprise] JavaBeans, and other
proprietary models.  When filtering is done at the Generation stage,
we have a very good bet on not wasting resources.

That is way XSP *uses* those models.  If there is a way to use Turbine
Models in the Generation stage, we could have yet another integration

> This is a very powerful concept indeed: it is utterly inefficient to
> generate a complex view of all the data contained in the model only to
> 'filter them out' at transformation stage. Here, the MVC model is
> clearly a winner.

This is overkill in anyones book.  That is why XSP and custom generators
use existing models of Data, and only generate the portion needed at the

> But, IMO, it is limiting to assume that since presentation can be
> decided at generation stage, it is optimal to do so.

Mixing presentation concerns and data models is IMO a bad thing.  That
is why I would create a model of say an Advertisement that can be
represented in XML.  I have the ability to transform my view (presentation/
transformation) into what I want and send it to the user (Serialization).

> It is totally possible to concieve a system where both view choice and
> transformation reduce overall maintenance costs. For example: views are
> choosen as 'layouts' and trasformations as 'skins'. Why? because they
> are two different graphical concerns:
>  1) where to place information / how to design the UI

I do this in one Transformation layer in Cocoon

>  2) how to present it

I do this in another Transformation layer in Cocoon.

> the use of different views allow you to have different layouts and
> different presentations, but if you have m layouts and n styles, you end
> up requiring n*m views while with transformations you would only need m
> views and n styles.

Already possible with Cocoon, but definitely could be optimized a bit.

> It also takes into consideration the fact that normally UI designers and
> graphic designers are different people with different skills: MVC forces
> them to work together only because both happen to impact on the
> 'presentation' of the information, even if with different aspects.

I definitely agree here.  I worked on a Workflow system where the layout
was designed by Developers (with no sense of style or placement).  My first
task was to retrofit the existing app with the Graphic designer's idea of
how the WebApp should look.  After I was done, the app had style, but wasn't
very usable.  I took my team of two, and we went through the feedback from
our customer.  We identified some common structures of how to layout an
Inbox oriented Workflow that really worked for our customer.  Again with
the retrofitting.

This retrofitting required altering over 200 templates, and it was HTML
mixed with the logical markup.  Now you can see why I am heavily biased
toward Cocoon.  It fills a serious need we have in the way we work at my
company.  The graphic artist is usually contracted too late, and then the
rework ensues.  With Cocoon as my publishing engine, I can change the look
of my entire webapp in one file--this is invaluable.  I can also change
the overall layout with a second file.

I typically stick with traditional data models, using Cocoon as my View
layer--and now with Actions, my Controller as well.

Now, I am very willing to entertain how Turbine in the mix could assist
me as well.

> 1) Cocoon and Turbine don't overlap but the assumption that Cocoon can
> be called by Turbine as a screen is misleading and ruining the design
> concepts that Cocoon was based on. This is, to me, the reason why nobody
> was able to integrate Turbine and Cocoon elegantly up to date (see
> Jetspeed).

Integration is a difficult issue on many levels, but I would need better
understanding of the specific problem domain in order to come up with
good solutions.

> 2) I explained why an XML web applications can use both Cocoon and
> Turbine functionality only if Turbine is contained by Cocoon and not the
> other way around.

I think this is the proper approach.  Imagine if you will a Turbine
Generator and a Jetspeed Aggregator all stylized by Cocoon.  I think
that would be Really cool--because now I am working on a "portal" of

Right now, it is more painful to do what I need, but I can't take the
risk that the site won't be restyled later.

> 4) I explained how many of the critiques that were moved against Cocoon
> were in fact against technologies that Cocoon was using to implement
> some of its components. No critique, so far, has mined Cocoon's core
> design concepts.

Where have you heard these critiques.  Everything I have read has been
pretty much pro-Cocoon.  I mean Cocoon really excites the imagination
of what can be done.  When you marry it with other less glamerous projects
the result is a net boon for all projects involved.  It brings more
users to the table for all of the technologies involved.

> 5) I explained how the use of both Cocoon and Turbine functionalities
> can be useful to reduce costs for web-app generation and provide great
> synergy between the two communities that can exchange information and
> design guidelines to improve both sides of the fence.

I like the prospect of this.  Is there any other methods besides Turbine
Generators and Actions?

View raw message