cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] Cocoon and web applications
Date Mon, 26 Feb 2001 17:45:01 GMT
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.

Please, understand that this RT (random thoughts, that is) is just a
friendly way to sparkle a healthy discussion and I hope it doesn't turn
out to be a dogfight over some irrational tastes.

It is because I respect the value of these communities that I post this.
I hope this will be appreciated, at least as a try.

                                  - o -

In the last few weeks I submitted what I consider good starting points
for the conclusion of the design work on Cocoon2 with my proposals/RT on
caching and content aggregation.

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

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.

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!

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.

Cocoon should be seen as a xml-driven serving enviornment, a mix between
a modular web server and a servlet engine. All based on SAX streams
instead of char streams.

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.

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, first of all, the Servlet API has no notion of SAX streams but
only char streams: this means that if you have to do a transformation of
some dynamically generated content, you have to serialize the SAX events
into a char stream (adding the angle brakets and all the XML stuff),
then parse it again, only because the only stream accessible is char
based.

Also, given this limitation, there is no difference between the notion
of 'transformation" (that is: transform a SAX stream into another SAX
stream) and 'serialization" (that is: transform a SAX stream into a byte
stream).

Example:

 file.xml -(docbook)-> XSLT transformation -(fo)-> PDF serialization

Wouldn't it be cool to have the output of your turbine web application
available on printed media with no changes to your logic?

I fully believe that publishing and web applications are orthogonal
concepts as long as the two frameworks are designed to work together.
Unfortunately, this was not the case historically since Jon and I had
different desires when we started and different itches to scratch. But
the evolution of the two projects is very likely to converge and overlap
to increase.

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!)

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.

Of course, this is up to you guys to decide.

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.

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.

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
2) turn Turbine into a generator and use directly Turbine stragegies
3) factor out Turbine strategies and make Cocoon components out of this.
4) ???

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.

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.

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.

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.

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.

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.

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.

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.

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

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
 2) how to present it

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.

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.

                              - o -

I want to draw some conclusions at this point.

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).

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.

3) I explained how Turbine and Avalon should reduce overlap by turning
Turbine Services into Avalon components and using Avalon API to access
them, while using Turbine code to implement them.

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.

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.

                              - o -

I would like to point out that the above represent my own personal
opinion and do not represent endorsement by either the Cocoon user
community nor its active developers, but my own opinion as Cocoon
developer.

My impression is that technological misunderstandings and ego problems
from both sides (for sure I have my big part on this, having rejected
many critiques for months without paying attention to the real meanings
of them) have stopped any discussion from taking place and shape the
projects involved.

>From my part, at this point, there is very little ego to protect and
many mistakes to admit, I sincerely hope this can lead the discussion to
a prolific point.

Thanks to all for the patience.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


Mime
View raw message