• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (64)

1 localhost commented Permalink

There are however things it doesn't do. One is (as far as I know) allow user variation of the endpoint for submission or for the method of submission. This is particularly annoying because while it seems to be very promising in allowing saving of the XML model instance to say a filename and local directory, the filename and location and hardwired into the XForms, rather than being dynamic. This seems overly limiting in comparison to other, proprietary, XML-enabled forms solutions. Only fair to mention such things.

2 localhost commented Permalink

Excellent news. Thanks.

3 localhost commented Trackback

I have been following the XForms spec for over two years and personally think it is a great improvemnt over what we have today. We have a document oriented contracting application that fairly begs for XForms for all the reasons you have specified above. The problem I run into when trying to sell it is two fold:<div>&nbsp;</div> 1. There is no browser support. Yes we can get a plugin but then it raises a host of support issues with third party software.<div>&nbsp;</div> 2. The submission is XML. That to me is the great advantage since for my SOA application having the browser deal in XML is a boon. In fact here is the larger question: Why isn't the "browser" just another end point consuming and emitting XML? The problem though is unlike J2EE's Struts and their ilk there is no standard MVC framework to deal with the submitted XML. I could probably roll my own so it's not a big deal.Indeed IBM recently bought DataPower and having the submission go to this very capable XML device is a plus.<div>&nbsp;</div> For us enthusiasts of XForms it is very frustrating to have the right technology standard and not being able to implement it for reasons beyond our control.

4 localhost commented Permalink

&gt; XForms does not provide a presentation layer<div>&nbsp;</div> Well, if it does not, there should be some other complementary technology, that finally resolves the dreaded "double submit" issue. Come on, this is the most common use case in submitting forms:<div>&nbsp;</div> * submit a form* there is error, redisplay form again* submit the form again<div>&nbsp;</div> What if I go back? What if I hit refresh? These issues has to be solved on a spec level, not by an application developer. If needed, HTTP spec should be updated as well. But without this, XForms is not a complete solution, but just yet another "XML data processing language" constrained by current HTTP spec and browser implementations.

5 localhost commented Permalink

&gt; You hit submit, XForms tells you there is a problem,&gt; you fix it, you hit submit again, XForms lets it through.&gt; No double submit! <div>&nbsp;</div> Oh, that's cool. Obviously, to take advantage of that I should use client-side XForms+validation, either native browser implementation, or loadable Ajax engine. Would be great if it worked with server-side XForms as well. Also, would be great if I could use some XForms features like XML submission, and server-side validation in a way proprietary to my application. Still, this is the exciting news for me already. Thanks! Will go dig into the specs now.

Add a Comment Add a Comment