NOT submitting to a form — hope this is an easy question…

[klangleyParticipant]

Just started experimenting with jqWidgets and right away I’ve run into a roadblock that, despite a lot of searching and browsing of the documentation and the forums, I can’t seem to find a solution for. Mostly people seem to be asking the exact opposite question to mine!

Briefly, how can I not submit the value of a jqwidget when a form is submitted with a submit button? The widget in question here is a jqxDropDownList, although I’m guessing I’ll have the same issue with other jqwidgets as well. I am doing, effectively, the following:

<DIV ID='foo'></DIV>
<SCRIPT>
  $('#foo').jqxDropDownList({source: ...});
</SCRIPT>

which works fine, except that when I submit a form on the page, I am getting the selected value of the dropdown submitted as foo. Note that I did not add a NAME='foo' attribute to my <DIV>. When I inspect my rendered HTML, though, it looks like jqwidgets is adding an <input type='hidden' name='foo'> tag. How can I avoid this?

Thanks in advance for any enlightenment…
KL

[Peter StoevKeymaster]

Hi klangley,

We have a sample which demonstrates how to submit DropDownList. Please, look at: http://www.jqwidgets.com/jquery-widgets-demo/demos/php/dropdownlist.htm?arctic

Best Regards,
Peter Stoev

jQWidgets Team
http://www.jqwidgets.com

[klangleyParticipant]

Hi Peter,
Thanks for the reply. I apologize if my question was unclear. I understand how to submit DropDownList via a form, as in your example. The problem is precisely that I don’t want the DropDownList being submitted with my form! Basically, I have code like this:

<form id="form" method="post" action="my.cgi">
   ...various input elements to be submitted with the form....
   <input type="submit" value="Submit form"/>
   <div id="notpartoftheform"">
      <div id="dropdownlist"></div>
      ...various other input elements not to be submitted with the form....
   </div>
</form>
<script>
   $("#dropdownlist").jqxDropDownList(....);
</script>

Note that I did not specify a name attribute in my dropdownlist. Thus, I would expect its value not to be submitted when I submit the form (just as it wouldn’t be if I had an ordinary <select id="dropdownlist"/> with no name attribute). But it seems like if a name is not specified, jqWidgets uses the id instead of the name and posts to the form anyway. This is a major problem for my application as the server side will reject unexpected form input. How can I get jqxDropDownList (and other widgets) not to be included when I post a form?

(It might seem odd that I am doing it this way, but it’s the way it has to be. The whole application is embedded inside a form which can be submitted in the traditional way, but the code using jqWidgets is conmunicating purely via Ajax — that is, for example, if the value of the dropdown changes, I trigger an event and handle the change that way; but I don’t ever want the value of the dropdown to be sent along with the surrounding form.)

Thanks again for the help,
KL

[Peter StoevKeymaster]

Hi klangley,

It seems that I cannot offer you a solution for your scenario. Most of the users expect some value to be submitted and consider the DropDownList as a Form element. That’s the reason we submit it.

Best Regards,
Peter Stoev

jQWidgets Team
http://www.jqwidgets.com

[klangleyParticipant]

Hi Peter,

That is really disappointing. It more-or-less means I can’t use jqWidgets for my application.

It seems on the surface to be a really well-designed and attractive widget set, but if it has this kind of unconventional behavior (e.g. using the id attribute to post to a form when a name is not specified) that cannot be turned off or worked around (so there is literally no way not to post to a form), it’s just not going to work for me. Please note that I would have been purchasing an enterprise license.

I don’t see the point of forcing a widget to be a form element whether the user wants it to be or not. “Most” people may consider it to be one, but not everyone does — it’s pretty standard to use JavaScript/jQuery/AJAX rather than forms to handle input elements. If I use a plain <select> tag with no name attribute, it won’t get submitted as a form, and I can handle it with the change event. The convention is to use the name attribute (not the id attribute) to indicate that an input element is part of a form. I don’t understand why jQWidgets would intentionally break this convention to the extent that it’s literally impossible not to post an element to the form.

I’ve run into another deal-breaker issue which I posted about in this forum, and received basically a “this is intended behavior” reply. There’s apparently no way to distinguish between user input (e.g. “I select element #5 in the dropdown”) and a programmatic change in a widget’s state (e.g. “my code sets the selected index of the dropdown to 5”) — both fire the select event and there doesn’t seem to be a way either to differentiate between the two events, or else to programmatically change the widget’s state without firing an event. This is disastrous for my application: imagine the simple case of two widgets that need to mutually track each other’s state; if the user changes one, an event fires which can trigger a function to update the other one, but if that also fires an event, you get an endless loop. This is another case in which jqWidgets seems to be breaking convention for no good reason. There’s no problem implementing this kind of thing with plain jQuery because programmatically changing the widget’s state doesn’t fire an event unless you explicitly ask it to.

Again, very disappointed that there appears to be no way around what seem to me to be arbitrary and easily-avoidable limitations on the flexibility of jqWidgets. I’m sure it wouldn’t be hard for jqWidgets to use the name attribute rather than the id attribute for form submission, or to allow “silent” update of a widget’s state, since that’s the way everyone else does it. Making it impossible to work around these issues basically rules out, for me, what would otherwise be a perfect fit for my application.

KL

[Peter StoevKeymaster]

Hi klangley,

I am sorry that our widgets do no meet your technical requirements. We will continue adding new features, new widgets and improving our documentation, but that is a long process.

Best Regards,
Peter Stoev

jQWidgets Team
http://www.jqwidgets.com/

[klangleyParticipant]

Thanks, Peter, but this to my mind isn’t a “new feature” or a “new widget” and, I gather from your replies, it isn’t a documentation issue either. Apparently there is no way to prevent a widget from being posted to a form, and this is because you’re incorrectly using the id attribute when no name attribute is specified. That, frankly, is a bug — it is an incorrect implementation of a well-accepted web standard: elements without a name attribute are not posted to a form. And there is, I gather, absolutely no workaround!

I’d argue that the complete inability to distinguish between a programmatic status change and a user-initiated selection is an out-and-out bug, too. At the very least it is such a severe limitation that I would think you would prioritize it over adding new features. It makes it virtually impossible to write complicated event-driven applications (e.g. there’s no straightforward, clean way to have two dropdowns each of which can affect the other’s value, as I pointed out before).

Both of these bugs seem like they’d be trivial to fix (e.g. if a name attribute isn’t specified, just don’t use the id attribute as the name of a hidden <input> instead; provide some kind of “silent” option when setting a widget’s value, or alternatively provide a way to distinguish between a user-initiated and a programmatically-initiated event). Surely this would be a lot less work than, say, adding new widgets?

Am I to assume that, were I to purchase an enterprise license with “Platinum Support,” you would still be unwilling to address these bugs and others like them? Because so far, all I have seen is, basically, dismissal of my concerns.

[Peter StoevKeymaster]

Hi klangley,

Ok, thank you for the feedback. I am not going to argue about anything. We will consider your comments if we decide to make any changes in the future versions.

Best Regards,
Peter Stoev

jQWidgets Team
http://www.jqwidgets.com/

[Author]

Posts