cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject Re: XP taglib and new cocoon site
Date Wed, 12 Jul 2000 15:09:56 GMT
Ulrich Mayring <> wrote:
>Robin Green wrote:
> >
> > Then why don't you do what I suggested?
> >
> > E.g.:
> > view.xml contains the code (XSP).
> > archive.xml contains the archive overview.
> >
> > Use view.xml?get=archive.xml and use <xsp:include-file>. 
> > does not suffer from the 64K restriction.
><xsp:include-file> is new to me. Perhaps you mean <util:include-file>?

Yes, sorry, I meant <util:include-file>

>Or the XInclude Processor?
>Anyway, XSP pages are always compiled. If you include XML before or
>during an XSP pass, then that XML is compiled along with it. If you
>include XML after an XSP pass, then you avoid that problem. The only
>option to do that would be the XInclude processor, but that currently
>doesn't work after XSP, only before it.

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 

> > Why do you need any XSP in the overview anyway, if it is all 
>There is no XSP anywhere in any of my pre-generated files, they are all
>straight XML. As soon as I include them into a XSP page, however, they
>get compiled along with the XSP page.
>Basically, my premises are these:
>a) all content in straight XML files, which are visible to the user
>b) all logic in XSP files, which are invisible to the user
>So, the user requests an XML file. All my XML files have a stylesheet
>called "/common.xsp", which generates a dynamic XSP page and executes
>it. The XSP page generates some dynamic content, puts it into tags and
>calls its stylesheet, which is called "/common.xsl". This stylesheet
>transforms the XML tags to HTML.
>As you can see there is no XSP file, which the user could request and
>which in turn could include something.

Well there should be - see below.

>Instead the user requests XML
>files, which will generate a dynamic XSP page, if logic needs to be
>done. This way I can give my straight XML files to anybody and have true
>seperation of logic and content.

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)

              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.

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

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 

Robin Green
i-tao Ltd.
4 Skyline Village
London E14 9TS
United Kingdom
Phone +44 20 7537 2233  Fax +44 70 8081 5118

Get Your Private, Free E-mail from MSN Hotmail at

View raw message