[Hippo-cms7-user] Relaxing CND's
Frank van Lankvelt
f.vanlankvelt at onehippo.com
Fri May 14 11:30:49 CEST 2010
as Ard mentioned, refreshing! I think that the prospect of easier updates
is certainly worth discussing this option. As Ard found by experiment, the
CMS editor already has a type indirection layer. And the HST has one by
means of the content beans. With content beans that are able to deal with
both old and new formats, it might even be possible to achieve this in a
A number of questions with regards to "how loose" we should go:
1) do we want to keep namespaces for projects?
2) if we do want to keep namespaces per project, do we hang on to
different document types in this namespace; each weakly structured?
Perhaps we should really introduce the concept "project" instead of
overloading the JCR namespace concept. I don't think it makes a lot of
sense to hold on to document types that directly correspond to node types
when all those node types will be identical.
We then do need to store this type info in the document itself, so there
will be "hippo:documenttype", "hippo:project" and (non-mandatory)
"hippo:projectversion" properties. This is necessary to be able to perform
content bean mapping, open the correct document editor and e.g. for
For metadata such as facets, tags, related documents, classification, I
think that these should remain strongly typed. These types are reused
across multiple projects, are likely to get stronger support in the CMS and
will likely be used by other, project-agnostic, tools. (perhaps a number of
"standard" properties (dublin core?) can also be made available in the same
Compound types should also be part of the picture. Since we're leaving
exact typing of compounds, I think there should be an "abstract" base type
hippo:compound. Then, the base document node type can have a "+ *
(hippo:compound) multiple" CND definition; this would catch the erroneous
placement of a handle or a document under a document. (the folder type can
extend the base definition and allow this, of course) A final addition to
consider is the "+ * (hippo:facetselect)". The facetselect type cannot
extend the hippo:compound type, but it can very well be added to document
and compound type definitions.
There are a few thorny issues that still warrant an "update-all-content"
step. It should be considerably less dangerous though, since node types no
longer need to be changed. Consider renaming a property (field path),
removing it completely, changing its type, making it multi-valued, making it
required, etcetera. These changes no longer require a type change, but do
need an update of existing content. To be able to show old revisions in the
CMS, we do need to retain some kind of versioning information on the
documents and document types.
What is important to realise is that by throwing away the JCR types, we'll
no longer have the JackRabbit checks. So if you misspell "title" for
"titel" in the importer, for instance, you will only find out when actually
viewing or editing the document. This might be mitigated by doing
asynchronous checks/fixups or by reusing the same beans that are used in the
site (importer) or the type definitions used by the cms editor. The data
will be more messy. Site developers should realise that the burden shifts
from creating upgrade modules to creating backwards-compatible content
Note that there will still be a need for content upgrade modules, to be able
to make complex changes. (moving properties in the hierarchy,
canonicalizing their values, splitting a property, merging them, etcetera)
Since these are likely to be a) rare and b) hard to achieve with backwards
compatible beans, these will need to be done offline.
All in all, I think this is a step forward. Content upgrades are more
expensive than they would be with weakly-typed documents. It will require
(quite) some work to adapt the CMS, but I think it is manageable.
PS: really, the term "template" doesn't make sense in a CMS. Terms like
"type", "editor", "prototype" and "instance" do. The problem remains what
to call the "type editor" + "editor builder" + "prototype editor".
On Tue, May 11, 2010 at 6:27 PM, Arje Cahn <a.cahn at onehippo.com> wrote:
> Hi all,
> Here's something that came up today. Or actually it's something that I
> heard from different people, at different occasions, but no-one really
> cared to write it down. So here I am shooting from the hip with
> something that I think is inside a lot of people's heads already. I'd
> really appreciate it if you could share your thoughts on this idea if
> you have any.
> Hippo CMS 7 offers a built-in document type editor. This UI component
> is sometimes confusingly referred to as being the "backend template
> editor" or simply the "template editor". And that confusion kind of
> says it all: what is it really? A template editor? A document type
> editor? A data modeling tool? A form creator? For the sake of my
> argument, I'll stick to the term "Editor" in what follows next, but
> I'm really talking about what is currently the document type editor
> The answer to the question is: kind of all of the above.
> When you create a new document type using the Editor, it creates a
> number of configuration files in Hippo Repository: the node type
> definition (a CND), a template definition, and a prototype. Every time
> something is changed using the Editor, these files get updated, after
> which you have to hit the big "update-all-content" button to enforce
> the updated CND onto all matching documents in the repository. In
> theory, you wouldn't need to update all content after every change,
> but this is how the current implementation works. I can think of
> heuristics to improve the mechanism, but that's not the point of my
> The point of this email is that I want to:
> 1) agree on a best practice that we should relax the strictness of
> document types, so their behavior comes closer to the way Content
> Blocks work 
> 2) change the Editor in such a way that a change made in the Editor no
> longer results in a change in the CND
> 3) as a result, eliminate the need to do an update-all-content when
> changing templates using the Editor
> 4) and while we're there, simplify the export/import process when
> moving content from one environment to another
> To make this possible, we need to take out the data modeling part of
> the Editor (the part that makes it the "document type editor"), and
> stick to it being just a "Template Editor". Instead of generating a
> CND, it should interpret a CND and allow the user to create a Template
> for it.
> Also, we should agree on a best practice on where the strictness in
> CND's should really be. It could save everyone a lot of trouble when
> sticking to more loosely defined CND's. They allow for more
> flexibility within the Editor and they allow changes to Templates
> without the need to update all content.
> Since Hippo CMS and the workflow expect certain parts of the nodetype
> to always be validated and available (like a lastmodifieddate
> property, a state property, etc), we'd need an envelope type that
> describes the metadata that really has to be there in a strongly typed
> fashion. But what goes *into* the envelope is entirely up to the
> *template* definition and the person that creates it. There's no need
> for that part to be so strongly typed. Lets separate what goes into a
> document (loosely-typed content) from what describes the document
> (strongly-typed metadata).
> A CND could have a definition that says: 'any object of type Document
> can contain 0-n String properties, with whatever name and in whatever
> order'. The template editor interprets this CND and will filter for
> all plugins that are capable of generating Strings. The user can then
> start creating a template by adding an Inputbox, a Textarea field,
> maybe another Textarea, a Password field, order them a bit and so on.
> Even though there are now 4 fields in the template, the CND hasn't
> changed. And when a new String-returning field is added to the
> template, even after 1.000.000 documents have been created with it, it
> would be a real breeze as it doesn't have to touch any of the existing
> documents. If we extend the content CND by also allowing Dates, Longs,
> Doubles, resources and hippostd:html elements, then we can recreate
> pretty much any template we currently have all with the same CND
> definition. No more content updates. I guess. But I'm not sure, so
> help me out here :)
> Note that this still allows a developer to go in and create a Very
> Strict CND when needed. For which they'd need to define an upgrade
> script to do an update-all-content after a change to their CND. But
> those are corner-cases (agreed?). I want to take out the pain for
> those 99% of the cases where people don't really need a strict CND for
> content, but just want to build a Template using the Editor.
> Of course there's drawbacks - it can be very handy to work with
> strongly typed data. From a JCR point of view, it could make sense.
> But since 99% of people on this list is actually using HST content
> beans with their own mappings to do content rendering, none of that
> strictly-typedness is actually put to good use. And for those cases
> where an external system is writing data to Hippo Repository that must
> be validated according to a strict CND - that's still possible (see
> above). You just can't create that strict CND using the Editor
> Any thoughts on this? Technical problems? Backwards compatibility?
> Would it take out the pain of the update-all-content cycle for you? Do
> you think it's even possible?
> Thanks for reading and sharing,
>  Document Type Editor:
>  "Content Blocks plugin provides the content/document editors an
> ability to add multiple pre-configured compound type blocks to a
> document." http://content-blocks.forge.onehippo.org/index.html
> Hippo-cms7-user mailing list and forums
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hippo-cms7-user