DesignBais Tip – Launching a URL – Part 2, E-mail

Part 1 on Launching a URL provided details about how to launch a complex URL from a DesignBais form. In this Part 2 of 2 I’ll show you how to send e-mail from the user’s PC. The effect we’re looking for is a Click Here link which will launch the end-user’s email client, rather than sending mail from the server.

Overview

First, let’s discuss e-mail in general, and choosing the right methods and solutions. If you want to send email from your application, there are many ways to do it.

To send mail from the same system running the DBMS, you can use Windows- or Linux-based command-line utilities, or an MV-based product like NebulaMail (gratuitous advert). With DesignBais you can send email from the web server using the DBI.G.SENDEMAIL subroutine. As this article discusses sending from the client, that covers all three tiers.

Most applications will send mail from the server. Each tool works similarly, you provide some critical data like the TO address, the SUBJECT, and the BODY, call a subroutine and the mail goes out. But each tool has it’s own capabilities and limitations, and you need to choose which features you need vs which ones you can live without. Examples include:

• Ability to send HTML or Text depending on user preferences
• Ability to send HTML and Text, and ensure that any given email client doesn’t see the unused segment as an attachment.
• Ability to embed images.
• Ability to send attachments.
• Requirement to send attachments with a proper MIME type.
• Support for multiple To, CC, BCC, and Reply-To, each with a "friendly name" in addition to the actual e-mail address.
• Support for Organization and other headers.
• Ability to use an SMTP server rather than requiring a mail sending agent on the localhost (many mail servers these days reject mail that doesn’t come from "legitimate" servers)
• Does the server code need to be cross-platform compatible for a VAR that supports clients over multiple OS platforms?
• Are there firewall restrictions on specific sockets that can be opened?

For sending mail from the client, there are advantages and disadvantages to allowing a user to change data in e-mail before it gets sent. On the down side, your application has no control over the text once it’s sent from the server to the browser, and you’ll have no idea what numbers or comments actually got sent to the recipient. On the up side, the user isn’t restricted to sending a "canned" message from the server – they can personalize the content and formatting as they see appropriate, adding in their own custom signature, changing the format to HTML, adding attachments, etc.

It’s easy to see that for any given application there will be value to having different methods of sending mail depending on circumstances. If you run an end-user site, you can do your homework on the various options for each tier, and make a decision about what suits your needs. If you’re a VAR, deploying your GUI to different environments, you won’t know without some research exactly what each of your clients or prospects need. One size may not fit all, and you may have varied degrees of success convincing each site to send e-mail the way you think is best. I will suggest that resellers keep an open mind when someone says you’ll need a different e-mail solution if they’re going to buy your software. I’ll also mention here that you shouldn’t rely on being able to send e-mail from a client PC, which for some users may be an unacceptable security issue.

Sending e-mail from the client via a URL

Let’s discuss the following code, which will launch the user’s email client on their own PC:

TO.ADDRESS = "moc.niamodravnull@troppuS"
CC.ADDRESS = "moc.niamodymnull@nimda"
* ‘mailto:’ says "send mail" compared to
* ‘http:’ which says "launch a web page"
TAG = "mailto:"
SUBJECT = "I%27d%20like%20help%20with%20OrderStatus"
BODY = "My%20company%20is%20ccccc%2C"
BODY = BODY : "20my%20phone%20number%20is%20ppppp."
DBCALLURL = TAG: TO.ADDRESS
IF CC.ADDRESS # "" THEN
  DBCALLURL = DBCALLURL : "&cc=" : CC.ADDRESS
END
DBCALLURL = DBCALLURL : "?subject=" : SUBJECT
DBCALLURL = DBCALLURL : "&body=" : BODY

That produces the following text (resized and broken into lines for formatting:
mailto:moc.niamodravnull@troppuS&cc=moc.niamodymnull@nimda?
subject=I%27d%20like%20assistance%20with%20OrderStatus&
body=My%20company%20is%20ccccc%2C20my%20phone%20number%20is%20ppppp.

Links on this page will show you how to construct a valid mailto: link. Refer back to the DBCALLURL variable documented in Part 1, and note that the Subject and Body have been URL encoded, but the DBCALLURL variable itself must be HTML encoded with "&", which gets rendered as an ampersand (&) internally in the browser. Rather than hard-coding encoded text in your programs, or even calling to an encoding subroutine, I recommend creating a callable subroutine just for e-mail handling (just like the DBI.G.SENDEMAIL routine) so that you never have to worry about syntax, just pass the pertinent data, let some other piece of code deal with encoding, and just pass back a finished DBCALLURL variable.

You will probably put your code to build DBCALLURL into a Button event handler. The first image here shows the Form Designer with text and a Button field. It’s tough to see but you’re looking at one text field, a button, and then one more text field. This is because we can’t have a Text Only field with part of it clickable – either you have all text or you insert a button between text fields. The second image shows how these render together at runtime to look just like any other text in a browser with an embedded link. I did have to go to property settings a few times to get the column and colspan right for each field, and I decreased the row for the button/text by 2 pixels to get everything appearing with no apparent dip in the line of text. If you want to be real picky, note that I’m using display class = SearchLabel for the button, which renders with black text. The color of my Label style used for normal text is Navy (blue), so at run time someone may notice the trick I’m playing here (as if it matters) unless the style colors are changed to agree.

This code won’t immediately send mail from your user’s PC. Their email client will come up and show the text you’ve pre-provided (perhaps with account data, contact info, or other data from the DBMS. For better or worse as described above, the user will be able to modify the text before it gets sent.

This isn’t the only way to put a mailto: link into a DesignBais form. You can also use the technique described for client-side scripting and put a complete stream of HTML, as <a href="mailto:…">. You will still need to URL Encode the text but you won’t need to HTML encode the ampersand or other characters. The difference between the techniques is that here you know when the user clicked the link because you are handling the event, the browser is not. You can also dynamically generate the content for the e-mail at run-time. You may not have all of the data you need at the moment you are generating an IFrame field for a form. As usual, weigh the concerns for each situation and be prepared for someone to tell you it needs to change anyway.