cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Some Cocoon-Hacks [Was: Re: Best way to include ouitput of one page into another?]
Date Tue, 28 Mar 2000 21:28:48 GMT
"Zisch (Matthias Meier), NetHorizon AG" wrote:
> 
> Content-MD5: 0U3ZJ677OKiQm7IIxaJNnQ==
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> 
> 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.

Don't worry, no problem at all.
 
> BTW: All my friends call me "Zisch", but if you prefer "Matthias" it's ok. :-)

fine with me, Zisch :)
 
> >"Zisch (Matthias Meier), NetHorizon AG" wrote:
> >>
> >> Content-MD5: SzWLgMS0js0jny122p3vsA==
> >> X-Spam-Rating: locus.apache.org 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
> 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.
> 
> 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: castor.exolab.org
 
> >> 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.
> 
> Sorry, if I tell you stories which you know already ;-) As I said: I'm very new
> to Cocoon.

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

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

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 Tomcat.next). Things
like Tyrex (tyrex.exolab.org) 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.
 

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

Feels good to hear that!
 
> 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)!

I truly believe that Cocoon can serve your purposes very well. And if it
doesn't, we are happy to welcome new ideas that allow to expand our
range without compromising our design goals.
 
> 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.
 
> 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 :)

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



Mime
View raw message