> "Diethelm Guallar, Gonzalo" wrote:
>
> > > 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... :)
>
> Ok, phew!
>
> > > 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
> > reusability 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...).
>
> These all sound great. I guess the obvious question, given that
> at least part of these components (the DB connection pool) was
> "ported" to Cocoon, is: why don't we make these useful components
> available at a lower level, so that they can be used by Turbine
> and Cocoon (and others)? (Not that I'm volunteering right now... 8-)
Yes. This should all be done with Avalon. There has been a lot of talk
here but no one has taken the initiative. Cocoon 2.0 is doing this and
I want to do it shortly for Jetspeed.
> > 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.
>
> Ok, but there is no reason why the same concepts (and even
> implementations) of these tools in Turbine could not be adapted
> to Cocoon, right?
Correct.. this is the idea!
> > Alpha stage currently so we don't know yet how it will
> > compare to Turbine performance wise.
>
> Is Cocoon 1.7.x and 1.8 considered alpha?
No... stable.
<snip>
> > 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.
>
> I guess this is the crux of the issue to me. I can see my apps
> will require user authentication, session management, etc., so
> it looks like Turbine would be a good fit. But we have also
> made the decision to provide all content with XML, and use XSL
> for presentation; even more, we would really like to separate
> the groups working on the logic, content (data) and presentation,
> and Cocoon looks like a very good fit for this. How could I mix
> both alternatives?
Use Jetspeed portlets. You get all this for free. :) The only
drawback is that you are stuck with Turbine layout. It is possible to
do whatever you want with this but you have to write Java or stick with
the current implementations and PSML.
I need to start the path down a CocoonPortletController. It should be
impossible but just something that everyone has been arguing about....
> > > 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.
>
> Just to clarify: are you saying that Jetspeed will eventually move
> from a Turbine-based approach to a Cocoon-based one? Maybe this is
> simplifying matters too much...
yes... at least for layout.
<snip>
> you COULD have a Jetspeed based on Cocoon only, and with all the
> functionality offered today by Turbine ported to Cocoon. Am I
> totally wrong here?
YES. Turbine is a requirement. Even from a lower level.
<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]
