Bug 83948 - Xforms support in Konqueror/khtml
Summary: Xforms support in Konqueror/khtml
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-24 21:55 UTC by eric
Modified: 2006-10-28 23:07 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eric 2004-06-24 21:55:35 UTC
Version:            (using KDE KDE 3.2.1)
Installed from:    SuSE RPMs
OS:                Linux

It would be great if Konqueror would have support for XForms, it would be a big improvement in
web application development if more browsers support it.
Comment 1 Rene Horn 2004-08-11 11:59:03 UTC
A little FYI: http://www.w3.org/MarkUp/Forms/
Comment 2 Kai Lahmann 2004-08-11 13:47:12 UTC
Mozilla just starts to announce their work on it a bit bigger :)
Comment 3 Allan Sandfeld 2006-06-17 23:04:37 UTC
From the looks of it WhatWG thinks XForms is a webserver technology and WebForms will be the browser part.
Comment 4 theo 2006-06-17 23:23:45 UTC
Well they have no idea what they are talking about then ;)

XForms is most certianly a browser client technology.  If you would like any clarification of that, read the specification at http://www.w3.org/MarkUp/Forms/. (as posted in comment #1)
Comment 5 Allan Sandfeld 2006-06-18 00:00:25 UTC
Yes, but it's a technology that is very depend on being implemented in both the server and the client. 

Therefor it can make sense to proxy it.. If this method wins then browsers wont actually have to implement it as such. 

Btw. did I mention that XForms is most horrible interdepending standard I've ever seen?
Comment 6 theo 2006-06-18 00:24:04 UTC
Sorry, i do not understand why it depends on being implemented on server side any more than current HTML forms do?

Just because the Web Forms 2.0 guys think what XForms should be implemented server side, it doesn't mean that the rest of the world does.  

processing XForms server side is a hack, full stop. :)

consider the case of XML data islands, or other client side web applications.  In these cases, there may be no "server" other than to post XML to and from, as the application may well use XML and XSLT for form rendering while the server purely understands XML or any other arbitary data format.

web browsers are not just used for browsing the web you know, dispite their name ...

just because opera don't want to add xforms to their product, it doesn't mean konq should, does it? (which is what the entire web forms thing is about, anyway)

and yes, i do know the xforms spec well :)
Comment 7 Rob Burns 2006-09-30 02:57:58 UTC
I hope the issue of implementing XForms will get more serious consideration than some of the above comments imply. First, XForms follows best practice standards by clearly separating model-view-and controller. It also finally rationalizes the separation between client/desktop and server: something impossible with existing HTML forms This reduces superfluous communication between client and server and creates a better experience for end-users.

It does accomplish all this in a way that depends on existing impelemented standards. One commenter posted that XForms is the "most horrible interdepending standard" ever seen. Well It depends on XML, HTTP, XPath, XML Schema Definnition, XEvents and other W3C standards. Most of these are already supported or will receive widespread support in the near-term. Which specific dependncies in XForms are a problem? Why would KHTML want to eschew these dependent standards?

As for WhatWG, they do not seem to have any substantive proposals. Instead they largely amount to a tutorial for using existing forms and in their advocacy against XForms act as a generator of FUD on adoption of improved W3C standards.