cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: shared object Proposal
Date Tue, 11 Jan 2000 19:48:05 GMT
Michael Engelhart wrote:
> 
> on 1/11/00 8:05 AM, Brett McLaughlin at bmclaugh@algx.net wrote:
> 
> > I'm +1 for the idea, -1 on your implementation (nothing personal ;-) ).
> > I think things like this do not belong (coded) in Cocoon.  They are part
> > of a large application frameworks, like Turbine (incidentally, where we
> > have implemented something similar to what you outlined).  Those
> > frameworks, which are designed to use things like Cocoon (Cocoon, keep
> > in mind, is a _publishing_ framework, not an application framework),
> > should handle services.
> >
> > So maybe take a look at Turbine, this is there, and then Turbine can
> > certainly use Cocoon for screen processing.
> >
> > -Brett
> nothing taken personally ;-)  Thanks for looking at the proposal.
> 
> In some ways I agree but don't you think that Turbine could be considered
> overkill for smaller web applications?  Things like database access (and
> thus connection pools shared objects) are very common if not a requirement
> on even the smallest intranet that may not have the need for something like
> Turbine.

Both are good points.

Also, turbine should be included into something bigger than that, the
Avalon framework which includes all the required design patterns. Cocoon
should itself be an Avalon block.

But the problem remains: designing such a complex architecture from
scratch is _very_ difficult and error prone. Cocoon uses some of those
patterns and tried to come up with a working solutions.

I know turbine people are lacking the publishing features of Cocoon
while Cocoon people are lacking the services Turbine does.

Turbine people believe Cocoon is a piece of their framework, but this is
totally wrong. There is no such distintion as "application vs.
publishing" framework. Because they mostly overlap in dynamic content
generation.

So, what I want to see is NOT Cocoon called by Turbine, or turbine code
called by Cocoon, but a _well_designed_ framework that includes both.

What Micheal proposed looks a lot like a light-avalon. This is the road
to follow, IMO, but, unfortunately, I don't have that much time to
investigate what is needed to make Cocoon + Turbine unite.

Any thoughts?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message