[Hippo-cms7-user] Relaxing CND's

Arje Cahn a.cahn at onehippo.com
Fri May 28 15:25:24 CEST 2010

Hey all,

Thanks to everyone who responded to my original mail. Looks like
everybody agrees in a way :).
As discussed with Stephan, we're freeing up time in the upcoming
months to start Relaxing our CND's. I'd encourage further discussion
to continue on this thread, mainly since I don't know what has to be
done to get it to work. And I think it's worthwhile to see what other
people on the mailinglist have to say.

Looking good!


On Tue, May 18, 2010 at 2:26 PM, Frank van Lankvelt
<f.vanlankvelt at onehippo.com> wrote:
>> > 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.
>> I don't think this is actually needed. If we have by convention an
>> abstract nodetype which is meant as 'extendable' marker nodetype for
>> subnode structures, this is not needed. Within one namespace (we might
>> have the abstract node type ofcourse in hippostd/hippo namespace, but
>> just for the idea), suppose you have:
> it must be in the hippo namespace.  Otherwise each node type with a plugin needs to be a mixin.  And then in each project you have to create a primary type that extends the abstract-type and mixes in the mixin.  It's much easier to have the abstract type in the hippo namespace.
> The reason for the abstract type in the first place was that I don't want to have "+ * (nt:base)" in a node type.  I think that that's going too far with the loose typing, since you're no longer using any checks.
> cheers, Frank
>> [myproject:abstractsubnode] > nt:base
>> - * (string)
>> - * (boolean)
>> - * (long)
>> - * (double)
>> + * (myproject:abstractsubnode)
>> [myproject:basedocument] > hippostdpubwf:document,
>> hippostd:publishableSummary, hippo:document
>> - * (string)
>> - * (boolean)
>> - * (long)
>> - * (double)
>> + * (myproject:abstractsubnode)
>> [myproject:newsdocument] > myproject:basedocument
>> [myproject:agendadocument] > myproject:basedocument
>> Now, with a setup like this, you can account for *any* future plugin
>> that needs it own nodetype: just extend the nodetype from
>> myproject:abstractsubnode: then you are allowed to add it. Are you
>> adding the *new* plugin to a repository containing 10.000.000
>> documents and you don't want an update of the existing data. Fine,
>> just add:
>> [mynewpluginnamespace:mynewplugin] > myproject:abstractsubnode
>> Then, after the new cnd is imported, you can add
>> mynewpluginnamespace:mynewplugin to existing documents.
>> Now, also note I do not try to claim you'll never ever need an update
>> all content anymore: when moving from say ecm 2.12 --> 2.15, you very
>> well might need some content iteration. However, upgrading, or say
>> content restructuring, justifies imo an update all content, whereas
>> extending an existing model with some field or, in your example
>> plugin, should be possible without update all content
>> Ard
>> >
>> >>
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html

More information about the Hippo-cms7-user mailing list