Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Message-ID: <38E0A46B.451D0860@apache.org>
Date: Tue, 28 Mar 2000 14:24:11 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
CC: Cocoon Users <cocoon-users@xml.apache.org>
Subject: Re: Some Cocoon-Hacks [Was: Re: Best way to include ouitput of one
 page
 into another?]
References: <200003271706.TAA23112@dalla.horizon.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm copying this to cocoon-dev since it should really belong there.

Crossposting is normally bad, but I don't know if Matthias is subscribed
there and this will give him the time to do it.

"Zisch (Matthias Meier), NetHorizon AG" wrote:
> 
> Content-MD5: SzWLgMS0js0jny122p3vsA==
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> 
> Hi all,
> 
> I'm very new to Cocoon. However when I had a look at it, I was really impressed.
> The basic ideas are simple but very powerful. (Actually it's the first time, I
> really understand the power of XML!)

thanks.
 
> We (that is <http://www.horizon.ch/>) develop mostly e-commerce-applications and
> currently use our own framework, called "WeAF" (Web Application Framework) for
> that purpose. (There is a website dedicated to WeAF, <http://www.weaf.com/>, in
> case you are curious. But I really don't recommend the site -- it's VERY VERY
> out of date and should soon be obsolete!)

ok
 
> We decided now to change to Cocoon as the base for our next release of WeAF.
> (There will still be a WeAF since there is a number of features in it, which are
> not part of Cocoon and probably never should be, since they are quite
> specialized for the "style" of Web-Application that we develop, or solve
> problems -- like resource-loading, DB-interfacing etc. -- which are not actually
> part of Cocoon's job.)

I totally disagree. In fact we are working toward Castor integration
that is exactly about resource-loading and DB-interfacing... You might
well do your WeAF stuff, but you might find yourself overlapping with
Cocoon and even basing your core on its code.

I think it makes much more sense to collaborate. But, this is my
personal vision, of course.
 
> However, there are also some "general purpose"-features which I will "port" to
> Cocoon. One of these features is dynamic inclusion. However, rather than to
> dynamically include static XML from files, I would like to include the result of
> a request to another page which also gets served by Cocoon (something like an
> "internal subrequest").

Internal subrequests... old tune.
 
> Since I do not want to format the result of the "subrequest" as a character
> stream and re-parse it again to a DOM tree, I intend to hack Cocoon, so that it
> will be possible to make "internal subrequests" which return their results as
> DOM-tree (that is, before the formatter does his work). (I don't think, that
> this is yet possible, for example using the util: taglib, is it?)

I honestly don't know (ricardo?) but I would think not.
 
> With this hack, it should be possible to "make a request" by calling the
> appropriate Java method of the Cocoon-Engine (using a probably modified
> Servlet-Request-Object) from within an XSP-page and include the returned
> DOM-tree (or parts of it) into the DOM-tree of the document which was requested
> in the first place.

yeah
 
> I skimmed through the Cocoon sources, and I think I know now how to do it. Are
> there any objections against this intention? 

one: don't do it on Cocoon 1.x

> Other comments? (Maybe, I violate
> some basic design-concepts which I didn't know up to now? Maybe there is a
> better/simpler way to do it?) 

Cocoon 1.x if feature-frozen: means that even if you donate the code, I
won't add it. This is to _suggest_ people to work on Cocoon2.

> If not, I will just implement it (and send the
> changes to the developers mailing list, hoping that they will make it part of
> the regular Cocoon distribution some day ;-).

Well, nothing can stop you if you really want to do it, but I would
advise you against doing it because you would throw away your time.
 
> BTW: I convinced my boss, to release the complete WeAF 2 framework (not only the
> changed Cocoon classes) as open source (probably Apache license, maybe GNU). I
> will post corresponding infos to this mailing-list as soon as something usable
> is available.

Collaboration, rather than forking, is always my suggestion. But who am
I to suggest?
 
> There is yet another hack which I need/intend to do: when starting the
> web-application (i.e. the Cocoon servlet), I need to initialize arbitrary helper
> objects which will then be available for the whole application, i.e. all
> XSP-pages and other components (for example to implement global caches,
> connection-pools etc.). Some of these helpers will also need to listen to every
> request and eventually redirect (using "internal subrequests") or otherwise
> "pre-process" the request (for example to check access to certain pages etc.).
> Last but not least, some of the helpers will need to know when the application
> shuts down (for example to cleanly close pooled JDBC connections etc.).

This should be a servlet engine thing.
 
> I intend to "generalize" the current way (as of Cocoon 1.7) how producers,
> processors and formatters are created to allow creation (and storage in the
> ServletContext) of objects of any class. Further I will implement some hooks, so
> that such global objects (or any other object ;-) may register themselves as
> listeners for certain events (namely incoming requests, completion of requests
> and shutdown of the servlet engine, maybe also for creation and destruction of
> sessions).
> 
> Again: Objections? Comments? Better ways to do it??

Tomcat provides exactly such hooks. I believe that Cocoon, being a
servlet should "inherit" all the features that are necessary to
servlets... but I admit I haven't really thought about it that much, and
I'm always open to alternatives if they are necessary.
 
> One last thought: it seems to me, that the response for any request gets cached
> as a String. This is true, even for pages which are generated by
> producers/processors which always re-generate the response (p.e. XSP).
> It would be quite easy to specify an additional method for Processor's (resp.
> Producer's) -- something like 'boolean isCacheable()' -- to allow Producers and
> Processors to signal to the engine that responses by that Producer/Processor
> shall never be cached because the cached responses get discarded anyway upon the
> next request for the same page. The needed changes to the Engine class would be
> minimal and implementation of 'isCacheable()' should be trivial (for the XSP
> engine: "return false;" ;-).

Good idea. No problem in adding this to Cocoon2. What do others think on
this?
 
> To the Cocoon-Developers: I understand, that you currently rather work on Cocoon
> 2.0 than to optimize the 1.x version. Probably you are also aware of this
> optimization-possibility, and I expect, it will probably be part of Cocoon 2.0
> (or be obsolete in Cocoon 2.0). If so, just ignore these two paragraphs. If not,
> I hope my statement helps to improve Cocoon further.

Oh, you definately made great comments and proposed good ideas. I would
love to see more people involved in the actualy code writing of Cocoon2
and I welcome you on board if you want to help us.

But, please, try not to fork our project or to work on Cocoon1 since
this would, IMO, waste your efforts and create harm to the project.

Instead, direct collaboration would help everyone.

What do you think?
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------