DropdownField that allows attributes for options

103 views
Skip to first unread message

Marijn Kampf

unread,
Mar 25, 2015, 6:47:16 AM3/25/15
to silverst...@googlegroups.com
Hi,

I've created a small addition to the dropdownfield that allows adding attributes to option elements (rather than just the select element).
$field = DropdownAttributesField::create(
    'Count',
    'Count',
    array(
        '1' => 'One',
        '2' => 'Two',
        '3' => 'Three'
    )
)->setOptionsAttributes(
    'data-bats',
    array(
        '1' => 'batty',
        '2' => 'batty batty',
        '3' => 'batty batty batty',
    )
);

Generates code like:

<div id="Count" class="control-group form-group">
  <label for="Form_Form_Count">Count</label>
  <select name="Count" class="dropdownattributes form-control" id="Form_CountingForm_Count">
    <option value="1" data-bats="batty">One</option>
    <option value="2" data-bats="batty batty">Two</option>
    <option value="3" data-bats="batty batty batty">Three</option>
  </select>
</div>
Would there be enough interest in this feature to add it to core or would that just be bloat?

https://github.com/marijnkampf/silverstripe-dropdown-attributes-field

Cheers,
--

Marijn Kampf
Exadium - Online Marketing & Web Development
mar...@exadium.com / www.exadium.com
uk mobile: 07 525 49 9234 / uk landline: 01446 620 436 / nl telefoon: 0357 110 379
international mobile: 0044 7525 49 9234 / phone uk: 0044 1446 620 436 / phone nl: 0031 35 71 10 379

Nic Horstmeier

unread,
Mar 25, 2015, 9:16:59 PM3/25/15
to silverst...@googlegroups.com
Hi all,

First time posting here, but watch the threads regularly. I ran into this need not too long ago and would love for this to be supported. I'll be checking out the github repo in the meantime as it looks promising!

- Nic (muskie9)

Will Rossiter

unread,
Mar 25, 2015, 9:31:59 PM3/25/15
to SilverStripe Development
The markup is generated by a template so cleanest way may be to use $formField->setTemplate(‘MyDataOptionsTemplate’) then you can modify the template / include your own loops / attributes / classes anything you want to. Personally I’d like to stay away from increasing the core code base for such specific things. Modules are all good though.


--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

Message has been deleted

Martimiz

unread,
Mar 26, 2015, 11:42:21 AM3/26/15
to silverst...@googlegroups.com
I haven't yet looked at this module, but in favour of adding something like this to core:  since SilverStripe already supports adding attributes to formfields, why should options be an exception and need their own module?

Must be a coincidence but it would have helped me too on a very recent project :)

Martine

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Mar 31, 2015, 5:51:26 PM3/31/15
to silverstripe-dev
On 27 March 2015 at 04:40, Martimiz <mart...@gmail.com> wrote:

in favour of adding something like this to core:  since SilverStripe already supports adding attributes to formfields, why should options be an exception and need their own module?

​+1

Patrick Nelson

unread,
Mar 31, 2015, 6:17:32 PM3/31/15
to silverst...@googlegroups.com
Might I suggest someone drop this into http://silverstripe.uservoice.com/forums/251266-new-features so we don't get a truck load of +1's? Might make it easier to gauge demand.

That being said (more than just a +/-1 vote): I like the idea of using modules to extend core functionality for fringe cases. Problem is, how frequently is this needed? Another tangential issue I've got on my end is that, while I'm happy with the modules I've got installed (and I could have many or just one or two), I don't like that they're in the root of the site. But that's quite a tangent indeed.

- Pat

--

Marijn Kampf

unread,
Apr 1, 2015, 2:28:43 AM4/1/15
to silverst...@googlegroups.com

Uncle Cheese

unread,
Apr 1, 2015, 4:23:20 PM4/1/15
to silverst...@googlegroups.com
Yeah, this really speaks to the bigger issue that there's just no API for the options themselves. That the $Options array is computed in the Field() method is particularly problematic, because there's no way to really overload it. (This wreaked havoc on my display-logic module). A getOptions() method would make these fields much more customisable.

Patrick Nelson

unread,
Apr 2, 2015, 10:48:53 AM4/2/15
to silverst...@googlegroups.com
Maybe somewhat tangential, but instead of using the originally proposed API (which was implemented as a module), maybe just have two main components added to the API for DropdownField:

1. Ability to find an option element by it's value, e.g.: $dropdown->findOptionByValue("foo");
2. Ability to access that option as it's own object with its own common methods, like any field (allowing for more extensibility, not just a single extra attributes method), e.g.: $option->doWhateverOptionFieldsCanDo("bar", sqrt(-1));

Maybe that last method was a bit verbose, but use your imagination.

On Wed, Apr 1, 2015 at 4:23 PM, Uncle Cheese <aa...@silverstripe.com> wrote:
Yeah, this really speaks to the bigger issue that there's just no API for the options themselves. That the $Options array is computed in the Field() method is particularly problematic, because there's no way to really overload it. (This wreaked havoc on my display-logic module). A getOptions() method would make these fields much more customisable.

Reply all
Reply to author
Forward
0 new messages