[Mono-list] Mono and XForms?
Thu, 11 Nov 2004 08:34:25 +0900
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
Anyways, XForms land would welcome developers, but won't consumers
Bill Abt wrote:
> Anyone know if XForms will eventually be supported in Mono?
> 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
*** 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
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: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 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?