Hi Thorsten, Lorenzo
1. reply to Thorsten:
>>In your example you've only got textboxes. With listboxes (<select> in
HTML)
>>it gets a bit trickier, since you'll have to get the possible values from
a
>>different table first. Have you got an idea for that, too?
>>Maybing using XSP-ESQL?
>nested esql like that:
>[...]
I'm not sure we undertand each other right there. The problem was not to get
all the recordsets from a table (say books) that are related to another one
(say authors), but to implement listboxes in an easy way. (e.g. a column in
table books contains a foreign key from table authors, then in a form you'll
want a listbox to easily select one author). I've been thinking a bit myself
and came up with the following:
Define a XSP-logicsheet with namespace e.g. "dbf". Snippet:
<xsl:template match="dbf:listbox">
<esql:connection>
<esql:pool><xsp:expr>dbfpool</xsp:expr></esql:pool>
<esql:execute-query>
<esql:query>SELECT <xsl:value-of select="@entries-column"/> FROM
<xsl:value-of select="@entries-table"/></esql:query>
<esql:results>
<select>
<esql:row-results>
<option>
<esql:get-string column="name"/>
</option>
</esql:row-results>
</select>
</esql:results>
</esql:execute-query>
</esql:connection>
</xsl:template>
note: dbfpool is a variable that might be set by a sitemap-parameter
Then use it in an xsp-page like:
<dbf:listbox entries-table="author" entries-column="name"/>
That get's you in one line a listbox filled with all the names in the
author-table. Defining another parameter like ref="authorid" you could then
bind it to a field in the book table.
2. Reply to Lorenzo
That is quite close to what I was talking about. However I don't like having
to write an extensive configuration file. For example, I don't like having
to define listboxes using a block of esql every time. I'd very much prefer
something like I outlined above.
Besides I don't need to use the same form elements again and again in
different contexts (which your system seems to be very useful for), it's
more about being able to write one single form really quickly and directly
without loads of support code (like the esql) around it.
3. More thoughts: XMLForms
I'd been looking into XMLForms before and reading Lorenzo's note at the end
of his last message I took another deeper look. I found a quite interesting
tutorial that describes how to replace the form model (currently
incorporated by a JavaBean) by a model defined by an XML-File that is linked
to an XIndice database:
http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice
I was wondering whether this would be worth a thought in this case as well,
since XML may be generated from any ordinary relational database, too.
You would generate an XML-Model from the database, use it to keep the form
data and in the end send the data back to the database. That would also have
the advantage that you could build multi-page forms to gather the data for
one table (for example one form to gather the book data and a separate one
to select the author from a long list) and then in the end send it to the
database altogether (otherwise you would have to store the book data without
the author being filled in which wouldn't be possible, cause the author
field can't be empty...)
So I am currently pondering about what to go for: an XSP logicsheet approach
as outlined above - that might be easier to implement right now - or try to
use XMLForms which would be a lot more flexible.
Any advice is highly appreciated.
Stefan
--------------------------------
AGAINST THE WAR!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
