Web Fields
If you've been using Domino 6 for a while you might have noticed a change. If you have an <input> field on your web form you no longer need to have a field on the back-end Notes form with the same name. This used to be the case and this error used to be the result.
Is this change by design, I wonder, and is it documented? What are the knock-on effects? Personally I think I'll always make sure the corresponding field exists, just in case of any regression in future releases.
What does this mean for us anyway? I can't think if it's a good or a bad thing. Nor can I think why I might want a field on the web form and not the Notes Form. Apart from the "Query" field used on this site as the search field, which exists on all pages. There's no need for this to exist on the Notes form really.
Because the field doesn't exist on the form, it doesn't exist on the document either and so it can't be referenced in any WQS agent. Although it forms part of the POST data sent from the browser it's never actually stored. In short, it's only available in the browser.
Just thought I'd pass it on...
Skip to the 
You can subscribe to an individual
I don't get it. If it is not accessible by WQS agent AND is not saved then it does not exist at all. You can create such a field with pass-through HTML or Javascript but once youz POST it disappears..
The only thing is that it is not reported as an error.
Or am I just plain stupid?
Josef,
It could be referenced through the Query String, but other than that, in effect it disappears like you say.
Hi Josef. Maybe I should have pointed out that it was in R5 that all fields in teh web form had to have the corresponding Notes equivalent. If you didn't there would be an error and the document wouldn't even save.
Don't worry, you're not stupid. Maybe this isn't as big as deal as I thought. It's only an issue if you create fields in HTML.
Lee. You can only ref fields in the Query String if you use GET to "post" your forms. Most Domino forms don't.
This would be really useful for designing dynamic web forms - ie where the design is not hard coded. I have this feature in my web forms database where users can design web forms without touching Notes Designer, but to acheieve this I have to have loads of fields to cover every option, and hide the ones we don't need.
This way you could build the <input> in the web query open agent or cmoputed text fields.
Of course, if it isn't saved, what's the use? Well, (haven't tested this) you could use javascript prior to the save to concatenate all these 'fake' fields into one real hidden field .
Just a thought.
So, if its not documented and you say you always create corresponding Notes equivalents, so how'd you find out?
I put it to you, Mr Howlett, that you were guity of neglecting your corresponding equivalents and that when you discovered your crime, you tried to gloss it over as some sort of inspired, masterly detective moment.
Jake Howlett, the Sherlock Holmes of the domino world........Well it is Friday afternoon.
I can't remember Andy. I think I noticed by accident originally. Then somebody mailed me about it and I thought "Maybe I can make a blog out of that". It's amazing what you *can* make a blog entry out of when times are hard ;-)
Can we have some updates on the House???????? How's the flooring???
Aha! Just what I wanted. I've been slaving over "virtual" HTML fields for months. There's a WQO on a form to do a number of lookups to a number of docs in a number of views, and builds some HTML. When the user submits their survey (this form) I have to use javascript to parse the virtual fields and empty them, and pass the data as a list to a field Domino is expecting (i.e. is on the form). Now if only I'd upgraded to R6 first....
Tim (and Jake)
Actually you can build a dynamic webform like Tim says whithout notesfields and than post the form to an agent. In the agent you can use the Request_Content-field to parse the fieldvalues and do what you want with them...
We've created a module like this to let users dynamically build webforms from the Client.
By the way, Jake. Great site! Keep up the good work.
//Johan
Good point Johan. When I said you can't access values in the agent I meant via doc.FieldName(0) methods. Parsing request_content ain't for the feint-hearted...
I found this out accidently not to long ago and it really came in handy on browser based forms when you combine it with DHTML and javascript.
Suppose you want to have fields that only display depending upon the values in other fields. Write your hide layers routine in javascript and use the onBlur event to pass the value of the field on the DHTML layer to an actual notes field. Use "Type=hidden" to hide the notes field from the browser.
As to the dynamic webform. Would it not be a terrible security hole if it did not require a agent to specificaly parse the request_content?
Somebody could use your FORM action, create their own form with your action and create any kind of document on your server.
Joakim. Not sure what you mean but I think the answer is no, there's no danger of that. Exactly how could a user create their own form?
Hey Caroline McGrath, I just wanted to give you a heads up that I created dynamic web forms both in R6 and R5. In both cases, I use javascript to dump all the dynamic fields into a multi-value "Notes Field". That's all you have to do in R6. In R5, I simply deleted the "fake" dynamically created fields before I saved the doc. The easiest way I did this was to put the fields in a div, and then replace the innerHtml property of the div with a null value prior to an @Command([FileSave])
Johan (Jake)
How do you parse the request_content in an agent?
/Henrik
Henrik. There are examples on the LDD forums. Here's a simple one:
{Link}