Binding/retrieving the value of a select element

[Hugh Lomas]

I'm having a problem with getting the value of a select element on the page, likely due to a lack of groking the derby data model and API. It seems like it should be quite simple. I was attempting to implement this similar to the generated project's handling of adding an item. 

https://gist.github.com/hughlomas/6090002

This just ends up spitting out undefined. I've also tried model.del('_page.call') with a similar undefined result.

The documentation for select elements is extremely sparse, I've searched through the group here, googled around, checked derby-examples. The "gender" dropdown on the directory example is using a bootstrap dropdown widget, not a normal select. The "sink" example is working with the selected attribute of the option elements and an x-bind when clicking the "select" button, however I am simply trying to get the value of the select. The select element's value should be defaulted to whatever the first option is, even without triggering an event like 'change'.

I would also desire for the behavior to be that each user viewing this form have a unique instance. What I mean is that if user A and user B are at /call/:prospectId and filling out this form representing a "new call", that user A would be editing his own instance of the form and user B would be editing his own instance, neither one sharing data. It's not clear to me exactly how to define this.

Thank you.

[Nate Smith]

We do our best to follow how HTML works, so you need to bind the value of the selected attribute on each item similar to the sink example. This is how HTML represents the selected state; <select> elements do not have a value attribute in HTML.

The way you have a different value for each instance of the form is you bind the value to a local value (in a collection that starts with _). Then when you want to save that value, such as on submitting a form, you get the value and save it in a remote collection that is synced and persisted.

- Nate

--
You received this message because you are subscribed to the Google Groups "Derby" group.
To unsubscribe from this group and stop receiving emails from it, send an email to derbyjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Hugh Lomas]

Regarding the second part of my question, I think my confusion about synced vs non-synced arose from the fact that the documentation mentions that collections that begin with a _ or $ are not synced, but if I create a page with, say, _page.prospect.name where _page.prospect is set via model.ref( "_page.prospect", prospect ) then technically the reference is being edited and thus is synced. Now that I have thought about it I believe that if it were not a reference that I would accomplish the behavior I was anticipating.

[Nate Smith]

Correct. The reference itself exists in the local collection, but the reference points to a remote collection. Therefore edits to items within the reference are synced. This is one of the core use cases for references.

--

[Hugh Lomas]

Not to be pedantic, but my reading of this http://www.w3.org/TR/html-markup/select.html and http://www.w3.org/TR/2012/WD-html5-20121025/the-select-element.html#dom-select-value seem to indicate that select elements do have a value. I know that getting an element via document.getElementBy___ and using .value will also return the selected value, and you can also "set" the value which will automatically set the relevant option to selected. 

I may be misinterpreting something though, I do not have much experience in reading those W3 definition documents.

Thank you for your responses though, I am not intending to be contrary.

[Nate Smith]

<select>'s have a value property via the DOM API, but they do not have a value attribute in HTML. Often properties and attributes are the same (such as in the case of id), but this is not always the case. The select.value property is derived from the value of the selected or first <option> element.

Because Derby renders HTML, we generally follow the HTML way of doing things.

[Hugh Lomas]

Going back to the gist I posted and referencing the sink example, I still feel confused on how precisely the value is bound after various attempts to get it working the way I expect it to.

At this point it appears that I have to set up a model with the array of option values, logically setting one of the values as a default, and then write a listener for a change event or similar to set the model value. It feels extremely roundabout when compared to the implementation of text inputs, which have the data-binding set up for you. I feel like I'm missing something obvious.

I simply desire for the select to be bound to the value of _page.call.result and to update that value when it changes. 

On Friday, July 26, 2013 12:46:26 PM UTC-4, Nate Smith wrote:

[Hugh Lomas]

Well after playing with it some more I have a solution that appears to be working, my only disconnect at this point as that the <p>{_page.call}</p>  in the "working as expected HTML" does not update the value when the select is changed. However the "submitted" value captures and inserts properly.

https://gist.github.com/hughlomas/6090002

[John Fletcher]

Thanks a lot Hugh for this gist.

After staring at it for 10 minutes the penny finally dropped and I realised why the value of the select actually gets saved in the model... because the binding works in reverse meaning that when something becomes selected, it gets set to _page.call.result by Derby. Of course it seems logical once you understand it :-)

John

2013/7/26 Hugh Lomas <hugh....@lodestarbpm.com>

[Curran Kelleher]

Just to update this thread with the current way of doing things, here's how it currently is done in the sink example:

<select id="title-select">
  {{each colors}}
    <option selected="{{titleColor === this.name}}">
      {{capitalize(this.name)}}
    </option>
  {{/each}}
</select>

Also related - Derby issue: Bind option or select value to model #146