cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: shared object Proposal
Date Wed, 12 Jan 2000 14:20:43 GMT
Brett McLaughlin wrote:
> Stefano Mazzocchi wrote:
> >
> > Michael Engelhart wrote:
> > >
> > > on 1/11/00 8:05 AM, Brett McLaughlin at 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.
> OK, in theory I can go with this, but in practice, as you pointed out,
> this seems to be a ways off :-(

No, just way too early in time. Cocoon was believed 6/8 months ahead of
time when I started it out. I believe Avalon is 2 years ahead of time.
> >
> > 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.
> More than the actual services, I am more concerned that Cocoon does not
> have a services _architecture_ which Turbine does.

Good point. I agree.
> >
> > 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.
> Really?  Which Turbine people are those ;-)  


> Since I'm the only one
> floating around it seems, I don't agree with that... I do think Cocoon
> is separate from Turbine, just as say FreeMarker or WebMacro are... but
> I do think it will generally be a matter of Turbine calling Cocoon
> (using Cocoon) and not the other way around.

No, well... yes, in some sense.

Here's what I mean:

1) first case: Turbine calls Cocoon

web server -> servlet engine -> turbine -> cocoon

this is currently possible and allows turbine to generate pages using
Cocoon as an API.

2) second case: Cocoon calls Turbine

web server -> servlet engine -> cocoon -> turbine

this is possible but not implemented. This allows in practive so use
Cocoon sitemap and turbine services. Most turbine people don't agree.

3) third case:

web server -> servlet engine -> something -+--> cocoon
                                           |       |
                                           +--> turbine

4) forth case:

web server -> servlet engine -> cocoon/turbine

but I don't have the energy to fight this battle.

> > 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.
> Hmmmm... what you are proposing is what I originally proposed Turbine
> would be.  I got ... ramrodded ... because Jon was set on it being a
> Dash derivitive, and most people wanted working code.  So I sacraficed a
> lot of design to get a viable project started.  

And i agreed with that.

> However, I agree with you here Stefano, in theory. But is Avalon 
> what you are certainly
> referring to) close enough to useful to be that answer?  If not, I have
> to say Turbine is fairly close to that structure.  I am close to adding
> significant services architecture allowing things like XML-RPC for
> remote services (without any user intervention), etc.  These belong to
> the framework, not to an application.... if you honestly think Avalon is
> closer, I can switch gears and incorporate it there.

No, avalon doesn't deal with those things, it's a step below.
> >
> > 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.
> Again, I'm not sure I understand what you consider "unite".  Obviously
> with the changes in CVS now, Turbine screens/control/whatever can use
> Cocoon for generation. Of course there is not the integration so tight
> that things like sitemap might sometimes apply targets to Turbine, etc.
> Is that more what you are saying?  


> If so, then we are looking at a wider
> design (which I am for) but one that is not close to being realized
> (which I am not so much for).  Worst case, we _have_ to have Cocoon 2
> and Turbine 1 (final) cooperating.  One way or another, this is a must
> in my mind.  Otherwise the ideas will lose interest....

Totally, but I'm not sure how this goes.
> I like the idea of a generic ServiceBroker, if you will.  This broker
> has the responsibility of delegating requests for a given Service.  In
> this general scenario, not only would things like Connection Pooling and
> JNDI Contexts be services, but actual engines themselves.  For example,
> I could request use of the Cocoon services, the Turbine services (with
> Turbine retooled), etc.  So in essence an application would have to
> write their own custom control structure, but for all the blocks, issue
> requests to the service broker.  In my mind, these services are _never_
> cast to what they are and have specific methods.  Instead, you have
> something like:
> public interface Service {
>   public String getName();
>   public void setName();
>   public void init(Object ob);
>   public Object get();
>   public boolean execute() throws AppException;
>   public void destroy(Object ob);
> }
> These general interfaces allow you tremendous flexibility!  You could
> use the Service Manager to get a connection, for example:
> Service connectionService = ServiceManager.getService("connection");
> connectionService.init(jdbcURL);
> Connection con = connectionService.get();
> // Use the connecction
> connectionService.destroy(con);
> This is very clean.  It allows the service "provider" to do things as
> simple as returning a plain connection, or as complex as very advanced
> connection pooling, all without the user of the framework having to
> worry about it.
> In the same fashion, remote services become easy.  Based on a property,
> a request to getService() on a service that should be executed remotely
> would actually return an instance of XMLRPCService, unknown to the
> user.  The servce manager would load up the service instance with
> information about the service and parameters to call (set in properties
> files, for example).  Then when the user calls execute(), the
> XMLRPCService would proxy the reequest across the network to the service
> remotely.  Of course this is transparant because of the clean,
> non-casted Service interface.

Hmmmm, I see, yours is a special non-casted version of a light Avalon.

> In the same way:
> Service cocoonService = ServiceManager.getService("cocoon");
> cocoonService.init(myServletRequest);
> cocoonService.execute();
> And suddenly, you have output.  This isn't what the final workings would
> be, I think maybe instead you could actually init() the Cocoon service
> with a sitemap fragment or something, but it's the idea that I'm driving
> at....
> So you wanna tear me up Stefano, or do you like this ;-)

Currently Cocoon is going in this direction:

 request --> cocoon -> sitemap -> cocoon-engine

while turbine is going in this direction:

 request -> turbine -> ??? -> cocoon-engine

they do not overlap, yet, but they are starting to do so.

This will make integration a pain in the ass.

I'll come up with something soon...

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

View raw message