Dropdown lists in a multi-line query result sub-template


I think Meteor has great potential for making great dropdown lists.
For multilingual purposes as well a data driven dropdown lists,
if such dropdown list appears in every line of query result (repeating the same sub template for each line) let’s say repeated 20 times in 20 lines:

  1. If that dropdown list repeats in each “line”, and that it is generated from a MongoDB query, does it generate a different cursor for each instance (creating some kind of lots of overhead)?

  2. if each instance has the same ID in each sub-template template, can it make a problem or IDs should be unique in all the page (rather than only within a template)?

  3. If OK, I use the ID for its purpose: a unique ID, I can then put some data as a class tag, but I would need to test them with a case block for each possible value. What is the other way (other than an hidden form field) to store the resulting value of the dropdown list? I maybe saw it somewhere, can we define a variable in the data context of the template? How?

  4. But if we need to give a different ID in each instance, how does meteor do that when using the sub-template for each line needed?


well, I am not sure, but I think you are thinking about this wrong.
There is no such think as ID in template usually, there is no mandatory _id as in publication.
Cause in publication it has to be there due to syncing with minimongo.

There are no lines, there are documents in nosql DB. And these coming from server have mandatory _id for DDP to track it etc.

In templates your data scope is object, or cursor etc. And you can iterate over cursors, arrays with #each. And inside #each data scope is that 1 item the #each is iterating over. So yes there can be ID but it does not have to be anything unique. And you can access it as this.ID as in Leaderboard example template events helper.

With select element, you can bind onChange event handler which reads $(“input”).selected property and store it whetever you want. Well, if I remember correctly best is to scope even that DOM read to Template.instance().$(“input”).selected or something like that.
I always mess which scope use in events and helpers.



Sorry, that was my weird sense of humor. I’ve read your questions twice but ended up more confused than at the start. Can you provide a minimal example, what you’re saying doesn’t make sense to me.


The idea is to populate dropdown menu lists (such as categories for a filter menu bar for filtering items displayed in a gallery or any other list or menu) . Data driven allows to add an item (without hard coding). Also, the router could allocate a standard collection name such a Products connection to a language specific collection (everything in English, or French, etc.) without the need to translate on the fly. NoSQL documents could allow in one document, the definition of a whole picklist with all its options in the order they should appear…
Ex.: In a collection defining picklists, one color document that includes its standard value in English:
English: {Blue, Blue}{Red,Red}{…}
French: {Bleue, Blue}{Rouge,Red}{…}
One collection per language.
The app would use the standard value for storage, or both values if storing in a document directly used by the user (such as my order history, see my order)