Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #32936 > unrolled thread

Appropriate event for change of a HTML selection list

Back to article view | Back to comp.lang.javascript

Contents

  Appropriate event for change of a HTML selection list Janis Papanagnou <janis_papanagnou@hotmail.com> - 2017-04-04 19:44 +0200
    Re: Appropriate event for change of a HTML selection list Julio Di Egidio <julio@diegidio.name> - 2017-04-04 12:05 -0700
      Re: Appropriate event for change of a HTML selection list Janis Papanagnou <janis_papanagnou@hotmail.com> - 2017-04-05 15:22 +0200
        Re: Appropriate event for change of a HTML selection list Julio Di Egidio <julio@diegidio.name> - 2017-04-05 07:12 -0700
          Re: Appropriate event for change of a HTML selection list Julio Di Egidio <julio@diegidio.name> - 2017-04-05 07:19 -0700
    Re: Appropriate event for change of a HTML selection list RobG <rgqld@iinet.net.au> - 2017-04-09 21:28 -0700
      Re: Appropriate event for change of a HTML selection list "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-04-10 10:38 +0200

#32936 — Appropriate event for change of a HTML selection list

This post is (primarily) about which javascript event function should be used
in the context of a HTML selection list, and (secondarily) whether there's a
suggestion for a different approach.

The situation is as follows; I have a couple of HTML selection lists like

    <select id="I1" onchange="f(...)">
      <option value="0"> +0 </option>
      <option value="1"> +1 </option>
      ...

Whenever I change a value some computation f() is triggered by the function.

In addition to the above set of lists I have _one_ (similar) selection list

    <select id="setall" onchange="f_setall()">
      <option value="0"> +0 </option>
      <option value="1"> +1 </option>
      ...

to predefine all values (instead of using the individual select lists) for
convenience.

The use of 'onchange' is straightforward (and fine) for the first set of
lists but in the second single list (the one that should set the defaults)
it has an undesired effect; as designed it doesn't trigger the function if
the chosen value is the one already presently defined.

My use case is; if some of the first set of selection list values have
been changed I then want to set/reset all the values using the 'setall'
list.

I thought about two ways to handle that use case. a) Use an appropriate
existing other event type than 'onchange', but skimming through the list
https://www.w3schools.com/jsref/dom_obj_event.asp I did not found any.
And b), "invalidate" the value setting of the "setall" list when any of
the other selection lists had been triggered, so that subsequently using
"setall" will then be considered a change and 'onchange' triggered.

I am considering variant b) but if I missed some existing event function
I'd also use that, and pointers are welcome.

Currently, using 'onchange', I work around the issue by first selecting
any other value and then the desired value, but that is inconvenient.

(I hope the description is clear enough.)
Thanks in advance for all your useful replies.

Janis

[toc] | [next] | [standalone]

#32937

On Tuesday, April 4, 2017 at 7:44:41 PM UTC+2, Janis wrote:
> This post is (primarily) about which javascript event function should be
> used in the context of a HTML selection list, and (secondarily) whether
> there's a suggestion for a different approach.

Change the (view) model, let the UI reflect the model.

Start by learning Knockout: <http://knockoutjs.com/>.

Have fun.

Julio

[toc] | [prev] | [next] | [standalone]

#32941

On 04.04.2017 21:05, Julio Di Egidio wrote:
> On Tuesday, April 4, 2017 at 7:44:41 PM UTC+2, Janis wrote:
>> This post is (primarily) about which javascript event function should be
>> used in the context of a HTML selection list, and (secondarily) whether
>> there's a suggestion for a different approach.
> 
> Change the (view) model, let the UI reflect the model.
> 
> Start by learning Knockout: <http://knockoutjs.com/>.
> 
> Have fun.

Thanks, Julio.

I'd rather not want to redesign the whole code to solve a comparably
simple technical detail, though.[*] I also want to avoid introducing
third party lib's. - Sorry for not having been clear about that. I'm
aware that me asking for a "different approach" might invite responses
that include suggestions of arbitrary complexity or effort. This was
not my (primary) concern. But thanks anyway for the knockoutjs pointer.

If common opinion is that the intended primitive task is not solvable
in any simple way that's also okay for me, since (as I said upthread)
I could implement a staightforward and simple workaround.

Janis

[*] The library link you gave refers to "Model View Viewmodel" and
Wikipedia says: "A criticism of the pattern comes from MVVM creator
John Gossman himself, who points out overhead in implementing MVVM
is "overkill" for simple UI operations."

[toc] | [prev] | [next] | [standalone]

#32942

On Wednesday, April 5, 2017 at 3:22:28 PM UTC+2, Janis wrote:
> On 04.04.2017 21:05, Julio Di Egidio wrote:
> > On Tuesday, April 4, 2017 at 7:44:41 PM UTC+2, Janis wrote:
> >> This post is (primarily) about which javascript event function should be
> >> used in the context of a HTML selection list, and (secondarily) whether
> >> there's a suggestion for a different approach.
> > 
> > Change the (view) model, let the UI reflect the model.
> > 
> > Start by learning Knockout: <http://knockoutjs.com/>.
> > 
> > Have fun.
> 
> Thanks, Julio.
> 
> I'd rather not want to redesign the whole code to solve a comparably
> simple technical detail, though.[*] I also want to avoid introducing
> third party lib's. - Sorry for not having been clear about that. I'm
> aware that me asking for a "different approach" might invite responses
> that include suggestions of arbitrary complexity or effort. This was
> not my (primary) concern. But thanks anyway for the knockoutjs pointer.
> 
> If common opinion is that the intended primitive task is not solvable
> in any simple way that's also okay for me, since (as I said upthread)
> I could implement a staightforward and simple workaround.
> 
> [*] The library link you gave refers to "Model View Viewmodel" and
> Wikipedia says: "A criticism of the pattern comes from MVVM creator
> John Gossman himself, who points out overhead in implementing MVVM
> is "overkill" for simple UI operations."

Unfortunately Wikipedia, as far as software engineering and development articles are concerned (but this has happened with other topics, too), has been hijacked and is simply full of the worst crap: do the exact opposite of what they say and you'd be way better off already.

That said, no, neither my reply nor Knockout the library are about MVVM specifically: indeed, MVVM per se is a problematic pattern (), and for non-trivial GUI's I keep using full-fledged MVC.

[toc] | [prev] | [next] | [standalone]

#32943

On Wednesday, April 5, 2017 at 4:12:27 PM UTC+2, Julio Di Egidio wrote:
> On Wednesday, April 5, 2017 at 3:22:28 PM UTC+2, Janis wrote:
> > On 04.04.2017 21:05, Julio Di Egidio wrote:
> > > On Tuesday, April 4, 2017 at 7:44:41 PM UTC+2, Janis wrote:
> > >> This post is (primarily) about which javascript event function should be
> > >> used in the context of a HTML selection list, and (secondarily) whether
> > >> there's a suggestion for a different approach.
> > > 
> > > Change the (view) model, let the UI reflect the model.
> > > 
> > > Start by learning Knockout: <http://knockoutjs.com/>.
> > > 
> > > Have fun.
> > 
> > Thanks, Julio.
> > 
> > I'd rather not want to redesign the whole code to solve a comparably
> > simple technical detail, though.[*] I also want to avoid introducing
> > third party lib's. - Sorry for not having been clear about that. I'm
> > aware that me asking for a "different approach" might invite responses
> > that include suggestions of arbitrary complexity or effort. This was
> > not my (primary) concern. But thanks anyway for the knockoutjs pointer.
> > 
> > If common opinion is that the intended primitive task is not solvable
> > in any simple way that's also okay for me, since (as I said upthread)
> > I could implement a staightforward and simple workaround.
> > 
> > [*] The library link you gave refers to "Model View Viewmodel" and
> > Wikipedia says: "A criticism of the pattern comes from MVVM creator
> > John Gossman himself, who points out overhead in implementing MVVM
> > is "overkill" for simple UI operations."
> 
> Unfortunately Wikipedia, as far as software engineering and development articles are concerned (but this has happened with other topics, too), has been hijacked and is simply full of the worst crap: do the exact opposite of what they say and you'd be way better off already.
> 
> That said, no, neither my reply nor Knockout the library are about MVVM specifically: indeed, MVVM per se is a problematic pattern (), and for non-trivial GUI's I keep using full-fledged MVC.

Sorry, submitted by mistake, here is the rest:

