Often times, we want to apply styles to certain form elements that can easily done purely in CSS. It feels like overkill to create a new widget for every schema node just to set the css class.
It would be a lot more helpful if the css_class of deform's Widget would default to a daherized/sanitized version of field.name with "deform-" prepended.
I'm happy to provide a patch, but I would appreciate general consent with the idea first so I don't provide waste.
Add default css_class to fields, Pylons/deform#97
see referenced patch for a proposed implementation
Well, fine for me; rebase your patch !
@mcdonc any objection ?
AN issue with this is that forms that have mappings and sequences may have fields with the same name.
For those, we can add a -X to identify them ?
like class="fieldname fieldname-0"
I think it might defeat the purpose, because the number would change if more fields were added.
looking to c8df92b ref in #98, i think this is not necessary to have css classes on "li values" because you can easily match the li in css with #97 or even a49904f with "ul.fieldname li"
Rebasing this was a mess, I have done so in this branch: https://github.com/rbu/deform/tree/issue-97-98
Regarding uniqueness. These auto-generated css_classes are not unique, but I did not indend them to be. They are intended as a stable way to address a certain field's widget and style it (e.g. 'deform-field-username'). If you have multiple such fields in a sequence and want to address them individually, one could use :nth-child (plus a polyfill if needed).
Revert "Add default css_class to fields, Pylons/deform#97"
This reverts commit 7fcd660.
Ugh, sorry for the tremendously late response on this. This code looks great, but I'm a bit cramped for time to really evaluate it to see if it breaks anything. I just wanted to let you know it's not forgotten about.
Thanks for getting back. We've been holding back on relying on this for production since we don't want to maintain a fork, but it would be very helpful for our form styling to get this in and start relying on it.
Ping again. This would be really helpful for us in production too, what about the merge status?
ping... We're about to package this patch for ourselves as it would be so usefull - could you please at least give a word what the status of this is?
I recognize that I may be a bit anxious, but could you please reply here and give a status update?
Well, here we go again... ping? Any news from the maintainers?
@kiorky @mcdonc This bug report seems to be more noise than discussion about the feature. Is there anything we can do to get this feature merged soon?
On a general note, I understand if you oppose a certain feature in your library (even if I may end up debating this with you), but getting positive feedback and no merge in 6 months is rather discouraging (for providing pull requests for other bugs that I opened).
Ugh. Sorry. I don't oppose the feature at all. My status on it is still the same: I'm still trying to figure out how to get the time to find out if it doesn't break anything. It's piled below a bunch of other things that are also in the same status. I'm a terrible maintainer, but it is what it is at this point, just trying to tread water. Sorry.
This is being addressed on issue #131. Closing this to reduce noise.
When creating the default widget for a field, give it a default item_…