[Hippo-cms7-user] Relaxing CND's

Arje Cahn a.cahn at onehippo.com
Tue May 11 18:27:17 CEST 2010


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
[1].

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
email.

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]
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
anymore.

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,

Arje

[1] Document Type Editor:
http://www.onehippo.org/cms7/documentation/user/information_architects/howto/create_documenttype.html
[2] "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



More information about the Hippo-cms7-user mailing list