search

lektor / lektor

The lektor static file content management system
https://www.getlektor.com/
BSD 3-Clause "New" or "Revised" License
3.84k stars 309 forks source link

implied_labels for drop downs disallow choices with an '='-sign in it #1032

Open bbbart opened 2 years ago

bbbart commented 2 years ago

I'm building a model with a field of the type select. My choices are URLs with query strings, and thus include '='-signs. This doesn't work now, because of implied_labels

https://github.com/lektor/lektor/blob/a170b4965eab7bf79e5ab739c715214e97e76bf7/lektor/types/multi.py#L35

By the way, this is otherwise also an undocumented feature, is it not?

The code allows me to have labels with an '=' in it, but not choices.

Is this intended and behaviour here to stay?

bbbart commented 2 years ago

(solved meanwhile by using an HTML entity instead of the '='-sign; of course this works in my specific case as I'm dealing with URLs, but doesn't solve this generically (also, it forces me to use the safe-filter in my template))

dairiki commented 2 years ago

FWIW, The current implied_label code appears in the initial commit of the current git repo (December 2015) and appears not to have been changed since that time.

It is nice, syntactically, to have a way that choice values and labels can be specified together (by using the "=" syntax) in the choices list, rather than in two separate lists (using choice_labels), but I agree that the current implementation is limiting.

I do worry about breaking backward compatibility if we change it at this point.

bbbart commented 2 years ago

I agree with both your points: it's nice to have, but breaking it probably will cause a lot of headaches. However... if I'm right that this is an undocumented feature, maybe not so many websites are using it after all?

Perhaps it can be a breaking change announced well up front? Of course, that doesn't yet bring us closer to a better implementation. :-)