cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scherler, Thorsten" <Thorsten.Scher...@weidmueller.de>
Subject RE: database forms
Date Wed, 26 Mar 2003 15:40:38 GMT
Hi Stefan, hi Lorenzo,

The solution to go with an action seems to be quite practical because both of you have proposed
that.
While I had a glance on the book "Professional XML Schema" I was think that "our" validation
is existent but quite rudimental.

1) "The select problem"
> <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.
> 

I had the same approach when I was coding the <select><option> - block. I think
that is your (Stefan) solution of "The select problem"

2) "The Lorenzo approach"
> 
> 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.
> 
 
Stefan got a point there! Your example (Lorenzo) is very good and advanced. The only problem
was mentioned by Stefan. If we use your example for further development we have to simplify
the structure. Especially if I keep in mind that I have a block of question were I do not
know the name. 

3) "XMLFormXindice"

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

The problem with the logicsheet is the missing validation. 
The problem with the "XMLFormXindice" approach is the custom programming. If I compare your
reference I find the ArtistAction.java that I have to edit and fill that with my fields. But
like I stated before what will happen if I don't know this fields.

I am a bit confused, Stefan, do you want to use Xindice to store the options? Do you consider
Xindice only as tool or do you want to use it?

4) Thought: "DTD/Schema approach (in the spirit of DB2XML)"
Some time ago I found this tool http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/index.html
DB2XML. The nice thing on it that the dtd will be generate "on the fly". Using that this could
give us the validation input. I admit it is quite similar to the Xindice approach. But the
problem with Xindice is (in my opinion) the validation of dynamic data. 

The question remain whether DTD is enough or do we have to use schemas?

King regards
Thorsten

> 
> Any advice is highly appreciated.
> Stefan
> 
> 
> --------------------------------
> AGAINST THE WAR!
> 

Against "Cesar Bush" and the war!

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


Mime
View raw message