XSLTsearch looks inside your docType properties, which is probably a sub-set of what gets sent out to the website visitor between the 'body' tags. It doesn't make much sense to search the navigation, for instance. Rather, it is the substance of the site that is worth searching (imo), and that's exactly how you structure your umbraco sites... content editors only work with the substance of the site, the bodyText and other document type properties you've established.
With XSLTsearch you can specify which docType properties to search and which fields should be given a higher ranking in the search results. This is done in the macro parameters. Check the full documentation for more information on configuring XSLTsearch.
While I think this is a good approach for XSLTsearch, there is also a real limitation to XSLTsearch in that it can only search through the content stored in docTypes because that's what's available to xslt itself. Again, I don't see this as a real-world limitation.
If you want to search the output of your pages then you might want to use a search engine that 'crawls' your site, such as a custom google search or MS Search Server Express, for instance. You'll have to wait for the crawler to update itself, whereas XSLTsearch is always instantly up-to-date. But that would be a trade-off you'd have to decide on.
What kind of data is it you want to search for within the body tag? If you need to use search to find it I assume it is some kind of text that will change with every (or so) page?
If so, one solution would be to not enter that data into the bodytag in the template, but to have a field for it on the doc type, enter the data on the content node and have that data written to the body tag in the template.
Then you should be able to search for it using xsltsearch.
Thanks guys, in my current project not all of the content is placed inside page fields or properties (as much as I have wanted), thats why the question popped in my mind.
XSLTSearch: how to search in the <body></body> tag?
Pretty self explanatory, I am just exploring the possibilities, can it be done?
oh, title was formatted, it meant to read "inside <body> </body>"
XSLTsearch looks inside your docType properties, which is probably a sub-set of what gets sent out to the website visitor between the 'body' tags. It doesn't make much sense to search the navigation, for instance. Rather, it is the substance of the site that is worth searching (imo), and that's exactly how you structure your umbraco sites... content editors only work with the substance of the site, the bodyText and other document type properties you've established.
With XSLTsearch you can specify which docType properties to search and which fields should be given a higher ranking in the search results. This is done in the macro parameters. Check the full documentation for more information on configuring XSLTsearch.
While I think this is a good approach for XSLTsearch, there is also a real limitation to XSLTsearch in that it can only search through the content stored in docTypes because that's what's available to xslt itself. Again, I don't see this as a real-world limitation.
If you want to search the output of your pages then you might want to use a search engine that 'crawls' your site, such as a custom google search or MS Search Server Express, for instance. You'll have to wait for the crawler to update itself, whereas XSLTsearch is always instantly up-to-date. But that would be a trade-off you'd have to decide on.
Make sense?
cheers,
doug.
What kind of data is it you want to search for within the body tag? If you need to use search to find it I assume it is some kind of text that will change with every (or so) page?
If so, one solution would be to not enter that data into the bodytag in the template, but to have a field for it on the doc type, enter the data on the content node and have that data written to the body tag in the template.
Then you should be able to search for it using xsltsearch.
Thanks guys, in my current project not all of the content is placed inside page fields or properties (as much as I have wanted), thats why the question popped in my mind.
is working on a reply...