Page History

...

...

Requirements

There's general consensus about the following:

[Magnolia needs] a formal definition for a type of content [...] including the fields that type may contain, and its relationships to other types of content.
Based on this definition, other things can be created with little or no work such as a content app, an editing dialog, and REST endpoints.

—via Content Types

...

Initial action plan / Spike 0

Based on a registry on one hand, and starting off with a field-based model on the other hand, we could start implementing a minimal user story with few concrete actions.

Status

PRs were created, yet they're not deemed to be in a "productized" state atm. Still a bit too reminiscent of the previous PoC efforts.

1. Configuration

Registry

At this stage, the format does not matter as much as what we're going to do with it.
It's also unclear why our YAML format should be considered a misfit—we've been pushing it all around the place—or for what use cases it falls short, concretely.

...

Should we hit the wall with the registry or format, and get an alternative on par with benefits above, nothing is set in stone. It just allows us to move on with downstream technical challenges.

Status

CT01.

...

Pick ContentTypeRegistry + ContentTypeDefinition into a new module

• Module will sit above core & config, but below UI
• Move registry <-> config-source bindings to the new module class
• tentatively YAML-only to start with

Definition outlook

—what does a content-type consist of?

This is also a never-ending topic. We should start small, and add more aspects/features as we go.
In fact, there is potential for many existing Magnolia features to shift under the umbrella of content types, eventually.As per the high-level vision at the top of this page, the most prominent part of a content-type is its model, its form, its fields.

The model debate

As foreseen, content-types are shifting upstream of apps, that is upstream of any UI/UX consideration.

On the one hand, modeling purists advocate for a strict, dry representation of the model, with almost exclusively primitive property types.
On the other hand, Magnolia has always provided users with pretty loose modeling, driven by field-definitions. The author experience comes first, the data model is deduced from it.

There may be some middle-ground there. With few key improvements, we can keep our familiar field-definitions, while decoupling them from UI/UX considerations.

Again, nothing set in stone. This in turn helps progressing towards generation of content apps and endpointsIn fact, there is potential for many existing Magnolia features to shift under the umbrella of content types, eventually.

Content type all-the-things :allthethings:

Just for reference, here's a non-exhaustive list of many more aspects a content type could specify:

• data source (envisioning an evolution of content-connectors, without the Vaadin bits)
  • kind
  • coordinates
  • workspace / table / collection name
  • node types
• model / fields
  • relationships, 1-to-1, 1-to-many, etc.
  • evolution, content version-handling
• locales
  
  • see

    Jira
    server Magnolia - Issue tracker columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 500b06a6-e204-3125-b989-2d75b973d05f key MGNLUI-3616

• folder-support
• tagging
• versioning
• publication
• personalization
• renditions / URI bindings / previews
• cache policies
• naming / id strategy
• ownership model / security
• consistency model
  • all consistent against latest schema (hence content migration)
  • vs. mixed-model version w/ compatibility
• ..

Action plan proposal

Based on a registry on one hand, and starting off with a form on the other hand, we can start implementing a minimal user story with a set of concrete actions.
Again, this is non-exhaustive, and we may well add more as we uncover potential roadblocks along the way.

Registration & config

• .

2. Fields

Modeling

As foreseen, content-types are shifting upstream of apps, that is upstream of any UI/UX consideration.

On the one hand, modeling purists advocate for a strict, dry representation of the model, with almost exclusively primitive property types.
On the other hand, Magnolia has always provided users with pretty loose modeling, driven by field-definitions. The author experience comes first, the data model is deduced from it.

There may be some middle-ground there. With few key improvements, we can keep our familiar field-definitions, while decoupling them from UI/UX considerations.

Again, nothing set in stone. This in turn helps progressing towards generation of content apps and endpoints.

Status

We start simple, with a plain map of named fields. We make FieldDefinitions less UI/UX-bound / more UI-agnostic.

CT12. Infer field-types vs. types both waysCT01. Pick ContentTypeRegistry + ContentTypeDefinition into a new module 

• Module will sit above core & config, but below UI
• Move registry <-> config-source bindings to the new module class
• tentatively YAML-only to start with

Making FormDefinitions less UI/UX-bound

CT11. Make Form a flat list of Fields

• ditch TabDefinitions in favor of an optional layout config

CT12. Infer field-types vs. types both ways

• setting "fieldType": FieldDefinition impls have hard-coded types (already)
• setting "type": infer a simple field type upon form creation (dialog, app)

CT13. Detach Validators from Vaadin

• boilerplate: must implement:
  • Vaadin Validator
  • Magnolia ValidatorFactory
  • Magnolia ValidatorDefinition
• switch towards standard Bean Validation standard Bean Validation (well supported by Vaadin too)
• provide config short-hands for standard bean validators (max-length, range, etc.)
  • validator-registry?

...

Under the radar (unranked)

• Support semi-structured content types (leveraging the content-editor)
• Defining & resolving references to other content-types (leaving linking out first)
• Groups of fields and/or 1:n relationships

UI bits

In addition to making fields more UI-agnostic, we seek to maintain presentation flexibility on app & form level.

Under the radar

CT11. Once CT gives us a flat list of fields, layout can be configured on app level

• ditch TabDefinitions in favor of an optional layout config

3. Data source

CT21. Reuse automatic workspace creation creation

CT22. Connect an existing app or sub-app descriptor to a ContentTypeDefinition

• experimented in Sang's PoC, via plain plain contentType reference id reference id

Status

To be discussed / defined.

4. Content apps

App generation

We seem to have consensus against re-introducing definition builders maintained by hand (like those we reverted before 5.0)

• A. Either verbosely build/nest configured definitions w/ plain constructors (no new def code)
• B. And/or we give a shot at leveraging Sasha's code-generation efforts for this

Status

CT23. Generate apps on-the-fly, upon AppController#start app startup

• AppDescriptorRegistry listens/delegates fluently to the ContentTypeRegistry
• broadly speaking, CTR is a source for apps
• resolve a placeholder DefinitionMetadata
• use a dynamic DefinitionProvider building the app on-the-fly from the type

Options under the radar

• Support a new, less-boilerplate app descriptor type, conveying higher-level semantics, leveraging content-types
• Definition-less app on the fly; dynamically built based on CT definition features.
• Either way, both would cause major changes to app sub-components (e.g. workbench, actions, all presenters heavily relying on defs atm; views hardly usable standalone)

App defaults

• yet to formalize config patterns, actions, columns, labelling...
• crud, publishing, import-export
• different stock apps have different flavors of actionbar section availability
• even the groovy generator is not fully "canonical", vs. M5 UX guidelines

Status

To be formalized.

Under the radar

• Composing mixin configuration defaults per content-types capabilities

5. Consuming content

REST endpoint defaults

Status

We have a productized, JCR-based, basic delivery endpoint. Currently this is just one "global" endpoint, taking the workspace name as path parameter.
Therefore at the moment, there's no such thing as one endpoint per content type (might come again later), so nothing extra to register.

...

TODO

•  Create JIRA tickets for these

Options under the radar

• Side-by-side endpoint implementations for CT-based vs. JCR-based.
• Single endpoint registrations (more content-semantic APIs than with the generic one)