SQLProcessor question

[Berin Loritsch <bl...@infoplanning.com>]

I did a proof of concept back at Cocoon 1.5 for my company, to prove
that this
technology would be able to create dynamic text, generate output based
on SQL,
and render in an acceptable time-frame.  Since then, I have not yet had
the time
to revisit the proof of concept--but a couple of issues came up, and I
wanted to
know if they still exist:

* If I used the qruerydefs methodology, it would not execute the query
UNLESS
  there was at least one query done the other way.

  EXAMPLE:
  <!-- This would not return any records -->
  <querydefs name="standard" doc-element="options" connection="foobar"/>

  <query defs="standard">
    SELECT foo FROM bar WHERE frustration < 1;
  </query>

  <!-- but this would ... -->
  <querydefs name="standard" doc-element="options" connection="foobar"/>

  <query doc-element="dummy" connection="foobar"/>
    SELECT foo FROM bar WHERE frustration > 1 ORDER BY magnitude;
  </query>
  <query defs="standard">
    SELECT foo FROM bar WHERE frustration < 1;
  </query>


* There was no way to override the field element names.

   <!-- The results will follow -->
   <query doc-element="foo" row-element="bar" connection="foobar">
     SELECT itsy, bitsy, spider
     FROM water_spout
     WHERE
       rain = washed AND
       spider = out;
   </query>

  <!-- the results -->
  <foo>
    <bar>
       <itsy>blah</itsy><bitsy>blah</bitsy><spider>blah</spider>
    </bar>
    <bar>
       <itsy>Hidy</itsy><bitsy>Ho</bitsy><spider>Neightbor</spider>
    </bar>
  </foo>

Problem: the field names are forced to be the same as the query's field
names,
         forcing the XSL to be much more creative.  I could have used
aliases, but
         for the particular solution I was looking for, I just wanted
all the fields
         to use <field></field> or something similar.  I was creating a
sortable
         list, and the field names were not that important, but when I
want to create
         a form the field names are very important.

Granted, for our project it may be a moot point--we are considering
using
Enterprise Java Beans (EJB) for the integration of the database into the
two or
three applications built on that database.  The problem with straight
SQL
embedded in the templates becomes evident if you ever need to
restructure your
database.  (we had to do that with an existing application with ~200
templates
averaging 5 queries per template -- it was very painful).