cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: sql xsp logicsheet design issue -Reply
Date Fri, 25 Aug 2000 15:24:25 GMT
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 <> 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 ( {
>   <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

View raw message