administration mode
Pssst...Ferdy is the creator of JungleDragon, an awesome wildlife community. Visit JungleDragon

 

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:

Set the form content type property 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:

CommonFields Subform

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.
The computed subform is interesting here. It loads the correct subform based on the previously explained Action field, like this:

@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":

ContactFields subform

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:

  1. 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
  2. Create a viewtemplate form and set the content type to text/html
  3. Embed the HTMLHeader and CommonFields subforms on top of the viewtemplate
  4. Insert the XHTML markup you need to lay out the page
  5. Embed the view you just created
  6. 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.
Despite these limitations, XHTML-compliant web applications gives us the following:
  • 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...

xhtml demo screenshot


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

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.

Share |

Comments: 38
Reviews: 17
Average rating: rating
Highest rating: 5
Lowest rating: 4

COMMENT: LAURENS homepagerating

JUN 26, 01:00:13

comment » Love the extreme simplicity of your design of the demo database! So well structured, such a short code, so little fields. All the code is where you expect it. I was waiting for somebody to write an article like this, since it is hard to get rid of all the Domino generated code.

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 emailhomepage

JUN 26, 18:27:54

comment » Laurens, many thanks. I appreciate the compliments, this makes it worth it to write the article, or any article for that matter. If Jake is interested, I'm very willing to cooperate.

Good feedback on the design too, I'll see if I can fit these optimizations in. «

COMMENT: BERNARD DEVLIN homepagerating

JUN 30, 20:52:18

comment » Thanks for sharing this Ferdy. I mostly work alone, and it is always great for me to see how other Domino developers are doing stuff. I haven't aimed for XHTML compliance so far - I have enough problems getting cross-browser DHTML to work! I mostly use pages with computed text, and only use forms where I need them. I will surely look through your database to see what other techniques you are using. «

COMMENT: WOLFGANG FLAMME emailhomepagerating

JUL 8, 16:40:05

comment » Ferdy,

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 emailhomepage

JUL 8, 17:26:58

comment » Btw: I wish IBM/Lotus would finally overcome the 15kChar limit for text fields and concetenate multiple items as they did for Notes RichText... «

COMMENT: CHRISTOPHER BYRNE homepagerating

JUL 20, 17:03:54

comment » Absolutely, as Bruce Elgort states, a must read. I am in the process of changing my version of the Blogsphere code to be be XHTML and other things compliant (508(c)(3) for one).

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 emailhomepage

JUL 20, 19:45:37

comment » Thanks everybody for the appreciation of the article., Christopher,, (Un)fortunately XHTML is strict in case. I personally feel uppercase HTML tags are a bit loud, but I know lots of other developers who stick to it. , Pretty soon I will share my blog template. Then everybody will have insight in a more advanced XHTML Domino database I guess. «

COMMENT: BERND HORT emailhomepagerating

AUG 5, 09:17:20

comment » Thank you for the interesting article.

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 emailhomepage

AUG 6, 09:35:48

comment » Good point. I mainly use computed subforms to keep a clear overview in design mode. This way I get short forms that focus on what is dynamic, without seeing all the static content all the time. «

COMMENT: MARCUS rating

SEP 8, 16:08:05

comment » really, really nice article. very good stuff, and the demo database is worth its weight in gold. i definitely plan on using some of the techniques you've shown here.

thanks again. «

COMMENT: RON DERKSEN emailrating

SEP 16, 15:41:41

comment » Good article. One thing I'm missing however is a problem that I've run into while checking out the possibilities of creating valid XHTML pages: rich text fields.

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 email

NOV 18, 12:13:21

comment » Really good article!

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 » I like to know! «

COMMENT: BEN LAMPARD homepagerating

JAN 31, 02:23:33

comment » Great stuff Ferdy - thanks heaps for the article! I looked everywhere for a solution along these lines and couldn't find anything else.... Where did find out about this?? «

COMMENT: DON J rating

FEB 20, 22:10:55

comment » Great article!! Thanks... «

COMMENT: LILJA LÄNSISALO emailrating

JUN 20, 09:20:45

comment » Very nice :) !

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 email

JUN 20, 09:24:47

comment » The scndinavian characaters that are not working, are ä and ö ,etc.

(The feedback also converted them incorrectly :( ... ) «

COMMENT: ANDREW POLLACK emailhomepagerating

OCT 4, 17:17:28

comment » Ferdy, this is a terrific how-to article. I truly wish Domino did create its html using this closed tag methodology as there are some benefits – particularly when other programs need to parse a web page for specific details. More than this, I wish Domino would create more useful element class and id tags in some predictable and useable fashion. For example, if a required text field was generated, a class=”required textInput” attribute would go a long way toward allowing you to use CSS better. A class tag schema that identified table cells by row and column (with a notation for nested tables) would also help.

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 emailhomepagerating

OCT 4, 17:25:04

comment » -- by the way -- there's a reason why Domino doesn't output XHTML. You can decide if its a good reason or not. Its probably both.

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 » Interesting approach. How would you mimic the effect of 'refresh fields on keyword change'? Without domino fields you don't have this feature. Are you limited to saving the form and capturing the values in the domino field subform? Can you any kind of dynamic behaviour in your form? «

COMMENT: FERDY

OCT 4, 19:20:49

comment » Andrew, thanks for your comments. I completely agree that the effort to make a domino web app can be (too) large. I'm not preaching everybody should work the way described in the article, I'm merely showing it can be done, where others have said its impossible in the past.

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 homepage

OCT 21, 16:12:26

comment » 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&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 homepage

OCT 21, 16:17:26

comment » sorry,

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

comment » What does the Save button's QuerySave(this.form) link to? I don't see a QuerySave function in the form or anywhere in the db.

Thanks,

-Jeff «

COMMENT: FERDY

JUN 20, 08:39:14 PM

comment » Jeff, the QuerySave runs the validation routine of the form, which is written in Javascript. The routine you can find in the javascript script library in the design. This library is included in the HTML header. «

COMMENT: PATRICK emailrating

NOV 19, 08:43:14 PM

comment » I had been trying to figure out how to serve up compliant XHTML on a Domino 7 server for a while. Your article was exactly what I was looking for, and it was so easy to do. Now a bigger side project for me will be converting my company's website from the lousy HTML 4.01 Transitional to XHTML 1.0 Strict.

Thanks Ferdy! «

COMMENT: PATRICK emailrating

NOV 19, 08:59:10 PM

comment » In follow up to my previous post. While designing a database using these methods, I ran into a problem when the Action field computes it's value based on the URL if there are parameters in it, ie: ?ReadForm&parm1=one.

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 emailhomepage

NOV 27, 12:41:05

comment » Hi Ferdy!

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! 18 «

COMMENT: SG

MAY 19, 2008 - 04:25:11 AM

comment » Ferdy. Thanks for a very good article.

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

comment » can you tell me details

How add file upload control? «

COMMENT: LUCA emailhomepage

NOV 25, 2008 - 14.17.53

comment » JUAN, can you give me details ?

How add file upload control «

COMMENT: KSB

DEC 10, 2008 - 08:20:38 PM

comment » What have you found to be the easiest/best way to handle field inheritance from one Domino document into a new one (can't use the ParentUNID= parameter)? «

COMMENT: MIKE VANDEVELDE email

FEB 13, 2009 - 12:01:21 AM

comment » You *can* use the ParentUNID= parameter! It's just (still) not documented. See this posting:

http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/da2d6863c9ce1202852570f8006e1ce2?OpenDocument

12 «

COMMENT: SARAH rating

AUG 31, 2009 - 11:01:38 AM

comment » hello, thank you for this very useful article :) I am currently using it now -- I am super new to domino programming and this helped me a lot in developing my application. :) i do have a question though:

I now have several submission forms, submitting different sets of fields using the same process as you described. but since I am saving my document using the ?createdocument in the action part of the form, what happens is that i get redirected to the "home" page after clicking on the save button but i really want to NOT be redirected to the home page but rather, either stay on the same page (i.e., that form) or redirect to a thank you page. I thought that it is a simple form redirection like form onSubmit = "window.open(...)" or put an input type="hidden" name = "redirect" value = "". but none seems to work.

I really hope you could shed some light for me on this...thank you very much! your articles are really very helpful to me in beginning my programming in domino. I am used to relational databases, and more on java programming and i am having a hard time shifting to some domino concepts :( «

COMMENT: FERDY

AUG 31, 2009 - 06:48:54 PM

comment » Sarah,

Thank you for liking the article. You have full control over where a form gets redirected upon submitting it. In Domino, you need to create a field named "$$Return". Fill this field with the address you want to redirect to, between brackets, for example [http://yourserver.com/app.nsf/yourpage]

I hope this helps. «

COMMENT: SARAH

SEP 1, 2009 - 03:07:47 AM

comment » Thank you very much :) that's exactly what I needed to know. I hope you will be patient with me as I try working the ropes here...I'll try my best but I may need to ask a few more questions :) «

COMMENT: ROMANO rating

APR 1, 2011 - 03:44:55

comment » Supet! «

COMMENT: DAVID BENKO emailhomepagerating

MAY 10, 2012 - 02:43:40 PM

comment » Good article, the only caveat is that the content type for xhtml really should be 'xhtml+xml'. But other than that, very informative. «

RATE THIS CONTENT (OPTIONAL)
Was this document useful to you?
 
rating Awesome
rating Good
rating Average
rating Poor
rating Useless
CREATE A NEW COMMENT
required field
required field HTML is not allowed. Hyperlinks will automatically be converted.