Creating a dynamic, re-usable message form

Jake Howlett, 12 August 2001

Category: Quick Tips; Keywords: message confirm

Telling a user what they have just done may seem a little obvious and maybe even unnecessary. Imagine an application that never confirmed to the user that something had happened. They would soon get worried and confused.

The most common use of it is when a user submits a form and the application tells them "Thank you. Your form has been submitted." Without this simple message how does the user know the submit was successful!?

The problem:

The simplest way to communicate with the user after a form is submitted is to use the $$Return field or use the Print method from a WebQuerySave agent. The problem is that these two methods are limited. If your site has a layout and appearance that is the same across all pages like codestore then you don't really want to see something like this when you hit submit:

This is where we stop using $$Return and Print as the method of communication. Imagine trying to create the whole of the page's layout this way. Far too complicated!

The solution:

The obvious solution is to create a form that has the same layout as all the others and put the message in there. CodeStore has a form called "Message | msg" that does exactly this. The formula for the $$Return field for things like the Comment form are then:

"[/" + DBPath + "/msg?ReadForm]"

Where DBPath is the name of a field that stores the path of the database. Notice that we use ?ReadForm as there is no need to have the form in edit mode.

In the Message form we can then add the message amongst the layout of the form wherever we want it to appear. This approach also has its limitations. What do we do if we want to have different messages? We don't really want to have to create a form for each one. To get around this we can pass the message in via the URL like this:

"[/" + DBPath + "/msg?ReadForm&msg=Thank you. Your form has been submitted.]"

Then on the form in the place you want the message on the form add a Computed Text area with the following formula

"@Right(Query_String; "=")"

*Make sure you have a field called Query_String on the Message form.

An alternative method that doesn't lead to problems with encoding and decoding URLs is to have all the messages stored in a view. This is how CodeStore works. Each message has its own unique ID which is passed via the URL to the Computed Text which uses an @DBLookup to get the text for the message and display it. The formula for this is:

key := @Right(Query_String; "=");
@If(key = ""; @Return("No message key specified."); "");
view := "Messages";
msg := @DbLookup("": "NoCache"; ""; view; key; 2);
@If(@IsError(msg); @Return("Invalid message key."); "");
msg

The view "Messages" stores the Message documents and is sorted on the first column which displays the key. The second column shows the text of the message.

What would this all mean without an example... msg?ReadForm&msgid=example. Also, here is what happens when a user saves a comment and what happens if the message doesn't exist.