cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zisch (Matthias Meier), NetHorizon AG" <>
Subject Re: Some Cocoon-Hacks [Was: Re: Best way to include ouitput of one page into another?]
Date Tue, 28 Mar 2000 14:41:50 GMT
Hi Cocoon-Developers (and especially Stefano ;-),

>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.

Yes, I'm subscribed, but only for two days now. I actually wanted to learn more 
about Cocoon before posting my own ideas, but I saw the discussion about 
page-including in the users list, so I just took my chance to contribute.

BTW: All my friends call me "Zisch", but if you prefer "Matthias" it's ok. :-)

>"Zisch (Matthias Meier), NetHorizon AG" wrote:
>> Content-MD5: SzWLgMS0js0jny122p3vsA==
>> X-Spam-Rating: 1.6.2 0/1000/N
[ ... uninteresting parts deleted! ...]
>> 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 
>> 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 
>> 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.

I totally agree! Seems as if I should have a look at Cocoon 2! (Never heard of 
"Castor" -- can someone give me a short explanation?)

>> However, there are also some "general purpose"-features which I will "port" 
>> 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 
>> a request to another page which also gets served by Cocoon (something like an
>> "internal subrequest").
>Internal subrequests... old tune.

Sorry, if I tell you stories which you know already ;-) As I said: I'm very new 
to Cocoon.

>> 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 
>> 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 
>> in the first place.

I assume, this means: "Do it!".

>> I skimmed through the Cocoon sources, and I think I know now how to do it. 
>> 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.

OK. Cocoon 2 then.

[... parts deleted ...] 
>> 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 
>> 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 
>> request and eventually redirect (using "internal subrequests") or otherwise
>> "pre-process" the request (for example to check access to certain pages 
>> Last but not least, some of the helpers will need to know when the 
>> 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, 
>> that such global objects (or any other object ;-) may register themselves as
>> listeners for certain events (namely incoming requests, completion of 
>> and shutdown of the servlet engine, maybe also for creation and destruction 
>> 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.

We are currently using JServ, so I was not aware of this possibility in Tomcat. 
I will certainly have a look at it. Thanks for pointing it out!

>> One last thought: it seems to me, that the response for any request gets 
>> 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 
>> Processors to signal to the engine that responses by that Producer/Processor
>> shall never be cached because the cached responses get discarded anyway upon 
>> next request for the same page. The needed changes to the Engine class would 
>> 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
>> To the Cocoon-Developers: I understand, that you currently rather work on 
>> 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 
>> (or be obsolete in Cocoon 2.0). If so, just ignore these two paragraphs. If 
>> 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?

I absolutely agree!

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

Thanks for the invitation! I surely want to contribute to Cocoon and have really 
no intention to fork the project!

It was never a primary goal of our company to develop our own 
web-application-frameworks, but since we needed one when we started to develop 
our shop-applications and couldn't find one (at least not one that was 
Java-based -- this was around three or four years ago, long before JSP got 
public), we decided to do it ourselves. I would really be glad, if there will 
someday be no need anymore for our WeAF and we could totally replace it with 
Cocoon (and maybe other Open Source components)!

My only problem is, that I have to deliver a working release of our 
web-shop-package whithin the next three months! And this release shall be based 
on Cocoon. Since we are a really small company with currently seven employees 
(three of them Java-Developers) and no big investor in the background, we need 
to constantly make some money with software-projects. Therefore I will need to 
concentrate on the issues needed to get our shop-package running (and maybe even 
implement some things which will later get obsolete again, to allow a smooth 
transition of the shop-package)!

However, I will have an intense look at Cocoon 2, Tomcat and Castor (whatever 
this is ;-) and see if we could completely get rid of WeAF (probably 
contributing some features of it to these projects).


| Matthias Meier  |
| NetHorizon AG     |
|                                                  |
| City Server of Winterthur |
| Swiss Internet CD Shop |
| Web Application Framework |

View raw message