Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Sender: ulim
Message-ID: <396C8A88.178AEE0F@denic.de>
Date: Wed, 12 Jul 2000 17:11:04 +0200
From: Ulrich Mayring <ulim@denic.de>
Organization: DENIC eG
MIME-Version: 1.0
To: cocoon-users@xml.apache.org
Subject: Re: XP taglib and new cocoon site
References: <OF5CD6FFF5.2B4DF22B-ONC125691A.00503BF5@notes.denic.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

> Robin Green wrote:
> 
> No, you are mistaken. <util:include-file> includes the file after the
> compilation has completed. It is a Java include, not an XSL or XML include.
> So <util:include-file> does indeed avoid the 64K limit. You can verify this
> by looking at src/org/apache/cocoon/processor/xsp/library/java/util.xsl
> (IIRC)

Are you sure this is true for dynamically generated XSP? I was under the
impression that dynamically generated XSP is compiled at run-time. But I
may be wrong here, I haven't actually tried it, because (see below).

> I am in fact suggesting the same separation into logic and content!  Just a
> different way around. (Nitpick - your "straight XML files" probably include
> processing instructions - so they are not _pure_ content. In fact, my
> approach would use pure content XML files.) You currently have: (this
> diagram needs a fixed width font BTW)

Well, you are right about the PIs, no doubt about that. But I thought
that they would be ignored by user agents that do not know them, much as
browsers ignore unknown HTML markup.

>               XSP logicsheet                      stylesheet
>  Data (XML) ----------------->  XSP --> content -------------> HTML
> 
> whereas to solve your problem, you should just switch it around from a
> "data
> pulls logic" system into a "logic pulls data" system, like this:
> 
>     gets XML data
>       |
>       |                       stylesheet
>  One XSP page --->  content --------------> HTML
> 
> Do you see what I mean? The one single XSP page does the job of your XSP
> sheet, without the overhead and the 64K limit.

Yes, I understand that, but (see below ;-)

> I anticipate that you may have additional logic that cannot conveniently be
> subsumed into this approach. If so please could you give more details.

I have a small amount of custom logic that I need to do for each and
every page in my site, including the mail archive. I could follow your
"logic pulls data approach" and put the logic in an XSP page and from
there include the XML that the user requested. So I base my site on a
single XSP file. This approach would work, but no pages would be
bookmarkable, because there would effectively be just this one page.
Except if I include all dynamic information in the URL, which would then
become rather long. And there are things like usernames/passwords, that
you don't really want in an URL, but as POST parameters :)

So, perhaps I should do "logic pulls data" only for the mailarchive and
live with the non-bookmarkability there? I must say this thought bugs
me: I really want to have a 1:1 relation between URL and page displayed.
But suppose I would make this one exception for the mailarchive. Then my
custom logic would live in two different places: once in the document
root (for the "data pulls logic" pages) and once in the mailarchive's
directory. Well... perhaps I can live with keeping both files up to
date. But what happens when the next "larger than 20K page" comes along?
I suspect that in the long run this will get rather messy.

I feel that as a site designer, I don't have the luxury of doing this
here and that there. I need to have a consistent site that works the
same way every time and seperates logic from content. Otherwise I
wouldn't worry about cocoon and just hack PHP or something :-)

Maybe I really should wait for the cocoon2 sitemap?

> Incidentally, we are working on a "automatic include" system (part of a
> Content Management System like that described on the Oracle website), which
> is sort of a more complex elaboration of the "logic pulls data" approach -
> but the CMS level of complexity is probably not needed for this mail
> archive
> application!

Not for a simple mail archive, but for a web-site!

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung