Article: Domino XHTML Forms »
FERDY CHRISTANT - JUN 18, 2004 (06:16:02 PM)
Everyone who does a bit of web development on the Notes/Domino platform knows it...you do not have full control over the server's HTML output. Specifically, you cannot change the doctype of the page, unless you wanna completely bypass the model and create all the HTML yourself. This makes it almost impossible for web developers to implement a Domino site that is based on true standards, such as XHTML.
This article describes the methods I used to implement 100% XHTML-compliant web forms in Domino, without using agents or code-generating techniques that cache Notes HTML documents. Yes, that includes edit forms, not just view templates.
Many have claimed that Domino is not the platform to do this. I don't know if this is true, this blog template and all its forms are a 100% XHTML-compliant, and it only took a little bit of extra work and the hacks aren't even that dirty, if at all. Just jump on the Domino wagon to full XHTML compliancy and read on.
The Basics
Let's just get to it right away: In order to comply to the XHTML standard within Domino, you have to bypass Domino by making forms HTML-only. This does not have to be a showstopper. In fact, it is very likely that you already use pass-thru HTML in big parts of your Domino web applications, because you like and need the control. To go from pass-thru HTML (in combination with Domino) to XHTML-only brings some limitations and extra work, but most can be overcome, as you will see.
Note: This article comes with a downloadable demo database. I recommend you to open it in Designer and follow along.
Before we start looking at the actual Domino implementation, let's review some XHTML guidelines. Moving from HTML to XHTML is quite easy, and you will learn to appreciate the improved markup. These guidelines always seem to keep me out of trouble:
- XHTML is basically just another XML standard. So it is case sensitive. Always make sure your tags are fully lowercase.
- Always close all your tags.
- Always close all your tags in the right order. Example: If you start a bold tag after a font tag, be sure to close the bold tag before closing the font tag, not the other way around.
- Singular tags, as they exist in HTML, such as the br and img tag, need to be self-closed in XHTML.
- Some tags have required attributes. For instance the img tag has a required alt attribute. Be sure to know what is required and stick to it.
- Quote all your attribute values within tags.
- Escape invalid XHTML characters.
Now, let's use the above guidelines to rewrite an HTML example into XHTML. Here's the sloppy HTML input:
<P>
<A href=http://www.ferdychristant.com>
<IMG src="logo.gif">Homepage</a><br>
</P>
And this is the same fragment rewritten as XHTML-compliant markup:
<p>
<a href="http://www.ferdychristant.com">
<img src="logo.gif" alt="logo" />Homepage</a><br/>
</p>
Tip: Be sure to check your markup with a validator regularly. It helps you to spot mistakes in an early phase. Check the official XHTML Reference for full details on the markup language.
Setting up the Domino form
Assuming that you now have some XHTML basics on your sleeves, let's set up our XHTML-compliant Domino form. To start with, we need to tell Domino that our form is of type HTML, this will make sure Domino does not generate any of its own stuff to the browser. You can simply do this by setting the content type property of your form to HTML:
Now that we have set the type to HTML, we are in full control of the markup to create, be it XML, XHTML, HTML, or any other plain text format. After telling Domino our format, we also need to tell the browser. This is done using a docucment type declaration (doctype) which occupies the very first lines of your pages. Many browsers go into a specific rendering mode based on this doctype. There's lots to learn and read about doctypes, and this is not the place for it. I always use the following one:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">"en"gt;
There's nothing to know or remember about doctypes. Just put them in a subform and embed it at the top of all of your forms. In fact, it is even better to include everything that should be common on every page in a subform like this. This includes references to stylesheets and javascript libraries. In the demo database I have them wisely stored in the HTML Header subform. Note that you no longer need to mark everything as pass-thru HTML, since we already have set the form's content type property to HTML.
On a side note, I always use a slightly personalized version of Jake Howlett's "CommonFields" subform, which holds many useful fields for use in any Domino web application:
That's all the preparation we need for now. Let's start building a XHTML form.
Implementing the XHTML edit form
First, let's consider what we're gonna do. We want to build a XHTML-compliant Domino form with which we can read, create and edit Notes documents. It would be good if we could do this in one form. Well, we can.
The first problem we're gonna run into is Domino URL behaviour. Both a ?openform and a ?editdocument URL prefix will generate an error, since "Documents treates as HTML cannot be edited", according to Domino. To overcome this, we need to use different conventions for URLs like this. Instead of ?openform to create a document, we're gonna use ?readform. And, instead of ?editdocument to edit a document, we're gonna use ?opendocument. This may look weird a little at first, but trust me, no user cares about your URLs.
In our situation, the actual action to take on the form is critical for loading the right markup. Therefore, I included an Action field on the CommonFields subform with the following formula:
tmpQueryString:= @LowerCase(Query_String_Decoded);
@If(
tmpQueryString = "readform"; "new";
tmpQueryString = "opendocument"; "edit";
"read"
)
So now in all forms we know what action the user is trying to perform. We will use this information in a minute.
Form structure
Let's take a step back and see how we are gonna break down our form. Basically, we need at least 4 (computed) subforms, in this order:
- CommonFields - Holds essential fields for any web app.
- HTMLHeader - Sets the doctype and references to styleheets and javascript libraries.
- Computed - Loads the correct subform for the requested content.
- Fields - Holds the actual Notes fields for storage of HTML input fields.
@If(
Action = "new" | Action = "edit";
"sfrmWContactEdit";
"sfrmWContactRead"
)
As you can see, the ContactEdit subform is loaded for both the create and edit actions. All other actions will simply display the ContactRead subform. So far, there has not been a significant amount of extra work to do for XHTML-compliancy. The majority of it is actually just in one subform, the edit/create form.
Let's move on first to our 4th subform, which is embedded in the bottom of the form. This form simply holds the storage fields that Domino should use when a post is done to the current form. The demo database has an example on board, named "ContactFields":
Nothing special about these fields. It is not required to create security fields or a $$Return field, yet I always consider them a best practice.
With this last subform in mind, let's go back and zoom in on to the most important one, the subform used to create and edit documents. On this subform, we will bypass Domino and create our own form with pure XHTML tags. The first line is crucial in this matter:
<form method="post" action="<Computed Value>" name="frmWBlog"
enctype="multipart/form-data">
In this form tag we specify some basic form details. The trick is all in the "action" attribute, this defines what Domino should do when the user submits the form. The computed value formula for the action attribute of the form tag is like this:
@If(
Action = "new";"frmWContact?createdocument";
Action = "edit";"contacts/" + @Text(@DocumentUniqueID) + "?savedocument";
""
)
So if we are creating a new document, and the user submits it, We redirect the post to our current form and append it with the ?createdocument URL suffix. Since we included an edit subform which contains the HTML input fields and a fields subform that holds the Notes fields, Domino will see the match and create a document and populate the fields. For existing document, thus an edit action, we need to post to the right document in the right view and append the ?save document URL suffix. Again, the HTML input fields combined with the Notes fields will do the job of saving the changes.
Let's move in with our edit subform now. All we need to do is to create the correct XHTML markup for the input fields, which should map to the names of the storage fields in the 4th subform. I will illustrate this process through two example fields, one is a simple text field, the other a check box field.
The demo database contact form has a name field on it. In the 4th subform it is called "conName". We need to recreate this field as XHTML markup:
<input type="text" name="conName" id="conName" value="<Computed Value>"
size="40" />
Where the computed value holds the following formula:
@If(
Action = "new";"";
conName
)
Note that we are using the subform for both the create and edit purpose, therefore we base the input value on the action performed. You could of course have two separate subforms for this, but this would lead to a lot of duplicate XHTML markup.
Checkbox fields and the like are a litte more complex, yet doable. The demo database contact form holds a checkbox field named "conHobbies", which holds one or more hobby entries for the contact person. This field can be recreated as follow in a computed text value
Hobbies:= "Domino":"Drinking":"Smoking":"Poker";
Result := "";
@For(n:=1;n<=@Elements(Hobbies);n:=n+1;
Result:= Result + "<input type=\"checkbox\" name=\"conHobbies\" value=\"" + Hobbies[n]
+ "\" id=\"" + Hobbies[n] + "\"" + @If(@IsMember(Hobbies[n];conHobbies);"
checked=\"checked\" ";"") + " /><label for=\"" + Hobbies[n] +
"\">" + Hobbies[n] + "</label><br />"
);
Result + "<input type=\"hidden\" name=\"conHobbies\" value=\"\" />"
This may look a bit complex or messy but the idea is simple: we loop though the allowed hobby entries and see which ones are selected for the current document. For all the selected hobbies we set the checked property of the input element to "checked". Note that the label tag and id attributes are optional, I use them to make the form more user-friendly. Be aware of the last line, this is needed to overcome the notorious Domino checkbox bug! There's more types of fields to see in the demo database, so I will leave the edit markup for now.
We're not yet completed creating the markup for the edit form. We still need to be able to save the document. This simply comes down to creating the XHTML markup for a button that submits the form upon click. In the demo database I do this after a validation check:
<input type="button" name="btnSave" value="Save" onclick="if ( QuerySave(this.form) ){
this.form.submit()}" class="button" />
Likewise, a cancel action would be simply a redirect to the entry view. Details in the demo database.
What's next? Not a lot, using the techniques described above we can create XHTML-compliant Domino forms to store Notes documents and edit them. In order to do so, we of course need some kind of navigation structure and a view. Generally, you follow the process like this:
- Create a view to spit out XHTML compliant markup for the document entries. This is a piece of cake. Look at the demo database for an example
- Create a viewtemplate form and set the content type to text/html
- Embed the HTMLHeader and CommonFields subforms on top of the viewtemplate
- Insert the XHTML markup you need to lay out the page
- Embed the view you just created
- End the markup for the page layout
To navigate to pages within views, something you would usually do with the @Command( [NavigatePrev] ) command maybe, we need to mimic this behaviour ourselves. A previous blog entry explains this. In the demo database this is implemented in the ViewNavigator subform.
Limitations
Now that we had an inside look in the process of creating a Domino XHTML web application, it is time to consider the limitations. These are the ones I came across:
- It is impossible to search a view using the Domino ?searchview&query= URL command. Domino sees this as a trigger to put the HTML-only viewtemplate form into edit mode. This will generate an error since documents treated as HTML cannot be edited. Only alternative there seems to be is to make your search views native Domino i.s.o. HTML-based or to create an agent to search for you and spit out HTML.
- I tried hard, but I did not succeed in mimicing a file upload control. I think it is possible, it's all about giving it the correct name, but it is quite mysterious how Domino usually generates it.
- You will have to give up some @Commands and mimic them yourself. This is almost always possible.
- A complete separation between content and representation, if used wisely
- Full control over the markup server to the browser
- Markup that is readable by both humanes and machines, since it is simply XML
- When used wisely, pages will be very light and clean, since all or most control over the look & feel is defined in the stylesheet
- A web application that is based on forward-thinking standards. This ensures your application will keep working in all future browsers. Realistically, this is obviously dependant of browser bugs
- Get acquainted with structured markup to be ready for the future
- A good, warm feeling inside
- And more...
Conclusion
There is many advantages to making your web application XHTML-compliant. Doing this in Domino is not a 100% straightforward though, and you should always consider the limitations before doing it. In a business situation, you might wanna plan a little extra time to cover the extra work you need to do. However, when the limitations are no showstoppers to you, it isn't even that much work to do it. If you're already a control freak and use pass-thru HTML a lot, it will be simple even. Realize that in the long term everybody will be doing it, regardless of the platform and how much it already does or doesn't do for you. If you can't do it in your particular situation, at least keep in mind that it is possible. I hope this article will be a guideline for you when the time is ready for you.
Resources
- Online demo database - Try it online!
- Download demo database - Look under the hood
- XHTML 1.0 reference - Essential markup explained
- W3 XHTML validator - You can't develop without it
PS: The demo database holds all kinds of other Domino web techniques, such as validation, stylesheets, naming conventions, etc. Feel free to peek around and use it to your advantage.
Comments: 32
Reviews: 14
Average rating:
Highest rating: 5
Lowest rating: 4
COMMENT: LAURENS
JUN 26, 01:00:13
Some observations, which may be just the preferences you have:
- the $$NavigatorTemplate form seems to be the same as the $$ViewTemplate form. You could possibly delete one and name the gave the name as an alias to the other
- there is a rather large formula in the second to create the html in the view. You could create a field that calculates all this html on the ContactFields subform, thus making the view faster.
I think you should post this on Codestore as the perfect starting point for any new webdatabase! «
COMMENT: FERDY CHRISTANT
JUN 26, 18:27:54
Good feedback on the design too, I'll see if I can fit these optimizations in. «
COMMENT: BERNARD DEVLIN
JUN 30, 20:52:18
COMMENT: WOLFGANG FLAMME
JUL 8, 16:40:05
well done. definitely a reference to keep.
Btw: To tidy up one's HTML one might use this little helper:
http://www.sns1.de/partner/flamme/wflamme.nsf/.
The article is in german but the principle is obvious. «
COMMENT: WOLFGANG FLAMME
JUL 8, 17:26:58
COMMENT: CHRISTOPHER BYRNE
JUL 20, 17:03:54
This article and sample DB will be a great asset.
The only thing I am not comfortable is making tags lowercase. I always use uppercase to make it easier to distinguish code from content in my HTML. I am going to have to ponder this a bit. «
COMMENT: FERDY CHRISTANT
JUL 20, 19:45:37
COMMENT: BERND HORT
AUG 5, 09:17:20
But there is a point I have to mention. Computed subforms are real performance killers. For the "action" subform I don't have any other suggestion, but in the contact form all other computed subforms have static content. So why not using normal subforms? «
COMMENT: FERDY CHRISTANT
AUG 6, 09:35:48
COMMENT: MARCUS
SEP 8, 16:08:05
thanks again. «
COMMENT: RON DERKSEN
SEP 16, 15:41:41
We create many websites where the content is entered in rich text fields. The only way to create valid XHTML from this is by using the Midas Rich Text LSX from Genii Software. This is a pretty expensive tool, but it seems to work very well. If you don't use it, the HTML generated by Notes will 9 times out of 10 break your layout. «
COMMENT: DON
NOV 18, 12:13:21
Just thought to share my experiences on RT-Fields:
During rebuilding our company website I tried to use the techniques in this article combined with the excellent "Domino Rich Text In The Browser" article (http://www.codestore.net/store.nsf/unid/EPSD-65GGMX?OpenDocument) by Jake Howlett and found some limitations using the HTMLarea JS libraries.
Domino will not render RichText fields into tags (intentionally - we must avoid Dominos FORM rendering edit mode for full W3C compliance) when used with "Content type=text/html", which seems to make saving the HTMLarea content into a RT-field impossible.
After a full day of struggeling with all sorts of hidden input fields, web query save agents and JS, I found a simple solution which works like a charm.
I'm not finished yet with all the CMS work, but this could also guide the way towards a combined Notes/Webclient CMS.
If anybody likes to know how, I will offer the raw NSF file and some comments, just let me know. «
COMMENT: FERDY
NOV 18, 18:27:58
COMMENT: BEN LAMPARD
JAN 31, 02:23:33
COMMENT: DON J
FEB 20, 22:10:55
COMMENT: LILJA LÄNSISALO
JUN 20, 09:20:45
But there's a huge problem, when user tries to submit data with scandivavian characters (ä, ö, å ) - they are not converted correctly, but rather randomly (leaving some characters totally out of the data, depending on the position of the caracter on the string and how many of those characters are in the string one after an other).
If there is a solution for this, I would be more that interested :) ! «
COMMENT: LILJA LÄNSISALO
JUN 20, 09:24:47
(The feedback also converted them incorrectly :( ... ) «
COMMENT: ANDREW POLLACK
OCT 4, 17:17:28
I want to caution you – or more specifically your readers – however, on overestimating the need to do these things. I’d had to see someone convert existing databases at great expense and time expecting benefits they’re unlikely to see. Like all things, there is a time and place.
Let me draw your attention to a couple of fallacies that may shed some light on this. The key one is that XHTML is a “true standard” and “html” is not. Readers should understand that HTML derives from markup languages that pre-date XML as a common tool. It is a subset of printing standards. It was not designed as a flawed XML. In fact, XML came about because the benefit of a common markup language was obvious with the growth of HTML, but a markup language itself wasn’t rigid enough for good data interchange. That’s why they LOOK THE SAME – which has turned into a belief that they should be the same.
XML is an expensive but flexible way to store raw data with little or no loss of integrity between disparate systems. HTML, on the other hand, is simply a formatting language designed to allow the visual & interactive reproduction of content (not data). The difference is significant.
If your pages need to be machine readable for some process, XHTML is great. Better, would be to create separate true XML pages for the machines to read –perhaps as web services so they can be defined with WSDL. If your pages are read by humans and search engines, HTML is just fine.
This is particularly important for people who thing using XHTML will gain them better results on search engines. Everyone has theories and books about how to score better on search engines. The search engine programmers, however, go to great lengths to avoid being trapped by such tricks. The best way to get good results on search engines, is to write good content at length; use your alt= tags on images and iframes, make sure to use your heading tags, title tags, and list item tags instead of just changing fonts and adding bullet icons, and link to other useful content. A small number (that’s key, by the way) of very specific Meta tags describing the content can help – but only if they are few in number and very specifics. Date stamps which accurate show creation and useful life dates are also valuable – ever changing date stamps will not work, however. Anything else is a waste of time from that perspective. In short – create good, honest content.
Andrew Pollack
President, Northern Collaborative Technologies
http://www.thenorth.com
andrewp@thenorth.com «
COMMENT: ANDREW POLLACK
OCT 4, 17:25:04
Domino is backward compatible. Its a golden role. If someone worked in one version, it must continue to work after upgrade. If it was broken in the way it worked in one version, it must continue to work the same way in future versions unless that broken-ness is a security problem, or something that simply fails to work at all. Some call thsi "bugward" compatibility.
We all benefit from this in not having massive rip and replace projects just to upgrade servers. The downside of course, is that it makes adoption of new methodologies tricky. I know many of the developers I've spoken with to be frustrated with this requirement even as they understand its value.
Its easy to jump on every latest thing if you don't have a hundred million people counting on you not to break their existing investments. A little trickier if you need to easily bring people from version to version without nightmares of re-programming.
-- Andrew Pollack
President, Northern Collaborative Technologies
http://www.thenorth.com
andrewp@thenorth.com «
COMMENT: BOB FIT
OCT 4, 17:25:28
COMMENT: FERDY
OCT 4, 19:20:49
Bob, in fact...I always mimic the refresh fields on keyword change feature on the web, also when I'm building non-XHTML web apps. The reason is that I don't like the fact that this feature triggers a round trip to the server when the user changes the selection, which is of course slow. The technique I use is to preload all possible selection options in a javascript array. Next when the user changes the selection, I load the correct sub values from the array, which is fast as lightning «
COMMENT: MASSIMO AZZOLINI
OCT 21, 16:12:26
1. create an hyperlink in any way to :
//MyForm?readForm&query=&db=&view=
2. it will open the form in read mode, so you can create the form MyForm using XHTML tecniques used by Ferdy
3. in QueryOpenAgent call the agent: MyOpenAgent
4. Create the agent MyOpenAgent:
Sub Initialize
On Error Goto getError
Dim s As New NotesSession
Dim doc As NotesDocument
Dim db As NotesDatabase
Dim view As NotesView
Dim vc As NotesViewEntryCollection
Dim entry As NotesViewEntry
Dim item As NotesItem
Set doc = s.DocumentContext
vista = Evaluate(|@left(@right(query_string; "&vista=");"&")|, doc)
query = Evaluate(|@left(@right(query_string; "&query=");"&")|, doc)
stringa = Evaluate(|@left(@right(query_string; "&stringa=");"&")|, doc)
databs = Evaluate(|@right(query_string; "&database=")|, doc)
Set db = s.GetDatabase("",databs(0))
Set view = db.GetView(vista(0))
Dim cols List As Integer
iCols = 0
Forall c In view.Columns
If Not c.isHidden And Not c.IsCategory Then
cols(iCols) = iCols
End If
iCols = iCols + 1
End Forall
Set vc = view.AllEntries
' some dirty stuff removed
aa = Replace(query(0),"%5B","[")
aa = Replace(aa,"%5D","]")
aa = Replace(aa,"%20"," ")
aa = Replace(aa,"2C+","")
Call vc.FTSearch(aa,0)
Set entry = vc.GetFirstEntry()
i = 0
While Not entry Is Nothing
i = i + 1
Forall colNumber In cols
ris = ris & entry.ColumnValues(colNumber)
End Forall
Set entry = vc.GetNextEntry(entry)
Wend
Set item = doc.ReplaceItemValue("Ris",ris)
Set item = doc.ReplaceItemValue("Total",i)
Set item = doc.ReplaceItemValue("QueryView",stringa)
Exit Sub
getError:
Msgbox "getError" & Error & Erl
Exit Sub
End Sub
Ris, Total, QueryView are ComputedForDisplay text fields.
we developed the following solution for the XHTML problem. It can be evolved and completed. It's just a beta release.
1. create an hyperlink in any way to :
//MyForm?readForm&vista=&query=&stringa=database=
vista is the view name
query ....
stringa a human readable conversion of the query (optional)
database ...
2. it will open the form in read mode, so you can create the form MyForm using XHTML tecniques used by Ferdy
3. in QueryOpenAgent call the agent: MyOpenAgent
4. Create the agent MyOpenAgent:
Sub Initialize
On Error Goto getError
Dim s As New NotesSession
Dim doc As NotesDocument
Dim db As NotesDatabase
Dim view As NotesView
Dim vc As NotesViewEntryCollection
Dim entry As NotesViewEntry
Dim item As NotesItem
Set doc = s.DocumentContext
vista = Evaluate(|@left(@right(query_string; "&vista=");"&")|, doc)
query = Evaluate(|@left(@right(query_string; "&query=");"&")|, doc)
stringa = Evaluate(|@left(@right(query_string; "&stringa=");"&")|, doc)
databs = Evaluate(|@right(query_string; "&database=")|, doc)
Set db = s.GetDatabase("",databs(0))
Set view = db.GetView(vista(0))
Dim cols List As Integer
iCols = 0
Forall c In view.Columns
If Not c.isHidden And Not c.IsCategory Then
cols(iCols) = iCols
End If
iCols = iCols + 1
End Forall
Set vc = view.AllEntries
' some dirty stuff removed
aa = Replace(query(0),"%5B","[")
aa = Replace(aa,"%5D","]")
aa = Replace(aa,"%20"," ")
aa = Replace(aa,"2C+","")
Call vc.FTSearch(aa,0)
Set entry = vc.GetFirstEntry()
i = 0
While Not entry Is Nothing
i = i + 1
Forall colNumber In cols
ris = ris & entry.ColumnValues(colNumber)
End Forall
Set entry = vc.GetNextEntry(entry)
Wend
Set item = doc.ReplaceItemValue("Ris",ris)
Set item = doc.ReplaceItemValue("Total",i)
Set item = doc.ReplaceItemValue("QueryView",stringa)
Exit Sub
getError:
Msgbox "getError" & Error & Erl
Exit Sub
End Sub
Ris, Total, QueryView are ComputedForDisplay text fields.
To do asap:
- Ris has the 32K limit. We have to complete the manage of this issue.
- Test it on a huge database.
- manage a search limit
- etc.
Thanks to Ferdy for his work, I hope this helps too.
bye
Max
Authors:
me and Andrea Baglioni «
COMMENT: MASSIMO AZZOLINI
OCT 21, 16:17:26
the cut & paste... traitor!
and the first point has been partially truncated:
1. create an hyperlink in any way to:
/db.nsf/MyForm?readForm&vista=viewname&query=query&stringa=stringadatabase=dbpath «
COMMENT: JEFF SCHWARZ
MAY 11, 08:56:12 PM
Thanks,
-Jeff «
COMMENT: FERDY
JUN 20, 08:39:14 PM
COMMENT: PATRICK
NOV 19, 08:43:14 PM
Thanks Ferdy! «
COMMENT: PATRICK
NOV 19, 08:59:10 PM
Here's how I changed the computed value of the Action field:
command := @Subset(@UrlQueryString; 1);
tmpQueryString:= @LowerCase(command);
@If(
tmpQueryString = "readform"; "new";
tmpQueryString = "opendocument"; "edit";
"read"
) «
COMMENT: JUAN
NOV 27, 12:41:05
Your code is great, and solve a lot of problems in my office. Just one thing, use the upload file control is very simple. You only have to write down the correct name and this is dbreplicaid.formreplicaid.$body.0.@unique . This works for me.
Best Regards from Spain, and sorry for my english!
«
COMMENT: SG
MAY 19, 2008 - 04:25:11 AM
Any idea, how do we do a 'refresh' that will just re-compute the Notes fields in the current XHTML form (this isnt any submit/save/create action) and reload the same document (unsaved yet) with the new values? «
COMMENT: LUCA
NOV 25, 2008 - 14.13.55
How add file upload control? «
COMMENT: LUCA
NOV 25, 2008 - 14.17.53
How add file upload control «
COMMENT: KSB
DEC 10, 2008 - 08:20:38 PM