Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The Problem
I came up with this select-box variant in answer to a question on UX.SE: http://ux.stackexchange.com/a/48951/16187

enter image description here

However, working out how to implement it has been driving me mad ever since I wrote that post.

What I've tried
Initially I figured it would be easy enough to do.

The strategy I would have taken would be to model all the options in a javascript object, with their own name and selected properties, and then write a view function to display them as an unordered list or something.

I could then create the button as another javascript object, modelling it's own state, and have a view function spiting it out a representation of it into the widget. Maybe throw in some event code for transitioning between button states and I'm done.

Where I'm Stuck
The more I thought about that approach, the more I realised that having all of the state sitting in javascript objects was a terrible idea. I figured that I should probably store the state in the dom, and mutate it with javascript.

However I have no clear idea what that sort of architecture would look like, or how I should go about coding it.

Can you help me work out what a better high level implementation strategy for this sort of widget looks like?

share|improve this question
1  
There is never a best way to do something. Only the way which works best for you. –  Philipp Dec 13 '13 at 11:54
    
@Philipp I agree in principle, but in practice I know there will always be some ways that are worse than the others, no matter who is implementing them. Here, I'm good enough to spot that my way is a bad one, but not good enough to spot what the actual good way looks like. –  Racheet Dec 13 '13 at 16:50
    
(Also: point taken; question improved.) –  Racheet Dec 13 '13 at 16:52

1 Answer 1

up vote 4 down vote accepted

Why would you think that having the state in js would be bad? I think it's as good as in the DOM, if not better.

Anyway, you most likely already have the state in the DOM, since for display purposes you will add/remove classes from the list elements. In such cases I often just let jQuery find all elements with a certain class within the list. Get the amount of those elements and you already know how many were selected.

Put all of this functionality (count objects with class "selected_list_thing", update button state) in a function and add an mouse click handler to your list elements. There switch the class (eg add or remove "selected_list_thing" is blue) and then call the function you defined to update the button.

share|improve this answer
    
One of the issues with having the state in javascript rather than html is that if I want to add new options, I've got to go and fiddle with the javascript, not just add another <li>. –  Racheet Dec 13 '13 at 11:57
    
@Racheet good point, having a fixed sized array or similar would make things ugly. So at a minimum it would have to get the amount of items in the list at page load. And then if you want to make it even more dynamic and add options at run time it gets worse. This 'class based state' I described worked very well for me, even with hierarchical elements where sub-lists are loaded at run time. If you need even more information within the DOM and attach to an element then maybe jQuery.data() would be interesting too. –  thorsten müller Dec 13 '13 at 12:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.