cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Didier VILLEVALOIS <>
Subject RE: 64k limit (was: new version of the sql logicsheet under devel opment)
Date Tue, 29 Aug 2000 13:16:26 GMT
Robin Green wrote:
> >I think your problem is induced by the fact you inline all 
> of the logic of
> >one page of your applications in one class.
> That's not correct. Look at some of the logicsheets. They 
> call external 
> Cocoon classes. And obviously DOM creation is inherently OO 
> (and maybe shows 
> why OO is not always so good!)

As you say *some* taglibs does this. But nothing or nobody
constrain you to do that. As pointed out Ricardo Rocha each
taglib could be a class embeding DOM creation. This is OO!!

> It is, but there are practical limits. For example, literal 
> node creation is 
> not easy to modularise because it refers to lots of local 
> variables.

What local variables ? The servlet stuff ?
Parameters that need the *taglib object* needs is passed throught
the constructor or methods parameters. This could be mapped to XML
through a variable/parameter passing mechanism as in XSL. This fits
very well with attributes and elements.

> >Ok code snippets are reused because capitalized in taglibs. But the 
> >produced
> >code is not. That's is too much inlining.
> >
> >That's why i looked in another direction : Embeding logic in 
> stylesheets 
> >and
> >not in producers. What i mean is compiling taglibs instead 
> of sources !! To
> >do this we need an xsl->java transform similar to the xsp->java one.
> The trouble is XSL is not necessarily the best language for general 
> programming tasks. E.g. there is no _standardised_ method for 
> invoking Java 
> methods. In general Cocoon does not want to rely on 
> non-standard "hacks" 
> like Xalan extension functions.

I think these are not hacks. XSP is more a hach than XSLT extensions.
The Java (and JS, C++) invocation mechanism of extensions will be
standardized. People in this list is just the one that could do proposals.

> Great fun, I was hoping to do something like that myself 
> soon. Not to solve 
> XSP problems, but in fact to speed up XSLT transformations. 
> Can you put it 
> up on sourceforge or something? I don't mind if it doesn't 
> compile yet, no 
> problem.

I'll try to put it this or next week. I'll notice the mailing list.
And in fact it doesn't compile yet :-).

> By the way Sun has said it plans to open source their XSLT 
> compiler sometime 
> in September.

I dislike Sun's approach. I think this is better to do it in XSL
for portability. The fact is we could learn a lot about how to
manage sorts... :-)


View raw message