> "Diethelm Guallar, Gonzalo" wrote:
>
> Hello,
>
> I have been talking with some guys on the Cocoon list,
> specially Stefano, and would like to hear comments from
> the Jetspeed people on a few issues. Stefano's comments
> are quoted with "S>", mine with "G>", for clarity.
>
> Please, let me state that I'm NOT trying to start a
> flame war, or offend anyone. I'm just looking for a
> clearer picture of things.
>
There's no basis for a flame war, it's a subject that pop up every 2 months either
on the Cocoon or the Jetspeed list... :)
>
> S> > > > Turbine -> servlet (standalone)
>
> G> > Besides being a servlet, it seems to define a standard way (sort
> G> > of a "philosophy") for writing web apps, right?
>
> S> Oh, yes, it's a framework, by itself doesn't mean anything
> S> (more or less like Cocoon).
>
> I guess what Stefano is saying here is that Turbine (and Cocoon)
> don't do much by themselves; you have to provide your content
> on top of them.
>
Both are frameworks but they have different focus I guess (Jon or Stefano can
correct me):
Turbine: java web *application* framework. Main focus is reussibility of components,
especially business logic (through Actions). Segmented user layout design that
is mainly geared toward programmers. Turbine is efficient and full of useful
backend components (such as user management system, scheduler, etc...).
Cocoon 2: XML web *publishing* framework. More ambitious than Turbine aims to fully
and cleanly separate publishing concerns. Does not offer as many tools as Turbine
for application developments (especially you have to do your own user management/
access controls) but its clean design will certainly allow a good extensibility.
Alpha stage currently so we don't know yet how it will compare to Turbine performance
wise.
Both are worthwhile frameworks, they follow 2 completely different development paths:
Turbine is *grown* by integrating working code and practices
Cocoon is *built* with a careful theorcial design aimed to answer a well-specified
need.
Turbine sometimes looks like a mess because it's a more organic framework.
Cocoon is very clean cut but has yet to prove its design in real life and require you
to strictly follow its patterns.
> G> > How well does [Turbine] integrate (if at all) with Cocoon?
>
> S> Unfortunately, it does not integrate and we have yet to discover a way
> S> (if any) to do this. The projects are very different in both strategy
> S> and design.
>
> This is my very first concern: is Turbine a liability to Jetspeed?
> I have been looking at Turbine for a few days now, and it strikes
> me as a brittle design; there are two areas where this shows:
>
> 1. You can't CLEANLY have more than one application based on Turbine
> running concurrently.
You can without any trouble run 2 apps concurrently with Turbine, just
make 2 turbine aliases with different resource files.
However, it has not be designed to allow 2 apps executing in the same web
page which *is* a liability to Jetspeed operation if we want to recommend
Turbine as basic portlet development framework. It's however quite easy
to solve this issue within Turbine by allowing "system" parameters to be
namespaced.
> 2. The basic page layout (top navigation, bottom navigation, etc.)
> is dictated by the framework (please correct me if I'm wrong).
>
I don't understand what you mean but I think it's enough to say that
you can build *any* kind of layout with Turbine. It just provides tools,
if you don't need them, don't use them...
> The Cocoon project has even gone as far as taking parts of Turbine
> (like the DB connection pool) and integrating that into Cocoon. So,
> it looks to me like Turbine is not perceived as a good generic app.
> framework (at least by the Cocoon people).
I would rather say that it means the Cocoon development team recognized that
the database pool code was good and decided to use it. As stefano said, the
2 frameworks follow very different strategy and it's impossible to fully
integrate both. It does not mean that Turbine is bad, just that it does not
work easily with Cocoon.
> What are the thoughts of
> the Jetspeed people in this regard? How heavy is the dependence of
> Jetspeed on Turbine? If the mentioned deficiencies of Turbine were
> never resolved, do the Jetspeed people see a clear migration path
> to a non-Turbine version? Has this issue ever come up?
>
This has come up several times especially in the Cocoon mailist (just
search the archives). Jetspeed is currently very dependent on Turbine
but at the same time, aims to fully explore XML possibilities for building a
portal. As such, integration into the cocoon framework is important since it
will probably be *the* XML publishing framework in the next years.
We're actively following the Coccon framework development and also trying
to modify the current Jetspeed application to better abstract some Turbine-specific
features (such as RunData...).
> S> > > > Jetspeed -> based on *both* Turbine and Cocoon
>
> G> > Ok, here I have my doubts: it seems to me that Jetspeed uses
> G> > Cocoon as an API, something explicitly "forbidden" in the Cocoon
> G> > guidelines. Is this correct?
>
> S> Yes. Kevin Burton is fully aware of this and when Cocoon2 is ready the
> S> Jetspeed project will fix this design flaw.
>
> Do the Jetspeed designers agree with this assessment? If yes, how will
> this "flaw" be "fixed" in the future? Do the Jetspeed people see more
> opportunities of integrating Jetspeed and Cocoon in a framework-like
> piece of software, designed to build web apps that have a portal flavor?
>
Well, it's not currently a "design flaw" because cocoon 1.x doesn't allow
anything else ;)
Integration into Cocoon2 will probably mean the user layout part of Jetspeed
will be rewritten as a Cocoon taglib and a sitemap. Maybe we'll also keep
the turbine layout system and provide 2 user front-end interface.
Administration and backend features will probably stick to Turbine for some
time though.
> S> > > > Cocoon -> servlet and command line (based on Xerces,
> S> > > > Xalan, Fop, Turbine-pool)
>
> G> > Ok, here is the (to me) X million dollars question: if I were
> G> > to build an application that:
> G> >
> G> > * is web based
> G> > * has certain traits of a portal site (a la www.eurofootball.com)
> G> > * uses XML to provide content, and XSL to present it
> G> >
> G> > and had to choose between all of the frameworks available
> G> > (turbine, struts, xang [is this one even an alternative?],
> G> > jetspeed, cocoon), which one should I use? Or, to put it
> G> > more bluntly, which one would you, Stefano, use? 8-)
>
> S> Jetspeed is cool but I don't like its current design.
>
Jetspeed is not an application or publication framework. I don't see
*anybody* building a whole site with jetspeed. Jetspeeed is used to
aggregate contents and publish this in one or several screens.
> I concur with Stefano: Jetspeed is VERY cool. Cocoon is also VERY
> cool. I would love to use both, but don't perceive clearly yet where
> each one's responsibilities and scope end. I would love to be able
> to do something like this:
>
> * A set of (concurrent) portals, each based on Jetspeed, each with
> its own page layout, that integrate different sources of information
> using the Jetspeed metaphor. The keyword, that seems to invalidate
> Turbine (and hence Jetspeed) is "concurrent".
>
Nope, should work perfectly. If you're using Tomcat, just define several
contexts...
> * Some (or all) of these portals can also be used to access web apps
> written with Cocoon. Would the current design of Jetspeed be enough
> to support this paradigm? I'm concerned with the fact that, is you
> are running Jetspeed, you can't simply serve any XML content with
> Cocoon, because that breaks the way Jetspeed handles some of its
> content.
>
Jetspeed is designed for this kind of things. Provide a synthetic and
customizable link conservatory towards your other apps or pages.
If you plan to use Cocoon 2 to publish the rest of your site, the main
liability in the current Jetspeed design is that since we're based on Turbine
you won't be able to fully leverage the Cocoon sitemap to design your site,
which is a shame.
I don't understand what you mean by "you can't simply serve any XML content with
Cocoon, because that breaks the way Jetspeed handles some of its content.".
Can you give us an example where you see an issue ?
> * All of this running on one (or more) servers, with just one instance
> of each piece of software involved (Turbine?, Jetspeed, Cocoon,
> auxiliary software such as Xalan, Xerces, etc.) installed on the
> server. The basic server software will very likely be Apache + Tomcat.
>
You should not aim to use a single instance of Turbine since it's not an app, it's
an application framework. You should have as many "instances" of Turbine as you have
applications.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
