On Wed, Apr 8, 2009 at 11:24 AM, Tobias Bocanegra <tri...@day.com> wrote: > On Wed, Apr 8, 2009 at 11:05 AM, Jukka Zitting <jukka.zitt...@gmail.com> > wrote: >> Hi, >> >> On Wed, Apr 8, 2009 at 10:53 AM, Tobias Bocanegra >> <tobias.bocane...@day.com> wrote: >>> i would like to drop the builtin .xml file and read the builtin node types >>> only from the .cnd file and additionally add support for a >>> "custom_nodetypes.cnd". >>> this will make the node types file much more readable and offers users a >>> simpler >>> way of providing their node types. >> >> I'm a bit afraid that making the file more readable will just >> encourage more people to modify it directly. :-( > well, but that's security by obscurity :-) but it certainly helps the > developers. furthermore, all the node types in jsr283 are now speced > in CND, and converting them to XML is a pain and error prone. > >> Instead, couldn't we store the node type information as actual nodes >> in the same persistence manager we currently use for versioning >> information? This way we could get rid of the current virtual item >> states we use for exposing the node types under /jcr:system. Storing >> the type information as content would also simplify clustering, >> backups, etc. > hmm, i think you're talking about something else :-). storing the > registered (builtin and custom) nodetypes in the persistence manager > (instead of the custom.xml) would certainly be a big advantage. the > 'versioning' workspace should then be the general "rep:system" shared > tree. > > i was talking about installing the initial set of nodetypes, like: > nt:base :-) those are currently stored as resource in > builtin_nodetypes.xml, and i would like to replace it with the > (already present) .cnd aequivalent.
+1 WRT custom_nodetypes.cnd: -0, i do share jukka's concerns. with hindsight i consider it a mistake storing the registered custom node type definitions in a human readable format ;) cheers stefan > > regards, toby >
