Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Parsing the structure of a form as XML content
 Mitch Amiano wrote: > Aleksander Slominski wrote: > >> Mitch Amiano wrote: >> >>> At what point does creating entirely new systems using the most >>> antiquated technology become a gratuitous exercise? >> >> >> >> hi, >> >> maybe because it works? and works very well meeting all our needs? > > > (screaching halt to communication) > Ok, sorry, I obviously set the wrong tone with my post. I meant to ask > rhetorically, when do you determine that taking a pure HTML approach > works so well that you > are willing to avoid new technology? hi, we are looking for something that works very reliably with IE6 and if possible with other browsers on other platforms (Mozilla, ...) that means that depending on Javascript, DHTML, Java Web Start or applets is not that great .... >>> I don't mean to slur the posters, as I've had to use a technique >>> similiar to the one described a few years ago. But this seems to be >>> the case of painting one's self into a corner, or throwing good >>> money after poor practice. >> >> >> >> it is proof of concept and we are willing to explore alternatives >> (that is why i have posted it). what do you exactly propose? > > > If I accept the premise, that is, that your goal is to be a pure HTML > implementation, > (disregarding my rhetoric above), then your design is quite reasonable. nice to hear it! > > > Another variation on the naming convention is to use concatenated ID > values, where the id of a child consists of the id of it's parent + a > sequential number to indicate its ordinal position. E.g. > P-0 > P-0.I-0 > P-0.I-0.JI-0 > P-0.I-0.JI-0.X1-0 > > These are valid identifiers, and can be ripped apart without knowing > anything about XPath, to get at a specific element or any of its > ancestors. However, I think perhaps you are looking for a location > into an XML instance, and not a name? you are right we want to be able to roundtrip XML instance (such as SOAP message). > >>> The forward slash isn't a valid name character. >> >> we support both slash and escaped characters: initially we had / as >> %XX however it did not look nice and after checking with HTML >> browsers it looks like slash will work. if we had it deployed to more >> HTML clients we would generate appropriate filed name depending on >> browser name. > > > In the case of a forgiving html browser that strategy might work. I > presume you aren't concerned that foo/bar and foo%XXbar would be > rejected by a software that expects valid names. actual decoding of parameter names is done by servlet and it works so far fine with both approaches to generate form parameter names just "foo/bar" is easier to edit by somebody who takes a look on HTML source. >>> One could maintain a second, hidden form field which contains a >>> simple lookup table of html field names to XPath targets, as in >>> field1, param:parameters/input/job-input/x1/ >> >> >> >> this does nor sound simple at all and does not scale for deeply >> nested XML instances: HTML field names are no longer self describing >> and even more: it has layer of indirection that prevents "View >> Source" editing of HTML ... > > >> it is my impression that doing View HTML source and than modifying >> was crucial to success of HTML and Web and as we wanted to make >> really easy to customize HTML forms we wanted to make it easy both to >> edit by hand (or text editor) and using more fancy visual editors - >> both approaches work now fine with HTML code that we generate and >> that can be used as template for better looking HTML page. > > > If viewing source and modifying it is important, then a level of > indirection is not so good. But why not then simply provide the > unmodified XML, or use a Wiki approach? we need HTML form to gather parameters form user that used to invoke web service or just to allow editing of XML instance (that contains parameters ans is stored in DB) > > How does embedding a stripped down path expressing as a field name get > better scalability for deeply nested XML? I mean, the path you use > seems to be predicated upon generic element names, whereas your fields > supposedly point to specific element instances. the path points to XML instance and set of such paths can be generated from XSD to guide creation of XML instance: in our case we take WSDL that has XSD and allows user to create instance of SOAP message (XML instance) and the form to create SOAP message is automatically generated from WSDL/XSD. > >>> The form is then self-describing, without violating any naming >>> rules. Of course, you still have a problem if you need to have >>> multiple elements as siblings, and need to specify the order, but >>> you can solve that with even more mangling to include parent/child >>> pointers. >> >> >> >> exactly. this problem and wanting to avoid indirections coded in >> hidden fields ... >> > > Good luck! thanks! alek 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
