[MGNLUI-3882] Reference fields by name as well as by fully qualified classname Created: 18/May/16 Updated: 25/Jun/18 Resolved: 16/May/18 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | 5.4.6 |
| Fix Version/s: | 5.7 |
| Type: | Story | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Ilgun Ilgun |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||||||
| Epic Link: | LD: Simple dialog config | ||||||||||||||||||||||||||||||||||||||||
| Sprint: | Basel 79, Basel 147 | ||||||||||||||||||||||||||||||||||||||||
| Story Points: | 13 | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
Currently in a dialog definition, to specify the type of field you must supply a fully qualified class name of the field, for example: info.magnolia.ui.form.field.definition.TextFieldDefinition For legibility, ease of development, and to make fields easier to remember, a developer should be able to use a short name instead of needing to specify the class name. (But the fully qualified class name may still be used.) In this case: text Still to decide is which field should be used to supply this field name, maybe the same field "class" or a new field "fieldType". A developer should not have to specify a different dialog class for this functionality - it should work with the current default dialog. Validation: https://wiki.magnolia-cms.com/display/PMTEAM/Simplified+Dialogs+LDV |
| Comments |
| Comment by Christopher Zimmermann [ 23/May/16 ] |
|
Idea: Whether to only address this for fieldTypes with a special mechanism, or whether to introduce this ability more generically - the ability to reference a class by a name. |
| Comment by Christopher Zimmermann [ 22/Nov/16 ] |
|
TODO:
|
| Comment by Aleksandr Pchelintcev [ 07/Dec/16 ] |
|
After thinking about this for some time, I started questioning the necessity of connecting the definition class to an alias via the registry itself. There's a couple of reasons for that:
Another point against attempting to wire up such mechanism over the registry is the support for other similar entities (actions/traits/columns/you name it). If we implement smth for the field defs and it works nicely - users will logically expect us to spread the pattern application. But many (actually most) of other objects aren't covered by the registries at all. With all that in mind - I start to think that the variant with class annotating is not such a bad idea if done smartly:
|
| Comment by Ilgun Ilgun [ 07/Dec/16 ] |
|
Actually when I started really looking into N2B and M2B and how to implement it via Registry approach, I had some doubts about it. If we really need to implement the Registry approach;
When I offered Annotation based approach, I had more or less similar ideas as Sasha. One important remark from him make sense to me as well regarding module descriptor xml tag. I'd suggest to have module name in front of the alias e.g fooModule.text |
| Comment by Jan Haderka [ 07/Dec/16 ] |
|
While it's good to behave like a boy scout and leave place you have been cleaner than it was when you came, i'm afraid we are getting fairly far away from the original scope of allowing any John Doe to write his definition w/ just name of the field in mind and not remembering full class name. Also while annotations and effectively hardcoding name of the field in the class would be most likely be no issue for us, remembering some cases in the past, it would be issue for users of 3rd party developed modules that might have same name definitions or where module A introduces field AX that module B wants to replace w/ BX ... that with annotations would probably require us to define dependencies on the modules if that would be even enough. How about another round of discussion on next Arch meeting before going too deep? |
| Comment by Ilgun Ilgun [ 07/Dec/16 ] |
|
If it comes to there we have different options and what I would suggest it to not allow same name fields aliases. If one wants to give an alias to a field, we can clearly suggest them to use moduleName prefix. anyhow that's very deep topic at this stage. |
| Comment by Aleksandr Pchelintcev [ 08/Dec/16 ] |
|
had re: problem with the clashing names - anticipating that too, I have outlined in my comment that the effort would require a namespace concept of some sort (implicit/explicit/semi-explicit). Allowing users to provide alias mappings within the module names would make the substitution possible. |
| Comment by Aleksandr Pchelintcev [ 08/Dec/16 ] |
|
hadilgun We have discussed the matter again at the arch meeting and the conclusion was to hold on with the effort for now mostly due to the high amount of uncertainty about this feature.
As I said in the beginning, it looks like it makes sense to park the effort now and see how the situation evolves and whether this feature could be implemented as a requirement or a complement to some bigger story |
| Comment by Jan Haderka [ 08/Dec/16 ] |
What is uncertainty? Be sure that this request is not going away. It will not automagically disappear so I don't understand what is uncertain about it. What do you need to remove the uncertainty? The above statement for sure doesn't make that clear. - Why is resolving the type from dialog field itself, currently you specify in dialog class that is picked by transformer to instantiate the definition. When class property is committed we use the default class for type expected at given position or fail to instantiate bean. We could simply use again type property that we used in the past for this and have default impl be proxy class that would look up the underlying type definition implementation in the registry. The proxy itself could live where registries are or even more downstream to avoid circular dependency. And I'm sure there are other even better solutions, all I wanted to say is that there is no "later" in "we shall revisit this later". Users struggling with writing solutions on top of Magnolia is the bigger story we are solving now, and having to remember, type correctly or paste class names again and again is part of this bigger story. |
| Comment by Aleksandr Pchelintcev [ 13/Dec/16 ] |
|
After another iteration of this feature review at the architecture meeting the following decision have been made:
Two concepts have been considered:
Next steps:
|
| Comment by Bradley Andersen [ 14/Dec/16 ] |
|
I have not read all of this, but my initial thought would be just attack the fieldTypes registry. Then a clash might happen and need to be dealt with if you have created one with the same name in $your_module. Edit: I have only just learned this ticket exists, and am very happy it has been selected. |
| Comment by Mikaël Geljić [ 20/Dec/16 ] |
|
Notes from architects meeting:
|
| Comment by Christopher Zimmermann [ 05/Jan/17 ] |
|
Please include me in QA. |
| Comment by Philip Mundt [ 18/Jan/17 ] |