(please don't send html mail)
<snip>
> 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.
:)
> Let me explain up front that I have to build a bunch of
> web applications that will finally interact with legacy
> back-end systems, and have spent a few weeks perusing
> several alternatives for this job. The applications will
> very likely have a "portal" flavor, hence my interest in
> Jetspeed.
>
> 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.
yes.
> 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.
Wrong. There is a common misconception that Turbine -> no-XML and you
are forced to use its Page/Screen/Action/Layout framework. While this
can be cool you can use Turbine for database connection pooling,
scheduling, database persistence, etc under Cocoon. Jetspeed is doing
this now BTW.
> This is my very first concern: is Turbine a liability to Jetspeed?
Only in one area. We don't have perfect XML integration. Jetspeed 2.0
(which will be based on Cocoon 2.0 and sitemap, etc) will fix this.
> 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.
yes you can... different servlet contexts.
> 2. The basic page layout (top navigation, bottom navigation, etc.)
> is dictated by the framework (please correct me if I'm wrong).
No. You just have to provide an initialization for Turbine. This isn't
*totally* perfect. I sent a proposal (but I haven't had time to
implement) for doing this. Someone else did the code and shortly I will
go back in to see if we can rework this.
> 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). 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?
There has been open discussion about this. Turbine will never go away
from Jetspeed. One of the reasons everyone created Turbine was that at
the time writing this stuff under Jetspeed was stupid. There were
conversations about this on various mailing lists and the whole gang
based this on code Jon already had. This provides a significant
advantage to Jetspeed, we can focus on Jetspeed goals and we don't have
to write connection pools, etc.
> 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.
I don't consider it a design flaw. Just something that isn't perfect.
Cocoon 1.x wasn't ready for what we want to do. Cocoon 2.0 with
Sitemap, offline, etc will work well.
> 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?
> 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.
What does this mean? It is not perfect but you can use Cocoon and not
even have to think about it :)
I mean if you think of it from an XML perspective, Jetspeed just pushes
content through Cocoon. If you need bulk RSS syndication Jetspeed is
the way to go. If you don't need this maybe you should go with Cocoon.
> 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:
In Jetspeed 2.0 the boundaries will be more obvious:
<content sources (OCS, RSS, etc)> -> Jetspeed -> Cocoon
You can use Sitemap, etc. The PortletController thing may still be
there but will just be Cocoon 2.0... maybe it will even be removed.
<snipo>
> * 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.
Huh? Yeah you can... you can serve just fine with Cocoon :)
--
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]
