[Mono-list] Mono and XForms?

[Atsushi Eno]

This is a multi-part message in MIME format.
--------------020408090507090404050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>      babt@us.ibm.com


--------------020408090507090404050508
Content-Type: text/plain;
 name="xforms-memo.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="xforms-memo.txt"


*** 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?


--------------020408090507090404050508--