[Hippo-cms7-user] Relaxing CND's

Jeroen Reijn j.reijn at onehippo.com
Tue May 18 09:53:04 CEST 2010

On Tue, May 11, 2010 at 6:27 PM, Arje Cahn <a.cahn at onehippo.com> wrote:
> 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

Good points! This sounds like a great improvement! My personal frustration
has always been that the templates where to much tightly coupled to the

> 3) as a result, eliminate the need to do an update-all-content when
> changing templates using the Editor

This will probably work for most cases that you want to tackle (like
adding/removing/updating existing base hippo field types like
String,Long,Rich Text), but I can think of a case where you might want to
add a plugin to an existing project that contains it's own nodetype
definitions. You then still have to change your namespace (even if it's
setup in quite a loose manner). But using the changes most of the time
happen with the default types. I guess this will cover 90% of the cases
where you want to change your templates.

> 4) and while we're there, simplify the export/import process when
> moving content from one environment to another
Yes this will become a lot easier.

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

I'm all for it!

> 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).
I fully agree with you on this part. I think you can't do without the
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 :)
I think this sounds exactly how it should work and with my knowledge of the
system this sounds quite feasible to me, but I guess one of the core devs
can probably have a better insight on this.

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

Yes I think you hit the nail on the head here. I think that giving the
responsibility to the developer here can save a lot of people a lot of time.
This way you can choose if you really need it. You will then know what the
consequences are when you go for the strict or loose approach.

> 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?

Yes it can take out a lot of pain as far as I can see. Especially on the CMS
side. The upgrade process now seems to be complex and to sensitive for
errors. Having a loose cnd can change this for most people.

> Thanks for reading and sharing,
Thank *you* for putting your thoughts into this email and writing it all
down. I think this is a great step forward!

> Arje
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onehippo.org/pipermail/hippo-cms7-user/attachments/20100518/b098f3ea/attachment.htm>

More information about the Hippo-cms7-user mailing list