On Tuesday, 14. January 2003 04:13, S Woodside wrote: > I'm working on a system to use a Relax NG (RNG) schema to generate HTML > forms. The user will interact with the forms, and when they press > submit, XML will be generated from the form results. The XML can be
Nice. I have such a system, only not for any standardized schema language but for a selfmade xml dictionary. I'm not inclined to release it, though, as it is a terrible mess, being extended as the need arose :-) > validated against the form either by javascript on the UA or by the > server after it gets it back Always validate on the server. You won't get around it, or your app will have a security hole > sourceforge) into RNG using dtdinst tool. Now I am writing an XSLT to > convert the RNG to HTML forms. The idea is to make it generic so that I > can change the forms by changing the RNG. I don't like working with > HTML forms directly, they are too messy. I took this approach at first, too, but it was too limiting later on. My current approach: Generate meta-form tags, i.e. arbitrary placeholders. Use one stylesheet to arrange these items the way you want, use a second stylesheet to convert the meta-form tags to real html tags. This way you can control the design much more. The arranging stylesheet could set additional attributes on the meta-form tags to control visual details of the conversion, like the "size" or the "cols" parameters, while the second stylesheet takes care of generating the correct <input>/... element with appropriate maxlength="" parameters and such. > Now, I can generate a huge mega form but that's not really practical, > it ends up as a 250K + HTML file that renders really slowly. As well, > there are <zeroOrMore> and <oneOrMore> tags in RNG to specify dynamic > sections of content. For the size reason, and because I don't know > javascript and DOM yet, I'm leaning towards a roundtripping server > solution. Also it will work on more browsers, AFAIK browser support for > DOM manipulation is spotty. If you abandon NS4 once and for all (and IE3 of course ;-), this is manageable. You need 'only' two DOM tree access functions, one for IE (all versions) and one for the rest of the world (Mozilla, NS6/7, Konqueror). Opera 6 didn't support either, Opera 7(beta2) does, but the current beta fscks up my CSS using sites (which degrade gracefully down to even NS4). Anyways. Nowadays you can get a long way with ECMAScript, and this is a good thing, IMHO - as long as you support a server-based fallback. ECMAScript gives your app a more responsive feeling through faster feedback, thus it is more userfriendly. (again, only as long as those having it turned off are not left outside in the rain) > My idea is that when I hit a <zeroOrMore> tag with a FooBar child, I'll > prune the (RNG) tree at that point and provide a button that says > something like ((Add a FooBar element)). The button will pass back > information that identifies the pruned subtree uniquely to the server. > The server will then feed that subtree back into the RNG->HTML Form > XSLT and so on and so forth. I want to write as little application > (i.e., Resume XML) code as possible. This is how my solution works, too. > So how do I best handle the POST/GET parameters? I want to be able to > grab the params from the POST/GET whatever and feed the unique ID back > into the RNG-HTMLForms XSLT to generate the appropriate new section. Use a naming scheme with which you can uniquely identify which input param belongs to which Schema entry. I use the following, which might be inappropriate for full RNG, I don't know: top-level tag FOO's elements are called FOO[0], FOO[1], ... plus a hidden FOO[] holding the count of them (empty fields are usually not sent back, so they would get lost otherwise). An element bAr below the first FOO is called FOO[0]bAr[0], FOO[0]bAr[1] and so on, again with a hidden FOO[0]bAr[] for the count. This preserves order and tree structure, only it can't express things like <foo/><bar/><foo/>, nor does it do <foo>Hello <bar>World</bar>!</foo>. If you need that, be sure to tell me which solution you found :-) As for the notification that a new subtree is to be shown, use submit buttons which carry names like "FOO[][add]", which means "append one FOO entry", or "FOO[1][del]" == "remove the second FOO subtree", or "FOO[1][add]" == "add an empty FOO before FOO[1]". You have to scan the param _names_ to get them, but this way you can put arbitrary text on those buttons. > Also, I need to have some way to assemble the pieces of XML that are > created this way into a complete instance document. It should be easy > to name the HTML forms fields in such a way that I can generate XML > from them. I think there's already some code out there that > automatically generates XML from the form fields (Matt was that yours?) > I will probably need to assemble multiple pieces into the complete > instance document. A recursive function of 20-30 lines will do the trick. Mine is that short, anyways, unfortunately I wrote it before I learned the DOM, so it just assembles a string... Hope this helps -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
