cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Morrison <john.morri...@experian.com>
Subject sql xsp logicsheet design issue -Reply
Date Fri, 25 Aug 2000 08:48:17 GMT
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.

If anything can be done about this it would *really* be useful.

John.

>>> 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




Mime
View raw message