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 Thu, 30 Mar 2000 18:06:09 GMT
Hi all,

I needed some time to look at Cocoon 2, Castor etc. Here are my conclusions...

> > 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?)
> take a look at it and tell us what you think:

Looks interesting, but at the moment it's actually a "feature-overkill" for our
purposes and I think, I currently won't have the time to integrate our
shop-software with Castor. On the other hand, I have our old WeAF sources at
hand, which I only need to modify somewhat to get it running on Cocoon, which
is much simpler for me!

However, for the future, Castor & Co. is probably the way for us to go. (Like I
said: I would be glad, if we could get rid of our home-written WeAF altogether

> > >> 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 assume, this means: "Do it!".
> > 
> > >> I skimmed through the Cocoon sources, and I think I know now how to do
> > 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
> > >> 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.
> yes. Niclas expressed the need for internal subrequesting and I have
> different feelings about them.
> We already agreed on using _sort_of_ internal subrequesting to do XSP
> compilation: we use one pipeline to generate the java bytecode out of
> XML pages (thru XSP components), then instantiate that bytecode as a
> generator for the subsequent calls.
> So, it is -not- what you wanted to do (if I understood correctly), but
> rather willing to "include" the output of another pipeline into your
> request.


> Now... you could place pipeline information inside your page, and this
> is a -1 from me. But if you want to do something like
> <page>
>  <cocoon:include src=./banner" force-user-agent="cocoon">
>  ....
> </page>
> or something like this, I see no problems. 

This was exactly what I thought about! (A typical example would be page-headers
and -footers, navigation-panels etc. which are reused across several pages --
no need to say that the "copy-and-paste-approach" is not really desirable for
such stuff. :-)

> We already thought about implementing the XInclude spec... I think this
> is better than having cocoon-specific namespaces but it might not have
> all the semantics we'd like to have like encoding, fake user-agent,
> parameters and such...

I don't know (yet ;-) XInclude, but in any case, I would also vote to use an
existing and established specification, rather than to do something

> what do others think about this?
> > >> 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!
> Look into Catalina (which is Craig's own try for Things
> like Tyrex ( have been using these tomcat-specific
> hooks to implement session transaction on top of tomcat. They were
> designed to do what you wanted to do... I believe.

I couldn't find something about "Catalina" or these Tomcat-Hooks -- can someone
give me a hint where to search?

> > 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)!
> No problem. We'll support you as much as it is possible for us.

Thanks in advance! On the other hand, I don't want to stress you with my tight
timelines. I think it's much better, _you_ concentrate on a clean Cocoon 2
design and _I_ try to get my project running in time. 

> > 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).
> Sounds like an awesome plan, Zisch... welcome aboard :)

Yeah, well ... I actually have no doubt it _could_ be done, but it's always the
same thing with these commercial projects: you never have the time to do
something right, and in the end most of the software you write ends up in a
bunch of dirty hacks. :-( :-( :-(

I looked through the Cocoon 2 sources and my conclusion is, that it would
probably need much more work for me to get a clean implementation of the
inclusion-functionality into it, than doing some dirty hacks on Cocoon 1. (I
think, I can get away with hacking the Engine class in Cocoon 1, while the
architecture of Cocoon 2 is -- no wonder -- quite different and somewhat more

So, this is my plan:

I intend to do the hacks on Cocoon 1.7 (page-inclusion, probably also the
event-hooks etc.) which I originally planned to do, to get our shop-software
working on Cocoon as soon as possible. Since it would be impossible
(page-inclusion) or unwanted (hooks) to include these hacks into Cocoon 2, I
don't even need to do something clean or clever -- it just has to work, so that
our customer is satisfied with it ;-), which makes it somewhat easier for me,
to do it in time.

If someone really would like to get these hacks, just send me an email. But I
absolutely want to make clear, that these are temporary, dirty hacks to get our
own project finished in time! It's not in any way an attempt to fork Cocoon, and
I will also not have the time to document these hacks or give otherwise
support! (Therefore, I won't post the modified source or otherwise make it
public, unless someone requests them.)

I'm really not happy about this, but I don't see any other possiblity for our
first step with Cocoon. Since this project is critical for the future
existence of our company, I cannot risk any experiments at this time! If no bad
things happen, we should be able to finish the project in time whithin the next
three months.

During this time, I will try to follow the Cocoon mailing lists, understand
the Cocoon 2 source code, learn more about Castor, Tomcat etc.

I hope that I will then see, how to make the next step, which should be porting
our shop-software from the hacked Cocoon 1 to a "regular" Cocoon 2, probably
using the Tomcat-Hooks, Castor and the like.

If no one implements the inclusion-functionality up to then, I should then have
the time to do a clean implementation for Cocoon 2 (probably based on XInclude).

But I actually don't want to make any promises at the moment, since at the end
of June my three-months summer-vacation start, which I really long for, since
the last three years in this startup-company were somewhat tough. I probably
should spend some time of the vacations for non-IT-related stuff (for example
for my girl-friend, who was very patient with me the last few years ;-),
however, since my job is also my hobby, I think, that I will use one or the
other hour to contribute to Cocoon.

After that vacation, I'll start to study IT at the ETH Zurich. (After doing
software-engineering in practice for the last years, I thought, it would be
nice to actually _learn_ it. :-) I will also have to do some work for
NetHorizon, to make the money I need to live. Last but not least, I thought
about eventually starting my own Open-Source project. (For example, I really
would like a Rational-Rose-like tool, but written in Java and with an
Open-Source license. What I found on the web last time I searched, didn't
really satisfied me, so maybe, I'll write my own Open-Source-RR in Java.)

I'm just telling you all this to point out, that I cannot make any promises
about how much I can and will contribute to Cocoon in the future, although I
surely _want_ to contribute as much as possible. And since NetHorizon will
certainly use Cocoon for most of its future projects, I will certainly stay in
touch with it.


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

View raw message