Product Development

Page tree
Skip to end of metadata
  • Created on 2017-07-26, last edited by Mikaël Geljić on 2017-07-27
Go to start of metadata

As part of the ongoing concept effort re: content types, we sought alignment, common understanding on the very basics, in order to gain confidence to move forward.


 

DEV-617 - Getting issue details... STATUS

Attendees

Outcome

We made significant progress on the mutual understanding, terminology and some of the foreseen concepts.
We could "co-sign" few statements—see the checked items and those in bold below.

Next we aim at getting more concrete with both the ContentTypeDefinition skeleton itself, as well as with Java APIs supporting data-sources.


Discussion log

Intro, expectations

  • Mika: seek common understanding, figure out disagreement points (convinced we're not fully on the wrong path)
  • Philip: What is a content-type, terminology, where it fits
  • Cedric: High-level common understanding
  • Federico: +1
  • Sasha: enrich the understanding
    • fundamental contracts of CTs; how we're gonna fulfill those

✓ Problem we're trying to solve:

  • Boilerplate to define your "domain" into the CMS
    • partially decoupled from the data-source (TODO: define which parts in common, which parts not)
    • decoupled from the consumers (UI framework, REST)

Vision

  • Push or ✓ Pull
    • e.g. module: magnolia-content-types
      • above core, config
      • below ui, rest
      • at first seemingly more independent from i18n, p13n, tags
  • ~ CT is an abstraction layer of data-binding, representation, custom data-models...
  • ✓ Envisioning to bridge most CMS functionality onto CTs

Terminology

A content type is the definition of a domain entity in Magnolia.
—We refer to content types, especially over entities, types, mainly for disambiguation purposes.

An instance is an individual piece of content, created or fetched from the content type.

A content type defines its model, which consists of properties.
—We ruled out reusing fields for that.

A content type also has attributes.
These can be metadata, that is informative content describing the content type;
or they can features, that is intrinsic characteristics of that content type, specifying or inducing a certain behavior.

 Click here to expand...

Content ~ Data
Types ~ Definition ~ Model

  • ✓ "Content Types"
    • has a name (e.g. cars)
    • is the effort name, project name, module name, the broad feature
    • ~ ContentTypeDefinition
    • // info.magnolia.types
    • synonyms: entity, ~ types
  • Instance, entry, item, object, (tuple, db row)
    • (a car)
    • an instance of a Content Type
    • Content Type entry
    • might depend upon ds
  • Content type has a Model
    • The model has Properties, fields, attributes
      • A content type defines properties
      • A content type instance has properties *with values*
      • is it only about "properties"? properties vs. child-nodes in JCR
        • TODO: define sugar to define rels in-place, or within same domain/realm
        • see # sub-models section below
      • data-bindings
  • Content types have Attributes
    • [attribute]: a quality or feature regarded as a characteristic or inherent part of someone or something.
    • metadata
      • name
      • description
      • inceptionDate
      • author
    • features (characteristic, aspects, attributes* (static), metadata, facets, mixins, traits)
      • datasource (a CT features a DS)
      • ~ i18n
      • full CRUD
      • batch-operations (deletion)
      • ~ p13n
      • ~ tags
      • ~ publicationStrategy > workflow
      • identifierStrategy
    • ~~ app // rest // template provisioning may not be regarded as features
      • pull contradiction?

Non-debated

  • Representations
    • previews
    • editors
  • Relationships, references


Root concerns

  • DataSource vs. ContentType?? chicken vs. egg
  • Two different CTs vs. same DS / WS
    • configuring same WS, same rootNode but different NTs
    • configuring same WS, different rootName, same NTs
  • One DS hosting two CTs in parallel or within common hierarchy (folder)
  • TODO: PM/Research how competitors address it?
  • ✓ A ContentType(Definition) is the root / entry-point to its "attributes", primarily to its data-source.

Sub-models

—aka compound types, groups
Inline/anonymous Content Types?
How do we store or edit those sub-CTs?

If those sub-models can be reused from different CTs, then where does it belong?

  • e.g. Person / address: Address


/ 
 - Mika [mgnl:developer] 
     - firstName: Mikaël 
     - lastName: Geljić 
     - dateOfBirth: ****-**-** 
     - billingAddress [mgnl:address] 
          - street: Rue ******** ****** 
          - number: **
          - zipCode: 68220 
          - city: Hésingue 
     - shippingAddress [mgnl:address]

If sub-models can be queried standalone, then they should be CTs
If they have no reason to be standalone, then it's down to the data-source to support sub-models (RDB would be ruled out)
Defended alternative to support just 1 level, and prefix property names

Sub-models would help supporting views/zoom-levels a bit more easily (vs. full-flat list)

ModelDefinition +/- model traits (e.g. nesting)

  • renderers/editors for sub-models anyone?

Assets

  • which metadata scheme

AssetMetaData type

  • name
  • set of properties

External types (referencing content)

  • Support for external content types?
    • Do we envision that 3rd-party/external types would be integrated via a ContentTypeDef as well?
  • vs. Content types just for these *managed* by Magnolia
  • or ExternalContentTypes as a subset of ContentTypes
    • only "views", "datasource", and ID resolution? / referenceable?
    • not supported: taggable, CRUD, etc.

Other connections and ideas

Config APIs usage (registry):
  • Philip: no means to restrict changing content-types (re: migration later)
    • content type def would be volatile
    • inter-registry dependencies
    • startup sequence, creation of workspaces vs. population of registries
  • Sasha
    • We can restrict config sources maybe
  • Regarding as implementation detail?
How does the app/actionbar react
  • to multi-selection
  • to hybrid selection
  • Ask PM/Anja to revisit the action bar
  • (help ourselves with i18n pluralization & specialization)
    • combined w/ better control of visible vs. enabled actions/groups/sections
Other
  • Minimalistic different kind of descriptor, explicit app (yet minimal, fully-backed by CT)
  • Versioning the content-type vs. versioning the model
  • Defining primary keys
  • Domain, ns, ws
  • Sys-props (jcr:, mgnl:)
  • Model
    • Strict consistency vs. loose, other models?
  • Inheritance of CTs
    • Leave it out for now
  • Relations
  • Identity
  • Fiddle-able at runtime vs. only at build-time
  • Validate against dam?
    • or get cues from there
  • Where semi-structured fits
    • Data-source driven?
    • Should not be a CT?
    • Raw text blocks + other content types
    • Should custom block types map to content-types


What next?

  • Sasha:
    • from a Java developer's perspective
      • in what form the data-source gives the instance?
      • how implementor binds the data
    • benefitting from Java 8 goodies
      • and Vaadin 8 goodies
  • Mika: CT Definition skeleton
    • datasource
    • model - fieldType?
  • Philip
    • What *we* consider MVP
      • vs. things we can afford to do later (e.g. customize apps)
    • Address content migration early
      • or e.g. lock until updates supported
  • Cedric
    • bindings from content-types to editors
    • standard vs. overrides
  • Friday afternoon


  • No labels