[MAGNOLIA-7175] Allow form field configuration with objects rather than just classes Created: 12/Oct/17 Updated: 12/Mar/21 Resolved: 12/Mar/21 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface |
| Affects Version/s: | 5.5.6 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Torsten Landmann | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| 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)
|
||||
| Date of First Response: | |||||
| Description |
|
Code-driven configuration of property dialogs uses constructs like the following: cfg.fields.multi("fieldname") .label("Field label") .transformerClass(MultiValueChildNodeTransformer.class) .field(cfg.fields.link("link"))); The problem is that transformers can only be given as a class here rather than an actual transformer object. What I'd love to see (instead or as an addition) is the following overload: AbstractFieldBuilder#transformer(Transformer transformer) . Wouldn't you agree that this is a lot better to read and to use anyway? Why choose the complicated overload mentioned above when you can have this simple one? A similar scenario exists with validators. The two currently existing overloads are AbstractFieldBuilder#validator(ConfiguredFieldValidatorDefinition validatorDefinition) AbstractFieldBuilder#validator(GenericValidatorBuilder validatorBuilder) These overload have roughly the same problems as the transformers, they're totally unwieldy or even completely useless in many cases because of their inherent limitations. It would be a lot better if you could just add an overload that accepts an instance of a simple Validator interface that might look like this: interface Validator { public void validate(FormField field) throws ValidationException; } Another issue in the very same line of argument is ConfiguredFieldDefinition#setConverterClass(Class<? extends Converter<?, ?>> converterClass) . ConfiguredFieldDefinition#setConverter(Converter<?, ?> converter) . The last aspect I'd like to point out is that the issue was well done in the case of LinkFieldBuilder#identifierToPathConverter(IdentifierToPathConverter identifierToPathConverter) . Interestingly this method does even demand an IdentifierToPathConverter object in every case (no class allowed), even though this means something like typing .identifierToPathConverter(new BaseIdentifierToPathConverter())
most of the time, which looks a little funnier than using BaseIdentifierToPathConverter.class instead. Adding these overloads wouldn't even mean a lot of work and effort from your end imho. It would just mean adding a few simple lines to the Builders, the Definitions, and the Factories, and you'd be done. It's neither hard nor complex, but not doing it occasionally makes things hard and complex for us developers using Magnolia. |