Creating a dynamic, re-usable message form - Article

Creating a dynamic, re-usable message form 12 August 2001

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.

Marcus
Fri 30 Nov 2001

Return Message

I get %20 between all the letters in my message. Is there a way to strip them other than a @Replace function?

Thanks

- Jake Howlett
- Fri 30 Nov 2001
Re: Return Message
Use the field called Query_String_Decoded instead
Jake

Brian Mucha
Wed 26 Apr 2006

Why do a Lookup? Just open the Message Doc itself.

"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."

I don't understand. You seem to say you open a Message form, pass it an ID in the QString to the doc that holds your desired message, to a Lookup to that doc (expensive!) to retrieve the actual message and display it in your message form.

Why not just make the form that holds all your messages look as you like, then open that doc DIRECTLY from the $$Return? That should be much faster. Just to show a nicer message if the doc isn't found?

IF you MUST do the lookup, how about doing to a PROFILE document and use @GetProfileField? That is also faster than a straight lookup.

« Previous Article		Next Article »
Confirming a user's action		Keeping your head nice and tidy

Creating a dynamic, re-usable message form 12 August 2001

Feedback

Return Message

Re: Return Message

Why do a Lookup? Just open the Message Doc itself.

Your Comments

Navigate other articles in the category "Quick Tips"

About This Article

Options

Let's Get Social

About This Website