Currently one has to type fully qualified classname in order to define a field in any configuration such as
However, fully qualified classnames are hard to remember and verbose. If we were to simplify/reduce the verbosity from the configuration, our configuration files would look much nicer and compact as well as It wouldn't be a hassle to remember which definition is coming from which class and hence its fully qualified class name. The ticket of DEV-338 - Getting issue details... STATUS is created to tackle this problem and MGNLUI-3882 - Getting issue details... STATUS to implement it. Perhaps for the time being It may seems like we are only targeting fields ,however, the solution which comes up from the discussion regarding the fields should/could be applied relatively easy to the other parts of Magnolia configuration such as actions.
Those solution can be applied at info.magnolia.ui.form.field.factory.FieldFactoryFactory#createFieldFactory(FieldDefinition, Object...).
This method is responsible to create a field factory instance out of the FieldDefinition, its the place when the query the registry for FieldTypeDefinition against given definition class.
We may annotate fields like below and get those fields easily in the runtime. Those annotation would contain values where we use it as reduced definitions (shortcuts).
Ideally we would create a component out of it e.g AnnotationResolver which would be generic for all annotations we have say fields, actions, etc.
Resolver also has to update the key-value pairs over time in order words, it has to scan the classpath like ClasspathScanner.
- Self documented
- Elegant look
- Not error prone
- Potential to apply it for all definitions
- Need to edit Java code
- All definitions should be modified with the Annotation
- Performance ?
2) Pre-defined key-value pair
A predefined key-value pair could be used to generate the reduced version of field definitions.
- Straightforward for user
- Ugly looking structure to maintain
- Old school
3) Runtime Classpath search with specific Pattern
Basically we can get all the subclasses of FieldDefinition and if the given reduced class form matches the pattern we can easily identify which class it points to. For instance:
- text → TextFieldDefinition
- basicupload → BasicUploadFieldDefinition
- checkbox → CheckBoxFieldDefinition
As you might grasp there is a pattern which makes is easier to detect those reduced form definitions. It's very doable to create an instance of a definition class based on the given keyword for instance 'text'.
The biggest drawback for this approach is that there would be conflicts since we would have to search the whole Classpath for fields due to users' custom field implementations. Upon a conflict it would be hard if not impossible to detect which definition is the correct one. Theoretically it's possible to have this approach without conflicts with users naming the classes properly(ideally with suffix/prefix of the module or similar) but this wouldn't be a nice thing to do.
- Predefined pattern
- No code changes in the definitions
- Error prone at wrong hands
- Might be conflicts over different packages
- Performance ?
4) Registry reference Id
There are already defined reference keys for those fields such as 'textField' for TextFieldDefinition. We can make use of those and simply make a call to the registry in order to get the definition. Users need to simply adjust those names as they wish to.
- Already defined values for default definitions
- Easily configurable
- Can't think of any
Migration and Fallback Mechanism
Although this chapter still sort of depends on the accepted solution, migration wouldn't be necessary for due to the fact that the actual plan here is to use both of the way to define a field class meaning that one may use the reduced version or directly fully qualified version. Fallback mechanism on the other hand, also depends on the accepted solution but ideally it shouldn't be even necessary since both ways would be accepted.
- Some mechanism/app to display user which shortcut would point to which definition class.
- If we go with solution#4, we should be reducing the reference ids e.g 'textField' to 'text' would look nicer and we know that its already a field.