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
- e.g. module: magnolia-content-types
- ~ 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.
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
- from a Java developer's perspective
- 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
- What *we* consider MVP
- Cedric
- bindings from content-types to editors
- standard vs. overrides
- Friday afternoon