Below is the draft I came up with few weeks ago, starting from the question "How simply would I want to configure my app?".
APPROVED
DEV-798 - Getting issue details... STATUS
MAGNOLIA-7469 - Getting issue details... STATUS
About the $type alternative
Rationale
- Provide alternative, simplified notation to fully-qualified Java class names in YAML configs (current
class:meta property).- help memorizing instead of copy-pasting
$typeis an alternative to theclasssetup, virtually anywhere in the definition object tree.$typeresolution would be backed by one, low-levelTypeResolver, not a configRegistry.- building upon
TypeResolverpluggability that was created first for fieldType aliases.
- building upon
- A
TypeResolverprovides implementations, whereas a configRegistrycollects instances of similar objects. - Available implementations would be provided via annotations.
- Main rationale here: when providing custom (Java) implementations, one is already on the back-end side.
- Most trivial way to instruct Magnolia to use it is to annotate it.
- Anything "foreign" to the Java class itself is perceived as overkill.
- e.g. version handler, light-module definition, module-descriptor mapping
Examples
@ConfiguredType("emailValidator")
class EmailValidatorDefinition implements ValidatorDefinition
/* @Validator extends a generic @TypeAlias annotation */
@Validator("emailValidator")
class EmailValidatorDefinition implements ValidatorDefinition
—See UI PR #679 for a draft implementation of the latter example.
Direction
- The suffix is a convention and should represent where the definition is intended to go.
- The 2bean mechanism may *not* care if user puts up a column where a field is expected. This will cause a definition problem anyway.
- JCR defs / n2b don't have to be supported
Field type registry evolution & default mappings
While the type-resolver facility seems fairly straightforward for simple implementations such as custom columns or validators, our current FieldTypeRegistry is a bit more complex.
- Re: Field types, cut indirection between
FieldDefinitionandFieldFactory?- i.e. put #factoryClass on
FieldDefinition, same as #implementationClass on various components
- i.e. put #factoryClass on
- Then how do we customize all text fields?
- or decorate richTextField from DAM to add image support
- would have to make all
FieldDefsinterfaces w/ defaultConfigured*impl - then let consumer override type-mapping in XML
- or ideally/later also declare type-mappings via annotations
Further app descriptor flattening exercise
$type: contentApp # Fancy any new generic type-mapping facility vs. java classes?
#class: info.magnolia.ui.contentapp.ContentAppDescriptor
#class: info.magnolia.ui.AppDefinition
#class: info.magnolia.ui.ContentAppDefinition
#class: info.magnolia.ui.ContentApp
icon: icon-asset-pool
label: Cars
contentType: cars # High-level contentType reference, analog to contentConnector or datasource, on app level
contentType: !inline # or low-level datasource config
datasource:
$type: jcrDatasource
workspace: cars
# Mind there's no subapp :) we can infer browser config from columns, and detail config from editor
columns: # Maybe w/ aliases such as properties, facets... (but 95% content apps have tables, hence columns)
- name: "mgnl:name" # - Example predefined column names coming w/ presets (expandRatio/width, sorting, formatter)
- name: "accountBalance"
width: 80
formatter
- name: "fullName" # - Example composite property formatter
$type: compositeColumn
format: "$firstName $lastName"
expandRatio: 2.0
- name: "mgnl:status"
preview:
$type: imagePreview
propertyName: photo
fields:
- name: "mgnl:name"
readOnly: true
- name: "gender" # Property would be String in contentType definition; override otherwise-inferred field type
$type: selectField
options:
- "female"
- "male"
- name: "firstName"
- name: "lastName"
- name: "email"
validators: [ $type: emailValidator ]
formLayout:
$type: myBusinessCardLayout
#actions: # optional
#actionLayout: # superseding actionbar