Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Date: Fri, 25 Aug 2000 11:24:25 -0400 (EDT)
From: Donald Ball <balld@webslingerZ.com>
To: cocoon-dev@xml.apache.org
Subject: Re: sql xsp logicsheet design issue -Reply
In-Reply-To: <s9a632ca.064@experian.com>
Message-ID: <Pine.LNX.4.21.0008251122330.3253-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 25 Aug 2000, John Morrison wrote:

> Donald - as far as I can tell this is a design flaw.  I attempted to do
> something similar last year (before you put the conversion stuff in the
> sqltag lib for dates) and never managed it.  Gave up completely in the
> end and wrote my own taglib which queried the database.  Shame.

well, of _course_ it's a design flaw, i'm just trying to determine in
which layer the flaw is and the best way to fix it. what do you think
about the solution i outline below?

- donald
 
> >>> Donald Ball <balld@webslingerZ.com> 25/August/2000 05:33am >>>
> i have a design question about xsp logicsheets. i have two logicsheets,
> sql and calendar. sql retrieves results from a database, and calendar
> generates a calendar view. calendar's generate method can take an
> argument
> indicating the date around which the view should be created. i'd like for
> that argument to be one of the values in the database resultset. i cannot
> think of an easy way to do this using merely xsp logicsheets, but i think
> it's something i ought to be able to do.
> 
> my first avenue of attack was to insert a logicsheet between the two
> that
> would create the call to the calendar logicsheet from the results of the
> sql logicsheet invokation. unfortunately, you can't match on the elements
> created by the sql logicsheet - they're part of the result document. the
> only way i can think of that'd you be able to do it would be to add
> another XSLT and XSP process, which i'm loathe to do.
> 
> is this a design flaw in the sql logicsheet, the calendar logicsheet or a
> problem in general with having logicsheets that invoke other logicsheets
> with arguments chosen at runtime?
> 
> ... playing ...
> 
> i'm leaning towards a design flaw in the sql logicsheet. rather than
> approach the logicsheet itself by tossing everything into a java library,
> a judicious use of xslt in the logicsheet might clear everything
> up. supposing we modified the sql namespace so that you could write
> things
> like this:
> 
> <sql:execute-query>
>  <sql:query>...</sql:query>
>  <sql:results>
>   <calendar:get-month>
>    <calendar:value><sql:get-string
> column="occurance_date"/></calendar:value>
>   </calendar:get-month>
>  </sql:results>
> </sql:execute-query>
> 
> that might solve the problem, and conceivable a slew of other ones. how
> would we modify the logicsheet to support that?
> 
> ... coding ...
> 
> <xsl:template match="sql:execute-query">
> <xsp:logic>
> {
> ...
> ResultSet rs = st.executeQuery("<xsl:value-of select="sql:query"/>");
> while (rs.next()) {
>   <xsl:for-each select="sql:results/*">
>    <xsl:apply-templates/>
>   </xsl:for-each>
> rs.close();
> ...
> }
> </xsp:logic>
> </xsl:template>
> 
> <xsl:template match="sql:get-string">
>  <xsp:expr>rs.getString("<xsl:value-of select="@column"/>")</xsp:expr>
> </xsl:template>
> 
> would this be a good way to tackle it?
> 
> if this is the best way to go about doing it, i can foresee one problem
> right away - it's almost certainly going to bang people up against the 64k
> java method limitation if it's written basically as i've laid it
> out. how could we avoid that?
> 
> - donald
> 
> 
> 
>