Zend_Form: adding css class attrib to select option elements

[David Mintz-3]

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.

--
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/

[Bart McLeod]

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.
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[David Mintz-3]

On Thu, Jul 21, 2011 at 5:19 PM, Bart McLeod <[hidden email]> 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.


--
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/

[Kaiuwe]

Am 22.07.2011, 17:06 Uhr, schrieb David Mintz <[hidden email]>:

> 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.

Use CSS:

option[label='Foo'] {
     background-color: red;
}

option[label='Bar'] {
     background-color: yellow;
}

Or look at the issue tracker:  
http://framework.zend.com/issues/browse/ZF-3580

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[David Mintz-3]

On Fri, Jul 22, 2011 at 11:22 AM, Kaiuwe <[hidden email]> wrote:

> Am 22.07.2011, 17:06 Uhr, schrieb David Mintz <[hidden email]>:
>
>
>  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.
>>
>
>
> Use CSS:
>
> option[label='Foo'] {
>    background-color: red;
> }
>
> option[label='Bar'] {
>    background-color: yellow;
> }
>
> Or look at the issue tracker: http://framework.zend.com/**
> issues/browse/ZF-3580 <http://framework.zend.com/issues/browse/ZF-3580>
>
>

Actually  I'm not concerned about CSS presentation at all. The 'class'
attribute would be strictly semantic, and make it easier to know how to
handle certain 'change' events with jQuery.

The proposal in the issue tracker, if I understand it correctly, presumes
you want all your options to have the same class -- which is less than
trivial to do in js. In my case... well I already explained it earlier.

--
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/

[Kaiuwe]

Am 22.07.2011, 17:43 Uhr, schrieb David Mintz <[hidden email]>

> The proposal in the issue tracker, if I understand it correctly, presumes
> you want all your options to have the same class…

Sorry, wrong! It is for one option element.

There is a difference between: "addMultiOption" and "addMultiOptions".

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Bart McLeod]

Op 22-07-11 17:06, David Mintz schreef:

> On Thu, Jul 21, 2011 at 5:19 PM, Bart McLeod<[hidden email]>  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.

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[David Muir-2]

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<[hidden email]>  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: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]