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




16 years ago
14 years ago


(Reporter: WeirdAl, Assigned: WeirdAl)



Firefox Tracking Flags

(Not tracked)




(1 obsolete attachment)



16 years ago
I've created a demo widget for an XUL application to post information to a 
server.  The demo is located at .  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 

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/ 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.
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

16 years ago
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 
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 

Comment 3

16 years ago
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

16 years ago
Posted patch <http:serverpost/> patch (obsolete) — Splinter Review
Now who can I get to review this patch, and who to test it besides myself?

Comment 5

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

(1) Add to XUL or other application:

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

(2) Add namespace declaration to document root element:


(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.
Summary: Add <xul:serverpost/> widget for extensions/xmlextras → Add <http:serverpost/> widget for extensions/xmlextras
Wouldn't the stuff in my Web Forms proposal be better than this proposal?
If not, why not?

Comment 7

16 years ago
"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

(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?)
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

16 years ago
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

16 years ago
re comment 8:  See
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.
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.
Ok, I understand now. Doing this makes sense, and would be in parallel with the
Web Forms stuff, specifically for XUL.

Comment 13

16 years ago
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 as documentation.  That is should
be a requirement before checkin.
Attachment #140376 - Attachment is obsolete: true


16 years ago
Target Milestone: --- → mozilla1.7beta


16 years ago
Depends on: 234389


16 years ago
No longer depends on: 234389

Comment 14

16 years ago
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.
Depends on: 234389
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.


16 years ago
No longer depends on: 234389

Comment 16

16 years ago
(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

16 years ago
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?
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

16 years ago
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?
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.


14 years ago
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.