> > 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-)
> 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?
> 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? I know Cocoon 2
is alpha at this point...
> 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 theoretical 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.
Any pointers to examples, tutorials or real-world apps built
with Turbine? Is a template language (Webmacro, etc.) REQUIRED
in order to use Turbine? If yes, what seems to be the preferred
choice? Are there any licensing issues with these languages?
> > 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.
Ok, this refers to the issue of sharing session information
and user authentication between the Turbine apps, right?
> > 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...
I meant that, from the documentation, I gathered I had to follow
a "top navigation bar, bottom navigation bar, middle content
area, etc." layout in my pages. Jeff Brekke pointed out this is
not correct, through the use of a templating language (Webmacro).
Do you concur?
> > 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.
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?
> > 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...
> We're actively following the Cocoon framework development and
> also trying
> to modify the current Jetspeed application to better abstract
> some Turbine-specific
> features (such as RunData...).
Don't know enough to understand that assertion...
> 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.
Interesting. You have mentioned Cocoon 2's taglibs and sitemaps
a couple of times. I don't know what a sitemap is, but it seems
to me that using taglibs and sitemaps you could offer the equivalent
of Turbine's functionality in a pure Cocoon(2) environment; therefore,
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?
> 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 ?
I meant that the default Cocoon installation expects to handle
all requests for "*.xml", but Jetspeed will also want to handle
XML files itself. I think I read about this somewhere, but I'm
not certain where it was...
> 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.
Ok, so what you are saying is that each time I deploy an app
built on Turbine (say, Jetspeed and Jyve) I should have separate
JAR files (why?) and TurbineResources.properties files, right?
The multiple properties files look like a pain in the rear,
specially if you have to configure things like DB drivers for
each of them...
> Rapha�l Luta - [EMAIL PROTECTED]
Many thanks for your valuable input!
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
If this mail is in HTML format, blame Exchange Server: Q222508
