Allow Values Not In List
Here's an age old Domino problem - if you have a keyword field with Allow Values Not In List selected it will not work on the web. Here's my most simple of simple solutions. First, a rant.
There's the obvious reason why these fields won't work in a browser - HTML doesn't have a Form element like it. It has the Select element but there's no space in that to add a new entry. Why though does Domino not give us a Select element with the default options, instead of simply an empty text field? Because of this quirk any form that has to work in client and browser has to have a mess of different field to cater for it. Look at the Main Form in the discussion template to see what I mean.
Anyway, let's only worry about the web. Say you've got a keyword field that does an @DBLookup to a view. You want the user to be able to add new values though. How? Well, there are various fancy DHTML solutions to this but I wanted to offer a simple fool-proof alternative.
First thing you need to do is add a Computed For Display field below the keyword field (called Category, say), call this new field NewCategory and give it a value of:
@If(@IsDocBeingEdited; "New Category: [<br /><input type=\"text\"
name=\"NewCategory\" value=\"\" />]"; "")
When in edit-mode this field adds an extra field to the form. Why is it Computed for Display? So that it never saves with the document. There's no need for it to.
Now, in the Input Translation event for the Category field, we need to add the following:
@If(@Trim(NewCategory)=""; @ThisValue; NewCategory)
When the document saves the Category field will save anything added to the new field. If it's empty it will save its own value. If you keyword field allows more than one value to be selected, this formula is a little different. You can see how in this simple sample database.
I know what you're thinking. Has Jake lost the plot? Why on earth is he talking about something so simple!? Believe it or not I considered making a full-length article out of this. I know it's a small issue but it's sometimes the simple things that are as confusing as the complex.
Skip to the 
You can subscribe to an individual
Little gems like this are ingenious! Simple yet beautiful. Thanks for sharing.
Thanks Jake. Nice tip/blog (as usual!)
I know you wanted a "simple" solution, but another alternative is Ajax. I've modifed the ajax samples from nsftools and developed an ajax js library that does type ahead lookup for a field from a view.
I've also done the same Neil, not quite as simple as Jake's idea but effective all the same.
Good stuff as usual Jake; it reminded me of an old-school Domino hack to use with it involving multiple fields. More info over at my new blog: {Link}
OK - I am sure I am overlooking something elementary here. I have tried doing this (and have reviewed Jake's sample database), but my "Category" field always ends up with the Computed-for-display value of the newCategory rather than whatever was keyed in.
In other words, it contains the following:
New Category: [<br /><input type="text" name="newCategory" value="" />]
rather than what the user entered.
A co-worker just discovered the problem. If your form has "Generate HTML for all fields" enabled, this trick does not work. Back to the old way... (unless someone has found a way to do this in that context :)
Cheers, Jake. Just had need of this, though I couldn't remember the keywords to find it through searching... fortunately it wasn't a very old post. :-)
An apparent problem with this approach is that if the user saves the document and later edits it, the "non-keyword" value is lost. This shouldn't be too hard to fix; but it would require saving the other field to the document.