[Hippo-cms7-user] Relaxing CND's

Ard Schrijvers a.schrijvers at onehippo.com
Tue May 11 20:42:14 CEST 2010


Hello,

first of all, I really like this reasoning: It is completely
complementary with the current HST content beans design *and*, as far
as I can judge, the current editor design. It seems to me backwards
compatible (how do I know: because I just tested it: changed strict
cnd's from hst demosite to loosely defined one (any string and boolean
allowed), and fired up the cms. I added a field in the BE template
through the console, et voila, the cms kept working, a logged in
editor instantly saw the extra field in the template without update
content/cnd, and the HST can use this new property without restart:
Beautiful I would say.)

I think, a proper convention, which is now already automatically done
by the BE templates, is that if you allow every for example String,
that the property name at least has the namespace of your own project.
For example myproject:title. This is already how the BE template
works, so no work here.

See further comments in line

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

Export/import does not involve any cnd stuff anymore, so not longer
multiple namespace version numbers: this makes it much easier! Also
think about versioning: within the same namespace, this is much easier
I suppose then supporting versioning over multiple namespace for one
document

<snip/>

> 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 :)

This is correct, and as a matter of fact, as explained above, I have
this scenario working with the HST demo cms and site: it is a very
nice match to how it already worked, only, give the cnd responsibilty
back to the developer, and let the BE template editor define the view
on the content model: also note, that of course, the HST archetype
will create a site setup for you, that has a loosely defined cnd
out-of-the-box, where you can do all what you would like with the
template editor, only this time without the need of update all
content. I think this is a major leap forward: just by moving some of
the responsibilities, it seems to me a lot of pieces nicely fall into
their place, and perhaps not a coincident, I think lots of code gets
much easier at the same time: the BE editor does not need to create
the content model at the same time. This removes a hard piece of code

<snip/>

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

This is the only part in your long mail I think I do not agree with
you: the very strongly typed data imo matches relational databases
really well, *but* JCR is designed to be very flexible in what you
store, and does not encourage you to use strongly typed data: The jr
community even encourages nt:unstructured when you just start, which,
imo is certainly a bridge to far: I really like our strong Document
model, certainly with our indexing extensions and virtual layers (and
the upcoming Lucene bleeding edge developments wrt incremental updates
and NestedDocumentsQueries will boost it even futher). Relaxing the
cnd for these Documents, what you describe, is imo absolutely the way
to go!

</snip>

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

Well, certainly since I already tested your reasoning as pointed out
at the beginning of the mail, I am confident this is a major
improvement, which fits current work really well, and I don't see
reasons why this wouldn't be backwards compatible, though, I must
admit I cannot judge all areas: For the HST at least, there are no
issues as far as i can see.

>
> Thanks for reading and sharing,

Thanks for the enlightening reasoning. I think this would make many
developers happy

Ard

>
> 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
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html
>



More information about the Hippo-cms7-user mailing list