cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: new version of the sql logicsheet under development
Date Fri, 25 Aug 2000 23:10:35 GMT
On Sat, 26 Aug 2000, Giacomo Pati wrote:

> Donald Ball wrote:
> > 
> > hiya guys. i realized recently that the sql logicsheet had a serious
> > design flaw that was making implementing some frequently requested
> > features rather difficult. the essential problem was that i was
> > manipulating the result DOM in my java library code, rather than relying
> > on XSP itself to generate the results. This made it practically impossible
> > to, for instance, use the results of a sql query as a configuration
> > parameter to another logicsheet.
> > 
> <snip/>
> 
> Wow, Donald, cool work. This approach can be migrated to C2 easily, I
> think!

oh, yeah, i forgot, that's the other big benefit as well - i think this
should work with C2 seamlessly - the only caveat might be the
this.xspParser object.

> > these are all of the pros. there is, of course, a con, and it's a pretty
> > big one - because the new logicsheet doesn't really know ahead of time
> > what it's going to be doing with the results, there's no easy way to put
> > it in a method that will be called over and over again. as a result, all
> > of the jdbc code is inlined into the populateDocument method (I can see
> > Uli clutching his head right right now), people who are querying big
> > resultsets are almost certainly going to bang up against the 64k per
> > java method barrier.
> 
> Maybe some part could be inlined into the inner class EsqlSession (or a
> separate one)?

probably little pieces, yeah, but i can't see a clear way to, uh,
method-ize the big recurring sections.

> > i see two possible avenues around that - one would be to make the xsp
> > processor more intelligent and have it break up the populateDocument
> > method into several smaller ones (populateDocument_1, populateDocument_2)
> > if it notices that the method is going to be really big. i don't know how
> > hard it would be to do that, probably pretty difficult though - however,
> > i'd like ricardo's opinion on that since he's the primary xsp developer.
> 
> This would be really hard I think. I once had the idea of splitting
> populateDocument into several pieces, too. But how can the XSP processor
> determine which local variables some other logicsheet has defined be
> passed from one populateDocument method to the next one?

maybe it can't determine that, but maybe it can track all local variables
which are still in scope at the end of one mini-method and pass them all
into the next mini-method? or maybe we could add an xsp element in
explicitly declare variable scoping:

<xsp:scope>
 <xsp:logic>String foo = "bar";</xsp:logic>
 ...
</xsp:scope>

-->

{
 String foo = "Bar";
 ...
}

and then the xsp processor could try to ensure that the methods would
break on xsp:scope boundaries?

- donald


Mime
View raw message