231833 - Add <http:serverpost/> widget for extensions/xmlextras

Status: RESOLVED WONTFIX

(Core :: XML, enhancement)

Description

[Alex Vincent [:WeirdAl]]

I've created a demo widget for an XUL application to post information to a 
server.  The demo is located at 
http://bdsmedberg.no-ip.org/xulform/serverpostDemo.xul .  I propose adding an 
<xul:serverpost/> widget similar to this, in the extensions/xmlextras area.

I'm willing to do all the work necessary to support this widget, including 
documentation.

The XBL binding, I suggest, would be located in the chrome at 
chrome://xmlextras/content/serverpost.xml.  I prefer this over adding it to 
chrome://global/content/bindings as it depends on the XMLHttpRequest() object.  
Appropriate CSS, DTD localizations, and /extensions/xmlextras/jar.mn will be 
included in my patch.

This serverpost element, unlike <html:form/>, does not replace the content 
document when the HTTP response is received.  Instead, the server may respond 
with any type of message it desires (text/plain or application/xml is 
recommended), and the serverpost element includes an event handler 
(onHTTPResponseReceived) to handle the server's response.  It also includes an 
event handler (onHTTPResponseError) in case an error happens in the 
XMLHttpRequest response.

The idea is that the XUL application will receive the response as a data string 
or XML document, and process the response appropriately -- perhaps going to 
another panel in an <xul:deck/> if desired.  Reloading or loading a new XUL 
document should be unnecessary.

Opinions and feedback strongly requested.

Comment 1

[Doron Rosenberg (IBM)]

If it relies on xmlextras, it shouldn't be part of XUL probably.  Perhaps
implement it using regular necko nsIFoo interfaces rather than xmlhttprequest?  

Also, web servers already can do this if you have a web service, and
xmlhttprequest can do get/post.  What are the advantages of your method vs doing
a get/post using xmlhttprequest?

Comment 2

[Alex Vincent [:WeirdAl]]

doron: I created the widget as an extension to the current XUL implementation, 
so that XUL applications can come from the server, run on the client, and 
interact with the server.  Perhaps Necko would be better, but I don't know jack 
about Necko. 
 
This widget uses XMLHttpRequest, so on first glance directly using 
XMLHttpRequest may be better indeed.  However, the widget takes the time to 
preformat the message it submits as a multipart/form-data, which CGI scripts 
(a well-established technology) can process them.  PHP can also receive 
multipart/form-data.  Really, this widget can be seen as a connection between 
the XUL application running on the client and the XMLHttpRequest which 
handles the true connection. 
 
XUL app <=> <serverpost/> <=> XMLHttpRequest <=> server-side 
programming 
 
I deliberately do not plan on adding it to the mainstream XUL widgets; at this 
point I'm not even considering modifying xul.css.  Instead, I would suggest the 
XUL app using this include an extra processing instruction to reference a 
stylesheet specific to the serverpost widget. 
 
With the widget implemented and enabled, and an extra attribute on each XUL 
control you wish to submit, it's just automating the process for the XUL app 
developer. 

Comment 3

[Alex Vincent [:WeirdAl]]

bsmedberg has informed me that method="post" does not require
enctype="multipart/form-data"; enctype="application/x-www-form-urlencoded" works
just fine if files are not included.  So I'll make that the default instead.

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: <http:serverpost/> patch

Now who can I get to review this patch, and who to test it besides myself?

Comment 5

[Alex Vincent [:WeirdAl]]

I wrote this patch so that people can in the future add other XML extras extensions.

Usage:
(1) Add to XUL or other application:

<?xml-stylesheet type="text/css" href="chrome://xmlextras/skin/"?>

(2) Add namespace declaration to document root element:

xmlns:http="http://www.mozilla.org/xmlextras/"

(3) Elements wishing to be controls submitted to the server need an
http:serverpostnames attribute with a space-separated list of http:serverpost
element names.

(4) The type attribute of the http:serverpost element reflects the content-type
submitted.  Default is application/x-www-form-urlencoded, with a
multipart/form-data as an alternate.

Comment 6

[Hixie (not reading bugmail)]

Wouldn't the stuff in my Web Forms proposal be better than this proposal?
If not, why not?

   http://www.hixie.ch/specs/html/forms/web-forms

Comment 7

[Alex Vincent [:WeirdAl]]

"It is not ready yet!  At all!"

Hixie, I actually respect your proposal a great deal.  To be honest, I do not
care how we get XUL controls' values submitted to a server and the response
processed.  I simply care that we do it, according to technologies popularly
supported.  I cannot explicitly state a strong argument for using my proposal
over yours at this time, except that this is a single element and your proposal
talks about several elements which are currently implemented through XHTML (and
some which aren't implemented yet).

Nonetheless, I'm going to try, as the devil's advocate :)

XUL works, for the most part (I have some fun with it in DOM bugs, but that's
irrelevant here).  Your spec would require using XHTML-namespaced elements, and
possibly that might not have the same meanings (<checkbox/> vs <input
type="checkbox"/>) or may not even work quite the same (doesn't XUL support
three-state controls of one sort or another?).

If XUL were to obsolete its controls and move to your web forms proposal, then
yes, I would agree wholeheartedly that implementing your proposal would be a
better solution.  If you needed XBL bindings for a few of them (repetitions come
to mind), I'd be happy to provide them.

In any case, this is an RFE; if you think Web Forms 2.0 is a better approach and
there's a bug on file to implement that, feel free to WONTFIX this one.  As I
said before, I think we should have some mechanism to automate the process for
submissions.

