An Alternative To Generating HTML For All Fields
As I've always understood it the sole reason for generating HTML for all fields on a form was to make them available to JavaScript — be it either to read or write values.
Whatever the reasoning I've never liked it, never used it and always disabled it straightaway on any Form I've inherited. To me it causes as many problems as it solves and just seems a little lazy.
There are better ways of making your fields available to JavaScript. For example, we could add this to the Head of the form:
<script type="text/javascript"> DEXT.Document.Fields = { "Name": "Jake Howlett", "Street": "Letsbe Avenue", "County": "Notts", "Phone": "999" } </script>
The web page then has a set of fields it can refer to when needs be. The following function loops them all and alerts their name and value pairings (like "Phone: 999"):
DEXT.Document.listFields = function (){ for (field in DEXT.Document.Fields) { alert(field + ": "+DEXT.Document.Fields[field]); } }
Or you could reference a field directly, like so:
alert('Your name is: ' + DEXT.Document.Fields['Name'])
This approach is a much cleaner way of having field values available in JavaScript. Note that keeping them all inside the DEXT global variable also prevents naming conflicts and is much better than having something like this in your Head:
<script type="text/javascript"> var Name= "Jake Howlett"; var Street= "Letsbe Avenue"; var County= "Notts"; var Phone= "999"; </script>
That's just bad! Don't do that. It's especially bad in that it creates a global variable called "name". Tut tut.
You don't have to call the global object DEXT. You can call it Acme or HRApp or anything you're confident won't conflict with other variables used.
You can easily generate the JavaScript array of fields like this:
Fields:="Name":"Street":"County":"Phone"; "<script type=\"text/javascript\">"+@NewLine+ " DEXT.Document.Fields={"+@NewLine+ @Implode(" \""+Fields +"\": \"" + @Text(@GetField(Fields)) + "\""; ", ")+ "}"+@NewLine+ "</script>";
Although wouldn't it be nice to be able to choose it on a per-field basis!
You can see a demo of this approach in use here. Change some values in the fields and save the document to see the JavaScript update.
Thanks Jake - and yes, very refreshing to read a blog post not from bloody Orlando !!! :-)
I prefer using hidden fields with a computed text in the value attribute on my webform, wherever I need them fields. Different approach, I guess :)
What's the beef with Lotusphere? Anyway, definitely a nice way to deal with it. Json is the way to go. Also if you're directly referencing it (DEXT.Document.Fields['Name']) you don't need to use the array notation to get at the value. DEXT.Document.Fields.Name will give you the same results.
And how about not hiding the fields, but just putting them in a div with css display: none?
That is nice. The only problem is that if you add or remove a field, you have to remember to change the code in the JSHeader too.
Jake's (and Karel's) way is nice because you still have access to the field values in read mode.
Is it wrong to put the fields in a span? Sometimes we put the fields in SPAN tags in name/value pairs. That way... in javascript you can just call spantagname.field to get the value.
Just one little niggle (and you know I niggle with love) -- you'll want to @Implode the field value as well. Whether you use a text separator like a comma or make an array out of the values is up to you, but if you don't implode the value, a multivalue field will give you an ambiguous index tag -- and that's bad.
What Karel suggested is the best way of creating a hidden field (and even Domino.Doc code implements the same way) on the form with the value dynamically computed using computed text. The only problem with this approach is this the field will be saved along with the document. There may be cases where I require a certain field to be used by javascript and would'nt like it to be saved along with the document. Jake's way of implementation will be useful in such cases.
I guess, enclosing "computed for display" fields in hidden "span"'s would be a nice solution as that makes the fields available both to javascript using innerHTML and Lotusscript.
Any thought on that ?
-T