http://example.holidays.no/index.nsf/tokyo
Everything in regard to Tokyo
http://example.holidays.no/index.nsf/hotels/tokyo
Hotels in tokyo
http://example.holidays.no/index.nsf/restaurants/sushi
Restaurants that serve sushi
In the HTTP Head Content of $$ReturnGeneralError, add a little JavaScript to extract what is typed after the path to the database (application if you're using N8 beta ;) ).
"<script>
var db='"+@WebDbName+"';
var loc=document.location.href;
var viewToSearchIn = '($People)'; //if not specified
var newloc;
//if searchview->error, return general error
if(loc.toLowerCase().indexOf('searchview')==-1){
var query=loc.split(db)[1].replace('/','');
if(query.indexOf('/')!=-1){
viewToSearchIn = query.split('/')[0];
var tmpquery = query.split('/')[1];
newloc=loc.replace(query,viewToSearchIn+'?searchview&query='+tmpquery);
}
else{
newloc=loc.replace(query,viewToSearchIn+'?searchview&query='+query);
}
query=query.replace(/s/g,'+and+');//replace whitespace with +and+
//avoid the back-button pointing to the erroneous url
document.location.replace(newloc);
}
</script>"
Above I'm using a view called ($People), to search in. You can pass the "query" to whatever you want.
Demo application
You have to create the full-text index on the db yourself to searh on the web.
This is the same as Jake's FakeNames.nsf, but I changed the $$ReturnGeneralError form.
Tested URLs:
http://yourdomain.com/fakenames.nsf/tommy
Searches in the default view, ($People)
http://localhost/fakenames.nsf/peoplecat/abigail
Searches in the peoplecat view
http://localhost/fakenames.nsf/holidays/aus*
Searches in the holidays view
With the last view, you can also write: http://localhost/fakenames.nsf/holidays/austria
which opens the austria document (sorted view).
You can of course take this even further, with per-application mapping-documents for particular searches.
4 comments:
Cool. But if $$ReturnGeneralError is used for search, what do you used to handle error pages?
This is just a proof of concept.
If you write ...nsf/asdf/asdf, you will still get the error page.
You can also filter out pages that has some http_referrer, filter out URLs with a specific structure, etc.
I'm not to sure, but with most well-designed applications, people "never" get to see the messages $$ReturnGeneralError anyway?
Inspired and brilliant.
Thank you :)
It was actually Microsoft that inspired me (sorry IBM). They have smart mapping of keywords on microsoft.com
You can type URLs like:
http://microsoft.com/vista
http://microsoft.com/officexp
and get redirected to the most likely site to that keyword.. Maybe, in the future, I can type: http://codestore.net/yui and get a page with all in regard to yui on your site.. ;)
Post a Comment