(Though to be honest, until such an implementation was actually added to
Mozilla, I'd probably rebel and use my binding anyway from a http URI.  If I
have something that works now, and I need something working to make my project
go forward, why shouldn't I use it, at least temporarily?)

Comment 8

[Hixie (not reading bugmail)]

I guess I'm confused. What is <serverpost> for exactly?

Could you provide a specification for it? I'm confused. My understanding was 
that the form controls weren't really relevant as far as it went.

Comment 9

[Mark Kaplun]

Cool idea.

I only scanned the code so maybe I'm wrong, but it looks as if there is only a
limited set of XUL input widgets being supported. I would suggest to support any
widget which implements the value property, no matter what is its type. This way
new XBL bindings can be supported.

Comment 10

[Alex Vincent [:WeirdAl]]

re comment 8:  See
http://weblogs.mozillazine.org/weirdal/archives/http_serverpost_spec.txt
for the specification I've drawn up.  (At this time, it is a very rough draft,
in plain text.)

re comment 9:  Not every element is appropriate for doing that to.  In the case
of menulists which offer multiple selections, the value property is inadequate
and possibly misleading.  (I haven't looked.) For radiogroups, the radiogroup
may have a value, and so do the radio buttons.  It's a little difficult to do
everything properly.

Also, I should note this is planned as an extension, and the limited support of
XUL widgets by this patch is simply because I haven't been able to spend the
time researching to see which elements to support and which not to.  It's a
fairly limited set right now because the three I found were the most obvious
candidates.  The fact remains adding support for these XUL widgets is really a
hack.  A better solution would be to add support to the XUL widgets themselves,
but I don't feel making changes to, say, textbox.xml to support the serverpost
widget specifically is a wise decision.

Comment 11

[[e-mail]]

Two notes:
a. Menulists aren't multiselect. Although we have multiselect lists we don't
attempt to track a value for them, the nearest we have are checkbox listboxes
for example in scripts preferences which works like a number of checkboxes.
b. radios are to radiogroups as menuitems are to menulists - they are the part
of the ui that lets the user give the radiogroup/menulist a value.

Comment 12

[Hixie (not reading bugmail)]

Ok, I understand now. Doing this makes sense, and would be in parallel with the
Web Forms stuff, specifically for XUL.

Comment 13

[Alex Vincent [:WeirdAl]]

Comment on attachment 140376 [details] [diff] [review]
<http:serverpost/> patch

This patch already differs from the spec I wrote.  New patch will be
forthcoming to better handle errors and conform to the spec better.

Note to self: Include filea for mozilla.org as documentation.  That is should
be a requirement before checkin.

Comment 14

[Mark Kaplun]

In coding terms, what I meant is to set a default case for xul elements in
getSuccessfulControls to be 
response[response.length] = {name: aNode.getAttribute("name"), value: aNode.value};

This way anyone which wish to use the serverpost widget for his own XBL widgets,
will know that all he has to do is to implement the value property. IMHO this
will make serverpost to be more future proof.

Comment 15

[[e-mail]]

Actually it's not just the value property, but you could check the
implementation - if the element supports nsIDOMXULSelectControlElement
then it's a radio or menulist type element, which uses a value; if it
supports nsIDOMXULTextboxElement then it also uses a value; if it supports
nsIDOMXULCheckboxElement the it uses the checked property.
This probably needs <listitem type="checkbox"> to be fixed to advertise
itself as a checkbox element and <radiogroup> to be fixed so that setting
the value selects the appropriate radio button.

Comment 16

[Alex Vincent [:WeirdAl]]

(In reply to comment #14) 
> This way anyone which wish to use the serverpost widget for his own XBL widgets, 
> will know that all he has to do is to implement the value property. IMHO this 
> will make serverpost to be more future proof. 
 
I'm thinking about it... my instinct is to say, "no, this is not a good idea for XUL elements."  
But if I can't come up with a specifically strong reason not to do so, I'll probably make it 
happen.  You need two other attributes on the XUL element anyway for serverpost to pick up 
on it... 
 
 

Comment 17

[Alex Vincent [:WeirdAl]]

Per discussions on IRC, this bug is almost a WONTFIX.  The widget itself is
good; pretty solid, actually.  It just doesn't have a home.

doron says it shouldn't go in extensions/xmlextras.  It would need approval from
hyatt to become part of the XUL toolkit.  I can't think of any other ideas for
good places within the Mozilla source tree for it to go, and it doesn't justify
creating a whole new extensions/serverpost directory for.

mozdev has been proposed as a possible good home, particularly in JSLib.  I've
been meaning to give them an assert() function anyway (which would WONTFIX
another bug I've filed).

Anyone in particular want to come to my rescue here?  petejc?  hyatt?

Comment 18

[Doron Rosenberg (IBM)]

I'm not saying it shouldn't, I just think that adding a new xul/xbl element only
if you build xmlhttprequest might cause some issues.

Comment 19

[Alex Vincent [:WeirdAl]]

heikki: do you want this code added to extensions/xmlextras, or should I try
somewhere else?  (I apologize if the question sounds abrupt, but I should
probably have asked you this a few weeks ago before working myself into a fever.)

doron: what sort of code changes to a Makefile (God help me) would I need to
make to force the file to check for XMLHttpRequest first?

Comment 20

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think the path of least resistance would be to make it a mozdev project. Then
see how popular it gets and what people think about it. If it gets good
reception, then do another proposal to get it included in the main Mozilla tree.