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

[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

[klangleyParticipant]

Hi Dimitar,

Thanks for the reply! I understand that it is intended behavior, but surely there has to be a way to distinguish between (1) a user explicitly selecting a value in the dropdown and (2) the dropdown being set by code to another value. Either a way to “silently” change the value of the dropdown (as I can do with, for example, regular HTML input elements or various other jQuery widget sets), or else a way to determine, when an event is fired, whether or not it was user input that triggered it.

This would be a total dealbreaker for me — I simply cannot use jqWidgets if there is no way to distinguish between user input and programmatic change.

But I’m confident that can’t be the case, otherwise there’d be no way to accomplish something perfectly reasonable like my example (in which two dropdowns mutually affect each other’s state), short of something absurdly kludgy like a global variable.

Thanks,
KL

[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

[Author]

Posts