cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <esa...@canuck.com>
Subject Re: How to reduce the size of XSP classes?
Date Fri, 07 Jul 2000 17:07:09 GMT
on 7/7/00 3:18 pm, Ulrich Mayring at ulim@denic.de wrote:

> Mark Washeim wrote:
>> 
>> Can I ask what the nature of the content is?
> 
> Yes, I am writing an XML-based email archive. When I have 125 email
> subject lines on my overview page, then that equals about 20K XML code.
> The XML file is smaller than the HTML page generated from it.
> 
>> It seems that you might only require some number of elements for any given
>> view. Hence, you could take an approach like xinclude does, and treat only
>> those nodes required for a given view?
> Let's assume for this example that we want to have some very simple
> logic, a counter, on every page. But we are not allowed to use the
> XSPProcessor, because it will always try to compile. That leaves us with
> the SQL Processor and the XInclude Processor. The first is out, because
> I don't want to do all my logic in a database :-)
> 
> Perhaps there's some way to trick the XSPProcessor by using XInclude.
> 

Ok, I've got you. Three immediate solutions come to mind:
1. If you don't treat the nodes but only want to add something like date,
then definatly use xinclude (or util:include-file). That will only includ
eht content at request time, not compile time.
2. If it's something like date/time you want to include, have Xinclude
include the xsp page (as a URI, so, with network overhead) as a 'fragment'
of the secondary page... you could have lots of utility 'pages' . . . but,
then, we're in jetspeed territory and you might want to look at portlets . .
.
3. use two xslt passes, transforming the data of the large data set
'through' an xslt/xsp page . . . but I've never tried this. The idea is:
xml -> xslt -> xslt/xsp -> html
I need to try something like this . . .

The 2nd idea is one of aggregation that Kevin of the jetspeed project is
doing very tidily with a portal defined of numerous portlets. . .

I'd be interesting to try this with xsp. Namely, aggregate the results of
numerous documents.

I'm going to have a go at this. But, first, with xinclude such that:
mailarchive.xml is composed of:
<xinclude:include parse="xml"
href="nav/site.xml#xpointer(//somestructure)"/>

<xinclude:include parse="xml"
href="util/calendar.xml#xpointer(//date/time)"/>

<xinclude:include parse="xml" href="mail/archive.xml#xpointer(//whatever)"/

<xinclude:include parse="xml"
href="colophon/colophon.xml#xpointer(//colophon/copyright)"/>


Of course, I'm not sure about what the impact on performance is, etc.



>> Or, do you really have 20KB of text to display? Our average article and all
>> it associated text (xml) are rarely more than 1 to 2 KB....
> 
> Perhaps you have no "Terms of Business"? ;-)
> 
> Seriously, our terms of business document is very large, just as an
> example.
> 
> Ulrich


yeah, sorry, I didn't mean to oversimplify. :)

-- 
Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell

 



Mime
View raw message