Page tree
Skip to end of metadata
Go to start of metadata

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
  • $type is an alternative to the class setup, virtually anywhere in the definition object tree.
  • $type resolution would be backed by one, low-level TypeResolver, not a config Registry.
    • building upon TypeResolver pluggability that was created first for fieldType aliases.
  • TypeResolver provides implementations, whereas a config Registry collects 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

Flavor A, suppa-generic
@ConfiguredType("emailValidator")
class EmailValidatorDefinition implements ValidatorDefinition
Flavor B, generic and specialized
/* @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 FieldDefinition and FieldFactory?
    • i.e. put #factoryClass on FieldDefinition, same as #implementationClass on various components 
  • Then how do we customize all text fields?
    • or decorate richTextField from DAM to add image support
    • would have to make all FieldDefs interfaces w/ default Configured* impl
    • then let consumer override type-mapping in XML
      • or ideally/later also declare type-mappings via annotations

Further app descriptor flattening exercise

cars.yaml
$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



  • No labels