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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
