User tests: Successful: Unsuccessful:
Enables use of snake_case style for custom fields (and rules and filters) in form XML by adding an additional class_exists() checks for entity types normalized to CamelCase. Currently, using snake_case is not possible unless a class alias is created through the class map.
With this PR, it will be possible to define a custom field class, for example, in pure CamelCase => ComplexTypeField and then use <field ... type"complex_type"/> to use it in the XML.
This change should be non-breaking as it only adds additional checks without altering existing code.
For custom fields with CamelClass compliant class names (like WorkflowComponentSections), you can replace their usage in forms with snake_case.
snake_case style in XML cannot be used for custom fields with CamelCase compliant class names.
Using snake_case for custom fields like the WorkflowComponentSections should be possible. Existing forms should work as expected.
None I'm aware of.
| Status | New | ⇒ | Pending |
| Category | ⇒ | Libraries |
Fields like
foo_barmay be in use. They converted to stuff likeJFormFieldFoo_Bar, not sure about Namespaces. Here need to be careful with b.c.
I think we should be good wrt B/C with this PR as we're only adding another check for matches. There are some foo_bar usages made possible right now through aliases in the classmap.
I don't know much about the B/C implications but maybe we can move to real camelCase class names and snake_case in forms someday.
What is the purpose of this PR. There is a codestyle that says it should be camelcase
What is the purpose of this PR. There is a codestyle that says it should be camelcase
I'm unaware, is there one that says it should be camelcase in the XML too?
Fair enough. Thank you for having a look :)
Fields like
foo_barmay be in use. They converted to stuff likeJFormFieldFoo_Bar, not sure about Namespaces.Here need to be careful with b.c.