- What do you expect
- What have you seen done wrong
- What are your key pains
- Are you addressing this already?
Moderator: Christopher Zimmermann
Questions from the group:
What is actually missing in Magnolia right now? Can't you do this already?
- Primary goal is to make content app creation fast and easy.
- Yes - You can create content apps, but the content modelling is implicit in the content app, it is buried, it is hard to understand the content model of a project. For example, there are many apps - but only some of them surface content types.
- Another problem currently is that the data-model and the presentation of the data forms are tightly woven. Its easy for someone to "break the data" when they are just trying to improve the appearance of the entry form.
Doesnt JCR node-types do this already? JCR loosely structured.
- JCR does have node types... but we want something on a higher level because a content-type will be able to represent external content too - not just JCR content.
We need to continue to support custom vaadin fields. (A: And we will.)
The main thing we need is simplified app definitions. Get rid of the boilerplate.
Would be nice to control the indexes on the workspace from the content-type.
Type should be declaritive not programatic
- Something like: "This field is available on monday, but not on tuesday". Could result in inconsistant data.
- Consider migrations. how could they handle dynamic/programmatic types?
Feature: It would be nice to have very fine grained control over who can edit what
- For example on the field level. On a teaser - enforce that some users can edit only the target of the link, not the description text.
- Another use case: translaters cannot edit all fields. To solve this now they have to create another edit subapp that does not show all fields. So they have to create a custom action to open that subapp!
- Typical: Master user can edit all - then categoreis of user that can only edit some things. (certain languges, etc)
Make sure all the standard validation is available for the fields.
Make sure all fine level app configuration can still be overlayed on a provisioned app.
Dialog definition already works well. Do we need something new? Could still use dialog? (A: current verbose app definition will continue to be supported. Also, using the dialog definition is being considered as an option to define a content type.)
- What about meta-data on a dialog for these additional high level features.
You can have more reflection or understanding of the type of each field. (If we go with strict fields vs Vaadin fields.)
Question to the audience: Who is defining the content types on a project:
- Mostly feel it is developers. A few saw it as a need for business users.
Suggestions about how to define the type.
- XML schema definition
- Would provide tooling in IDEs.
- Have we looked at JSON-schema?
- Using groovy generator.
- Dialog definition
Very rough example of what a content type definition could look like:
- type: text
- required: true
- type: relationship
- content-type: categories
- path: /tour-types
- type: int
- type: option
- omnivore: o
- herbivore: h
- vegan: v
- widget: dropdown