Search Form For Reader Access
Tony Walters posted an interesting problem on the forums yesterday. Without giving much thought to whether it is indeed a problem or to why he wanted to do it, I responded with a solution. Here, in its visual form, is a way to add a search form to a site that users only have read access to and on which JavaScript is not allowed.
How it works: End the Domino form and start a new one. Make sure that its action parameter is GET. This means the user doesn't need anything above Reader access. Then make the action parameter equal to the path to the view you want to search. Then add two fields, one called Query. Then add a button that will submit the form without needing any JavaScript. The result of submitting this form is a request for a URL of the format Domino uses for searching, as below:
test.nsf/srchviewname?SearchView=&Query=test
When a GET form is submitted the browsers takes the form's action parameter and tags on a ? character followed by the content-pairs of all the fields on the form. That's why we need the field called "SearchView". This does nothing more than fool Domino in to believing it's a bona-fide search request. Without this field, the URL looks like the one below, and Domino don't like that
test.nsf/srchviewname?Query=test
Now I'm not saying this is a solution you'd catch me using. It's just another example of an occasion where it helps to be able to "think outside the box". It's the ability to apply a number of hacks like this that make it possible to tackle almost all problems.
I made a change to the comments system last night. You don't have to wait for me to approve them any more and all HTML is not permitted! Oh, and I made the input box a lot bigger ;o)
Skip to the 
You can subscribe to an individual
This comments box is bigger?
Jake. Couldn't you get round the Search problem simply by giving users "Write Public Documents" Access, creating a Search Form (that allows Public access) and then firing off the search with a simple $$Return field? Or have I misunderstood the point of the question (wouldn't be the first time).
Hey Jake;
I like this. It shows that "if there's a will; there's a way!"
And it's applicable in the real-world! (unlike my CGI Variables article ;-))
-Chris
http://www.dominoguru.com
This is great. I feel "famous", AND I get a solution. Thanks! There's just two things I still can't fathom. 1. Why does Domino INSIST on generating its own FORM element, even in read mode and on PAGES? 2. And what's so wrong with this method? "Now I'm not saying this is a solution you'd catch me using." I can't see what's wrong with it, I don't want to use it if it's BAD of me to do so. I like to be good. Or something.
Tone, I'm a purist. I like things just so and don't like having to do things like this. Feel free though, it's not that bad....
It's not a "bad" solution per se. It works allright, just it's more like a "bad form".
Especially if you're a purist in standards (I'll point you to Jake's XHTML fetish ;) which couldn't be satisfied with Domino R5).
test.nsf/srchviewname?SearchView=&Query=test
The "bad form" part here being that first "=" character.
Then again, it -is- a nice solution if you have to cater for non "JavaScript enabled" browsers like Lynx.
I, too, have a need to do this without javascript. Here's my solution.
I have a form that is only used for receiving search parameters. The form has a $$Return field that computes the search URL string. I make the form accessible for public access users.
I can then write an HTML form to anywhere on the site that allows users to enter search criteria. The submit button for the form creates a doc from the search form, which of course fires off the required search URL.
The beauty of this approach is that I can write the HTML for the form anywhere - there is no need to create specific fields on any of my main web forms.
The question? Is there anything 'bad' about this approach.
How about a Form with a webqueryopen agent that searches the database and populates the required fields. The URL of the search could be http://server/db.nsf/SearchResults?ReadForm&Query=xyz....
The ReadForm should take care of the reader access issues and the $$Return field can be used to generate the URL.
<<b>>will it</b>>
Jake: I know, but I'd like to be "a purist" too. But part of that purism leads me to avoid necessitating users having JavaScript enabled for navigation/searching. Firstly, I think searching IS navigation, and I like websites to be accessible to non-javascript browsers (JavaScript's fine for "extras" but site should function without it). And secondly, and more selfishly, I don't know JavaScript!
HWK: I've not heard it called that before, but if that's what it is called, then I have an "XHTML fetish" too. Meaning that I keep as close as Domino lets me to XHTML standards! I didn't actually notice the weird extra "=" in the URL argument bit "?SearchView=&Query=test". I thought it generated just "?SearchView&Query=test", which I assume would not be so "bad"! I can see your point now. I might see if I can hack a way around getting the "?SearchView" bit of this into the resultant URL without using that hidden field. I'll give it a whirl.
Anura: I don't know - but I am interested in your method too. I'm not sure I know how to do this, but I'll give it a try. It also has the advantage of giving us stats on what people search on!
Rishi: I'm not sure I understand the "populates the required fields" bit. What fields?
Test: Nice try.
By the way: codestore, FOR MY NEEDS, has WAY overtaken Notes.net in terms of usefulness now.
The best reply I got to my question on Notes.net was from Jake anyway!
And the comments on this thread do "add value" (I hate that expression) to codestore. Thank you very much.
Tone, I agree with you entirely regarding Codestore and it's usefulness. I never use Notes.net any more. And I check Codestore daily (several times!). Maybe Jake should add a Codestore forum area that we can all use instead of notes.net :-) I'd be prepared to pay Jake an annual fee to register to use the forum because I'm sure it would be popular. How about it Jake ? £5 a year fee ?? :-)
The main problem with The notes.net forums is the search engine!
When you need an answer to something, and you're not quite sure how to word it, the LN search engine makes it that much more difficuly. The amount of times i've had to type 'whatever_1 AND whatever_2' as my query then when it comes up with No Documents found, simply had to reveres it to 'whatever_2 AND whatever_1' and then results come up! - it's just utter crap! and the developers behind it should be kipper slapped silly!
Richard, I'm with you on your forum remark, I think Jake's audience has lots of advanced developers who growed over (was that english?) the notes.net forum. These blog comments do add value, but it would be nice if we could collaborate on all subjects, besides the ones Jake finds interesting. With all respect of course Jake, because theyre usually very interesting. So, how about a domforum Jake ;)?
prawnFresh: My main problem with the searcb on Notes.net forum is the repeat posts. Not just the repeat posts, but the people complaining about repeat posts. People that say "try searching the forum for *** **** AND ***" mean that if you ever do search for "*** **** AND ***" all you get is people telling you to search for "*** **** AND ***". It's SO simple!
Ferdy, I'm glad you agree. It would be nice to start a forum with a clean slate wouldn't it ? And I'm serious about paying for it because I think that a) it would encourage serious particpiation only and b) would make Jake a bucket load of cash so that he can continue all the good work. And "domforum" would be a good name Jake (wheras "freedomforum" would not).
Although the Dutch have a reputation of being cheap, i would be willing to contribute financially to the forum. I do think the rest of the site should remain free, as asking for money can scare of a lot of people. I do think many people would be interested in a high quality Domino forum, but how much are ACTUALLY gonna pay for it? Maybe paying members should get certain privileges, like access to templates and stuff?
Let's not get ahead of ourselves, let's wait for Jake's comments on the inital idea.
I would pay 10 € for a year fee. Having access to a high quality Domino forum would be very profitable for me, as I spent a lot of hours trying to find solutions for my needs and problems regarding Domino programming.
Two things:
1) The reason _I_ don't like this solution is that it requires "Generate HTML for all fields" to be enabled, which I think is a waste of resources and a (minor) security issue. The SearchView field should instead be passthru html of <input type="hidden" name="SearchView" value="">. (Don't get me wrong, I love the concept. This is a "Yes, and..." point, not a "No, but..."
2) Regarding the forum and a pay portion of the site: Hiding templates and stuff from the public is the wrong direction, too, IMO. I think Jake should shamelessly embrace the model that he's currently (and I think accidentally) practicing. The webmaster of SelfPromotion.com has written a realy good paper (about 5 screens in length) about it. See http://tipping.selfpromotion.com/ The side-navigator of every page could have a "Useful? Tip me!" link.
... and no, I haven't tried using SelfPromotion.com's services, but I plan to soon.
John, it doesn't require Generate HTML for all fields. Examine the above picture in more detail.
You're right though, it probably would be better as *all* passthru.
First thing I did after testing Jake's instructions was to replace the "fields" with <input> elements. Works fine, if this is your preference, and it is mine, generally. I can't stand "fields" in my pass-thru, I only use them when I HAVE to. They don't go GREY when told to pass-thru, and this makes it difficult to see what I'm doing. For non-editable fields I tend to use <computed text> bits which is easier to mark and un-mark as pass-thru. Means I have to use @Name( [Abbreviate]; FieldName ) sometimes though, where a Names field type would normally do this for me. For editable fields (in edit mode) Domino also uses uppercase MarkUp, something my recently crowned "XHTML fetish" leads me to dislike. (Thanks HWF!)
I never checked "Generate HTML for all fields", I promise, and it worked. I've never used that property!
If only I could find a way of getting rid of the extra "=" character in the resultant URL. I tried removing the SearchView field and changing the form element's action attribute from "searchviewname" to "searchviewname?SearchView" in the hope that it would just append "&Query=test" after "searchviewname?SearchView", but it just changed the URL to searchviewname?Query=test which, as Jake says, Domino doesn't like. Doesn't even know what to do with it!
So my conclusion, so far, is that if you don't mind the url to have an extra (and "inpure") "=" character in it (eg. searchviewname?SearchView=&Query=test", then this method is good. If you don't like that, then I don't know how to get rid of it.
Is this Wutang "=" the only thing "wrong" with this method? There can't be anything wholly "wrong" with closing the Domino generated FORM element in order to start our own forms, because Jake uses this for this very comments form! Jake? I want to be a "purist" too!
IF you're really unhappy about having a '=' in your parameter, the only other thing to do is to make an agent, and use a 'post' method instead of 'get' then your agent can parse the information, and redirect it to the search engine. Thats what I had to do here, but I did it not for looks, but actual functionality - i.e. couldn't do it any other way.
http://www.shropshire-cc.gov.uk/vacancy.nsf/search
(note: hmm may have to copy and paste that link... no clicky clicky!)
Nice one prawnFresh. I will try your method too. Nice to have options!
So where/when/how does the agent run? the form element's action attribute is "/vacancy.nsf/viewStraightList?Searchview". Cool. That brings up the URL. But where does the agent run? I thought maybe it was a WebQuerySave agent (don't know exactly what this would do), but your form is not a Domino generated one is it? I don't know.
Tone: Go a bit further down, to the advanced search part. The action for that is "/vacancy.nsf/generateSearch" with the "post" method.
The agent is just set up as "On Schedule Never". The code just goes through and rearranges the posted selections to a query string and forwards the user to a properly formatted field search query.
The annoying part with this however, was finding whether the user had multiple selections, and retrieving and reformatting those.
Sorry prawnFresh, looking in the wrong place again!
I understand now (I think). I don't know if sess.documentcontext.queryfieldname(0) will work, I hope so. I assume that's how you get the query from the <input> element. The agent's my job anyway, will read up again. I have to say, the Domino Designer Help for web agents isn't as good as it could be. For some things it is much better, but the web agent documentation's a bit vague in places, innit?
Tone: Anura's method may work like this:
in any form/page/view/etc: put the following pass-through html:
[/form][form action="Return?CreateDocument" method="post" enctype="multipart/form-data"][input name="searchQuery" type="text" SIZE=44 MAXLENGTH=90 value=""][input type="button" class="button" value="Search" onclick="if ( this.form.searchQuery.value==''){return false;} else {this.form.submit()}" /]
The above creates a form on your form/page/view/etc with a field called searchQuery and a submit button next to it.
Create an form "available to Public Access users" called "Return" put two fields: queryString and $$Return. Make all the required calculations on the queryString field in the $$Return field.
e.g. "[/" + DB + "/searchview?SearchView&Query=" + searchQuery + "&SearchWV=FALSE]"
Simple and effective.
It also gives you the ability to create Google style search queries as described in:
http://www.codestore.net/A55692/store.nsf/all/339186C51DA90D7E86256B5E007A7991?OpenDocument
It also gives you the opportunity to create view to see what people are searching for!
There are some bugs in the above Comment. The field "queryString" on the "Return" form should be called "searchQuery". Read a better explanation on:
<a href="http://www.codestore.net/A55692/store.nsf/0/42420B7236A4D5A786256CA6003D06FB">Standing on Jake's shoulders</a>