On Sat 23 Jul 2011 04:27:16 AM EST, Bart McLeod wrote: > Op 22-07-11 17:06, David Mintz schreef: >> On Thu, Jul 21, 2011 at 5:19 PM, Bart McLeod<mcl...@spaceweb.nl> wrote: >> >>> My wild guess is that you should override addMultiOptions in a custom >>> select element so that you can add the class attribs. >>> -Bart >>> >>> Op 21-07-11 21:49, David Mintz schreef: >>> >>> From my googling I see that this has been asked, and there's no >>> really >>>> easy >>>> answer, and none of the few answers I found work for my case. >>>> >>>> Basically, you have a label, a value and a category signified by the >>>> css >>>> class. I want the output to be something like >>>> >>>> <option label="apple" class="fruit" value="1">apple</option> >>>> <option label="spinach" class="vegetable" >>>> value="w">spinach</option> >>>> <option label="salmon" class="fish" value="1">salmon</option> >>>> >>>> And yes, I know there are option groups for organizing OPTION elements >>>> into >>>> a hierarchy, but I have my reasons for not wanting to go there. >>>> >>>> This will all come from a database. In high-level terms, how would you >>>> suggest approaching this? What classes/methods would you look into >>>> overriding? >>>> >>>> The purpose is to do fancy tricks using jQuery -- I need to detect the >>>> "category" on the change event. I can think of ways of hacking around >>>> this, >>>> e.g., load a JSON data structure that maps ids to categories and >>>> refer to >>>> that as needed. But... any other ideas? >>>> >> Thanks Bart. >> >> I noticed that $helper is a public property of >> Zend_Form_Element_Select, so >> rather than extending it, I have started working on a custom view helper >> instead, whose method signature is the same as that of formSelect in >> Zend_View_Helper_FormSelect. >> >> But the $options array that I am going to pass the >> Zend_Form_Element_Select >> constructor won't be like array( 1=> apple, 2 => spinach ), but rather >> array( array(value=>1,label=>spinach, class=>vegetable ), ... ) >> >> Any thoughts about this approach? I know that it's kind of crude to >> deliberately abuse Zend_Form_Element_Select's constructor and then >> give it a >> custom view helper to make up for it, but it looks like it's gonna work. >> >> > Indeed it sounds like it's going to work and I do not see the crude > aspect. If the constructor can be used this way it is the strength of > the architecture that makes this possible. I looked at the issue in the > tracker and that doesn't sound bad either, although I wonder how it > would perform with a lot of options.
I had a similar issue where I wanted to include a title attribute for each option. Ended up just going the manual rendering route as it gave me a lot more control, and as a bonus, doesn't require the gymnastics needed to get an array that works with formSelect. David -- List: fw-general@lists.zend.com Info: http://framework.zend.com/archives Unsubscribe: fw-general-unsubscr...@lists.zend.com
