Hi,
I saw some (not many; since XForms had never been major) XForms-interested guys are just asking "will there be XForms support?" but they never have any requirements nor concrete ideas, like I attached (it is just a memo without implementation nor running plan).
Anyways, XForms land would welcome developers, but won't consumers right now.
Atsushi Eno
Bill Abt wrote:
Anyone know if XForms will eventually be supported in Mono?
Regards, Bill Abt Emerging Technologies IBM Corporation Ext: +(00)1 877-445-9222 or +(00) 1 603-673-3440 T/L: 930-3277 Cell: +(00)1 617-803-7514 [EMAIL PROTECTED]
*** XForms interoperability
A new HttpHandler is required to accept XForms submission (not difficult). It will be represented as XmlHttpHandler(, XmlHttpRequest and XmlHttpResponse) that exposes pure XML I/O on HttpHandler. It will however require usual HttpRequest to handle. Simple runtime representation of XForms elements and attributes will be implemented. Active Server Forms Extensions (asfx) pages will be handled via XFormsHttpHandler. They could just be written in pure XML. All kind of directives could be written in its own namespace: <asfx:page xmlns:asfx="http://www.mono-project.com/namespaces/asfx/1.0";> <asfx:Import namespace="System.Data" /> ... (They could also be written as processing instructions, but then we will have to parse text value. Elements in its own namespace would be more cool.) Some notes; - some utility methods could be provided to handle XForms model easily. For example, ModelItems.Add (object obj) automaticaly XmlSerializes <code>obj</code> into xml output - some of Sys.Web.UI.WebControls might be implemented with them. Complex ViewState won't be required since they can be represented as XForms model instances. - For form submission model, we don't need inconvenient Request name value pairs anymore. We could directly handle form submission as XmlReader, or even XmlSerialized object. - Http Response could be directly implemented to fill XForms model element, with certain template page. - Server side event handling support. That is, if control's event is defined as asfx:runat="server" (namespace should be differentiated), then output XBL event should just submit control binding (XForms model instances) and the event target information (e.g. button1.OnClick). When sent to the server, XFormsHttpHandler creates the page instance and raises the event method as usual .aspx does. - Control data binding could be either early or late. Sometimes early binding for user control can be too heavy (imagine DataGrid with thousands of DataRow lines to be DataBound). Client might be rich but connection will be poor. - Those ideas does mean that it needs another WebControl-ish framework that needs many design decisions. Are we just copying ASP.NET style? Why do you need XForms then? For some XForms controls that can be represented as custom user control?
