> If you need the ability to rename, you should "define" tags in a > separate location, eg. under /tags. Then you would have a my:Tag node > type that includes a title (and maybe a description) using jcr:title > and jcr:description
That's what I thought > (standard property names for this purpose, will be > included as mix:title mixin in JCR 2.0) for the tags. Why "mix:title"? > A tag would then > be identified by the node path /tags/flower (or just "flower" if the > /tags prefix is fixed and known) and now content can be tagged by > having a multivalue tags property that includes those paths So would advice against using the UUIDs in the multivalue field? But that is awkward. You will end up with tags like this /tags/oldname/my:title = 'newname' That's confusing more than it helps. While we are on that: As JCR quite a bit like filesystem - are there native ways of doing a "symbolic link"? And if so - how does that work with versioned resources? Example: /images/image1.jpg /articles/article1/images/image1.jpg -> /images/image1.jpg /articles/article2/images/image1.jpg -> /images/image1.jpg or with versioning /images/image1.jpg (versions 1, 2) /articles/article1/images/image1.jpg -> /images/image1.jpg (version 1) /articles/article2/images/image1.jpg -> /images/image1.jpg (version 2) /articles/article3/images/image1.jpg -> /images/image1.jpg (latest) > (using > reference properties here could be a little performance issue and are > not very readable when exploring the content, see David's model, rule > 5). But how do you deal with referential integrity here? I remove a tag from the "tags" node and suddenly the references are dangling. (Ah ... you cover that below) > This requires an extra step when displaying content to retrieve > the actual title of a tag, but that is not a big problem, since the > tags, which are effectively nodes then, would be managed by > jackrabbit's internal node cache for free - and if the number of them > is limited (say a few 10000 tags), this should work out fast. Yeah > Renaming a tag is simple then, simply change the title property of > your tag. Removing tags and other operations can be either done > through observation or in a lazy-way. With observation, ie. modify all > tags properties in the content when you delete a tag, you have the > problem that there might be a lot of write operations at once. Since > you have that extra step during display of content anyway, you could > also do it the lazy way and don't display tags that are not under > /tags anymore. Removing tags can also be lazy, ie. on the next write > operation on the content node, again using observation. Hm ... that's a lot of manual work :-/ I think I prefer the lazy show of tags and them prune on the next write maybe. So the "weak reference" model. But lack of repository based referential integrity assurance is quite a turn off. I have "referential integrity" on the feature list on some presentation slides. Right now I just can't follow why/how. >> 1. Is "mix:versionable" of recursive nature? When this is set on the >> document node will all the descending-or-self nodes be versioned? Or >> is this per node? > > There is a separate setting called "OnParentVersion" for node types > that specifies what happens with a node when its parent is versioned. > Have a look at section 8.2.11 "OnParentVersion Attribute" of the JCR > 1.0 specification [2]. Ah - thanks! >> 2. Why would you want to use "jcr:data" vs "my:body"? That just a >> convention for e.g. the explorer or webdav servlets? Where could I >> find information about these standard attributes? Are they defined in >> the spec? > > With a JCR, you should always try to standardize your property names > and/or nodetypes. This gives you maximum reuse. The generic (simple) > WebDAV servlet is only one integration that works with nt:file and > nt:folder - others are possible. Have a look at rule 6 of David's > model [3]. Thanks, for the links!! cheers -- Torsten
