Re: [xsl] I have the XSLT, now need to make it usable as user-input form?

[S Woodside <sbwoodside@xxxxxxxxx>]

On Saturday, April 19, 2003, at 03:11  AM, Andrew Watt wrote:

> At 01:08 19/04/2003 -0400, you wrote:
> > This should be possible with regular HTML form submission as well. 
> > Basically imagine that you have one big TEXTAREA in html with the XML 
> > in it, and a submit button. THe submit button will simply post 
> > whatever's in the textarea back the server.
>
> Simon,
>
> One difference is that XForms will submit well-formed XML data with no 
> visible sign of XML in the interface exposed to the user. It is ok for 
> XML geeks to, for example, enter XML in a textarea, but most users of 
> forms don't speak XML.

Right. The system I'm working on won't present the raw XML ... I was 
just trying to illustrate a certain concept.

> Also, won't the data submitted actually be a name-value pair from an 
> HTML form? The value may well-formed XML but the whole submission 
> won't be.

Yes, but most XSLT processors (libXSLT anyway...) support the ability 
to extract the name/value as a parameter, by defining the param with 
the right name and then the value is the ... value. With EXSLT evaluate 
or somesuch that can be converted into a node tree or whatever it's 
called (I keep forgetting the lingo).

> That might preclude passing the submitted HTML forms instance data to 
> an XSLT application (since the source isn't well-formed) whereas 
> XForms instance data, because it is well-formed can be passed straight 
> to XSLT. Of course a little pre-processing could strip off the name 
> part of the name-value pair from an HTML submission.

Yup, the data could come in as not-well formed. So, in my case, I'm not 
going to be passing the whole instance through, which would be 
incredibly inefficient anyway. I was just showing how that might be 
done.

FWIW, there's still the possibility that a malicious XForms user could 
hijack the connection and send back malformed XML for some nefarious 
purpose. So XForms definitely has that as a pro but there's still the 
possibility of a security issue. That's one reason why I generically 
prefer server-side solutions.

> > On the server side the application that receives the data (could be 
> > XSLT ...) can simply pull the instance data out of that parameter and 
> > then do whatever it wants with it, write it to a file (e.g. using 
> > EXSLT document()) write it to a database, verify it, etc.
>
> One viewpoint in a recent XForms list discussion is that dynamic 
> creation of XForms documents, for example using XSLT, will be an 
> important approach.

Cool.

> > simon


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list