jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Shoener" <mshoe...@softwareapps.net>
Subject RE: Custom node or mixin added to existing node
Date Fri, 09 Oct 2009 14:20:01 GMT
But the problem with the following query:

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

Is that is searches on the entire node, not just the file contents and my
specified property.  I would like to only search on specific properties and
the file contents, not the entire node. I would like to keep the meta data
separate from the actual file contents. So do I create a mixin and add that
to the "nt:file" parent node of the "nt:resource" node that holds the actual
binary file data? If so then do I query against my custom mixin type?

Also, I thought in order to have the property returned, whether it contained
the term being searched or not, I had to put the /(hfs:description |
hfs:anotherpropertyname) at the end of the query. Is that incorrect then?

Best Regards,

Michael Shoener
Support Staff
Software Application Services, Inc.

-----Original Message-----
From: Alexander Klimetschek [mailto:aklimets@day.com] 
Sent: Friday, October 09, 2009 10:05 AM
To: users@jackrabbit.apache.org
Subject: Re: Custom node or mixin added to existing node

On Fri, Oct 9, 2009 at 15:38, Michael Shoener <mshoener@softwareapps.net>
> 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.


Alexander Klimetschek

View raw message