Rapha�l Luta wrote:
<snip>
>
> 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...).
Another thing to point out. Turbine is SOLID! VERY stable. Cocoon 1.x
has known performance issues and if you stick to conventional
publication with Turbine you can have a really productive team of
programmers.
> 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.
Hm.. That might be a good idea. This way if someone wants to use the
Turbine layout we won't exclude them. They can choose their layout
system for implementation. This way there will be no Sitemap vs Turbine
Layout argument within Jetspeed :) ... of course this only matters if
it is technically possible.
> > 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.
Well... I don't know why anyone would want to base on Cocoon 2.0 today.
True we would loose sitemap support but that is OK. Cocoon 2.0 isn't
stable. By the time Cocoon 2.0 ships we will follow up with Jetspeed
2.0 :)
<snip>
--
Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
--
--------------------------------------------------------------
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]