MVVM per se is a problematic pattern (I'll omit the details), and for
non-trivial GUI's I keep using full-fledged MVC.  But Knockout is not tied
to either, Knockout essentially just takes away all the plumbing and lets
you concentrate on designing the flow and control: of course you can do the
same without Knockout...  Indeed, I was answering your question, about
better approaches, and the answer is mainly architectural.

Julio

[toc] | [prev] | [next] | [standalone]

#32985

On Wednesday, April 5, 2017 at 3:44:41 AM UTC+10, Janis wrote:
> This post is (primarily) about which javascript event function should be used
> in the context of a HTML selection list, and (secondarily) whether there's a
> suggestion for a different approach.
> 
> The situation is as follows; I have a couple of HTML selection lists like
> 
>     <select id="I1" onchange="f(...)">
>       <option value="0"> +0 </option>
>       <option value="1"> +1 </option>
>       ...
> 
> Whenever I change a value some computation f() is triggered by the function.
> 
> In addition to the above set of lists I have _one_ (similar) selection list
> 
>     <select id="setall" onchange="f_setall()">
>       <option value="0"> +0 </option>
>       <option value="1"> +1 </option>
>       ...
> 
> to predefine all values (instead of using the individual select lists) for
> convenience.
> 
> The use of 'onchange' is straightforward (and fine) for the first set of
> lists but in the second single list (the one that should set the defaults)
> it has an undesired effect; as designed it doesn't trigger the function if
> the chosen value is the one already presently defined.
> 
> My use case is; if some of the first set of selection list values have
> been changed I then want to set/reset all the values using the 'setall'
> list.

Presumably the "setall" select is initially set to the same default value as all the other selects. As soon as any of the others is changed from the default value, change the "setall" select to a blank setting, e.g.

  <select id="setall" onchange="f()">
    <option></option>
    <option value="0"> +0 </option>
    <option value="1" selected> +1 </option> // default for all selects
      ...
  </select>

so that as soon as any other select is changed, "setall" is set to a selectedIndex of 0. Now any selection to a valid value will dispatch a change event, and a user manually setting it to the first option does nothing (or maybe shows some type of information message).

Perhaps while all selects have the same value, the "setall" select is disabled. Maybe some user trials are required to see which behaviour suits best, it likely depends on whether there are a small number of users who will use it frequently, or a large number who use it infrequently.

-- 
RobG

[toc] | [prev] | [next] | [standalone]

#32986

RobG <rgqld@iinet.net.au> wrote on 10 Apr 2017 in comp.lang.javascript:

> On Wednesday, April 5, 2017 at 3:44:41 AM UTC+10, Janis wrote:
>> This post is (primarily) about which javascript event function should
>> be 
> used
>> in the context of a HTML selection list, and (secondarily) whether
>> there' 
> s a
>> suggestion for a different approach.
>> 
>> The situation is as follows; I have a couple of HTML selection lists
>> like 
>> 
>>     <select id="I1" onchange="f(...)">
>>       <option value="0"> +0 </option>
>>       <option value="1"> +1 </option>
>>       ...
>> 
>> Whenever I change a value some computation f() is triggered by the
>> functi 
> on.
>> 
>> In addition to the above set of lists I have _one_ (similar) selection
>> li 
> st
>> 
>>     <select id="setall" onchange="f_setall()">
>>       <option value="0"> +0 </option>
>>       <option value="1"> +1 </option>
>>       ...
>> 
>> to predefine all values (instead of using the individual select lists)
>> fo 
> r
>> convenience.
>> 
>> The use of 'onchange' is straightforward (and fine) for the first set
>> of lists but in the second single list (the one that should set the
>> defaults 
> )
>> it has an undesired effect; as designed it doesn't trigger the function
>> i 
> f
>> the chosen value is the one already presently defined.
>> 
>> My use case is; if some of the first set of selection list values have
>> been changed I then want to set/reset all the values using the 'setall'
>> list.
> 
> Presumably the "setall" select is initially set to the same default
> value as all the other selects. As soon as any of the others is changed
> from the default value, change the "setall" select to a blank setting,
> e.g. 
> 
>   <select id="setall" onchange="f()">
>     <option></option>
>     <option value="0"> +0 </option>
>     <option value="1" selected> +1 </option> // default for all selects
>       ...
>   </select>
> 
> so that as soon as any other select is changed, "setall" is set to a
> selectedIndex of 0. Now any selection to a valid value will dispatch a
> change event, and a user manually setting it to the first option does
> nothing (or maybe shows some type of information message). 
> 
> Perhaps while all selects have the same value, the "setall" select is
> disabled. Maybe some user trials are required to see which behaviour
> suits best, it likely depends on whether there are a small number of
> users who will use it frequently, or a large number who use it
> infrequently. 

So the undesired effect is,
that the onchange is not triggered when there is no change?

Meseems that is the logical consequence of "onchange".

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web