jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Custom node or mixin added to existing node
Date Fri, 09 Oct 2009 14:05:28 GMT
On Fri, Oct 9, 2009 at 15:38, Michael Shoener <mshoener@softwareapps.net> wrote:
> Ok. I'll give an example of my query. In this example the "hfs:fileInfo" is
> a mixin that was added to the "jcr:content" node (which is an nt:resource
> node type).
>
>        //element(*,hfs:fileInfo)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
>
>        The above for some reason does not check the actual contents of the
> file, it only checks my custom property @hfs:description.

First of all, leave out the last location step "/(@hfs:description)" -
it doesn't make a difference.

Secondly, the //element(*,hfs:fileInfo) step will select the
jcr:content node, hence the jcr:contains in the constraint part
([...]) will look for yet another subnode jcr:content. You should
change it to ".":

//element(*,hfs:fileInfo)[jcr:contains(., 'testing') or
jcr:contains(@hfs:description, 'testing')]

> Then I tried querying the "nt:resource" nodes like below, but it then does
> not return my custom mixin property values (I believe it gave me an error
> when trying to retrieve the custom properties defined because it only
> returned "nt:resource" node types).
>
>        //element(*,nt:resource)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)

Same issue with jcr:contains as above plus this one will also select
all nt:resource nodes without your custom mixin set and without the
hfs:description property - hence the error.

> Then I created my own custom node type (hfs:file) which extends the
> "nt:file" node type. Then when I queried on that node type it returns the
> results correctly (meaning it searched both my custom property and the
> binary file contents.
>
>        //element(*,hfs:file)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)

Yes, that's because now element() part selects the file node, and the
jcr:contains now has the correct relative path.

> Now what I need clarification on is what I am doing by defining my custom
> node type the correct (i.e.. best practice) way to go about just adding
> custom properties needed or should I be using a custom defined mixin?  And
> If I should be using a mixin then which node does it go on? The "nt:file" or
> "nt:resource"

You decide ;-) That depends on how you want to handle metadata
separately from jcr:content or not (ie. if it changes separately from
binary data). But for the beginning putting it into jcr:content is
fine.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message