> "Diethelm Guallar, Gonzalo" wrote:
> > 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-)
>
Correct. The only thing as Jon pointed out is that these components
currently work very well in the Turbine environment so the Turbine
team has *no* incentive to port them to the Avalon project. In effect,
these tools will effectively be ported over Cocoon and/or Avalon only
when someone will have a compelling reason to do so.
> > 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...
>
Cocoon 1.x is slow and very hard to manage. It's a proof of concept piece of
software. When we talk about Cocoon in this list we only consider Cocoon 2.
Cocoon 1.x is an improved XSLT processor with server-side processing capabilities.
> >
> > 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?
>
No, the use of some "reserved" parameters by Turbine apps (mainly "screen"
and "action") which makes it currently quite difficult to host several
Turbine apps within portlets displayed on the same Jetspeed portal screen.
> 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?
>
Sure.
> > > 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?
>
That's what *you* have to decide, based on such parameters as what are your
team main skills, what is your timeframe for development, what performance and
usage is expected, etc...
> > > 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...
>
No. Just some parts of Jetspeed will be modified to smoothly integrate into
the cocoon2 publication framework.
> > 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?
>
Using taglibs you *can* port most of the Turbine tools for Cocoon use, but we
*won't* do it because this not the project goal. We're not trying to bridge
these environments, we're building an EIP... ;)
Jetspeed in currently composed of 2 main components :
- a syndication engine which aggregates externam data sources
- a layout system which displays "portlet" contents to the user
A portlet is a piece either linked to a syndicated data source (for example
Slashdot RSS feed) or a local data source/application (local Turbine app, cocoon
XSP page, whatever you care to code...)
The layout of a portal page is defined by what we call a PSML (Portal Site Markup
Language) file.
In the Turbine processing model (current), when a user connects to the portal
the following steps occur:
- Turbine selects the appropriate screen (and maybe action) based on the request
parameters
- if it's a Jetspeed screen, Jetspeed selects a PSML file to display based on the
request (it's done by the Profiler)
- then Jetspeed builds the output of this screen by gathering the content of all
the portlet referenced in the PSML file, decorating them with titlebars (this is
what PortletControls are for) and using a layout strategy to organize the page
(this is the role of the PortletController)
In the Cocoon2 model :
- The sitemap selects, based on the URL requested, a PSML file to process
- the PSML file may contain tags that are pre-processed by non-Jetspeed taglibs
(for example SQL queries, etc...)
- The tags of the PSML are processed by the Jetspeed taglibs (XSP) and replaced
by the portlet content, decorated with the portlet controls and organized by the
portlet controller
- the result of this may be post-processed by other Cocoon taglibs (sitemap
configuration)
- the document is output to the user.
In every case, thi sonly concerns the layout part of jetspeed and not the
syndication structure.
> > 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...
>
This is not current anymore abd was only a common configuration issue in
Jetspeed 1.1.
> > 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...
>
I'm not saying you have to duplicate jars, you should just usually
run as many *instances* of Turbine as you have applications in order
to be able to configure them independantly. If you don't need separation
of contexts, what's your point ?
--
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]
