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_bar
may 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_bar
may be in use. They converted to stuff likeJFormFieldFoo_Bar
, not sure about Namespaces.Here need to be careful with b.c.