Feature: Widget's css_class should default to field name

[rbu]

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.

[rbu]

I'm happy to provide a patch, but I would appreciate general consent with the idea first so I don't provide waste.

[rbu]

see referenced patch for a proposed implementation

[kiorky]

Well, fine for me; rebase your patch !
@mcdonc any objection ?

[mcdonc]

AN issue with this is that forms that have mappings and sequences may have fields with the same name.

[kiorky]

For those, we can add a -X to identify them ?
like class="fieldname fieldname-0"

[mcdonc]

I think it might defeat the purpose, because the number would change if more fields were added.

[kiorky]

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"

[rbu]

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

[rbu]

ping

[mcdonc]

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.

[rbu]

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.

[dwt]

Ping again. This would be really helpful for us in production too, what about the merge status?

[dwt]

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?

[dwt]

I recognize that I may be a bit anxious, but could you please reply here and give a status update?

[dwt]

Well, here we go again... ping? Any news from the maintainers?

[rbu]

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

[mcdonc]

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.

[cguardia]

This is being addressed on issue #131. Closing this to reduce noise.