Special

Special Print Closeout!

We're clearing out the remainder of our print issues at fire sale prices -- as much as 75% off! Quantities are extremely limited and only available while supplies last. Hurry to take advantage of this one-time offer.

RBD Magazines

Once these printed back issues are gone, they are gone!

Article Preview


Buy Now

PDF:

Yuma Development

Validating Form Posts

Accepting a user's submitted data

Issue: 6.6 (September/October 2008)
Author: Brad Weber
Article Description: No description available.
Article Length (in bytes): 5,931
Starting Page Number: 54
RBD Number: 6620
Resource File(s):

Download Icon 6620.zip Updated: Monday, September 1, 2008 at 2:44 PM

Related Web Link(s):

www.YumaDev.com

Known Limitations: None

Excerpt of article text...

There are countless reasons to collect data from site visitors in web forms-- blog comments, e-commerce check-out, user registration, and more. You'll typically need to validate users' submissions and redisplay the entry form repeatedly until the content is acceptable. I'll show you how to accomplish that in a simple form and throw email notification into the mix so we can explore more of the Yuma framework. Note: The complete page content is available later in the article for your reference. We need to create a simple user registration form to access our password-protected frozen custard recipe site. Users will submit an email address, password, and favorite flavor. The favorite flavor value is optional. The other two will be required. The process will work as follows: 1. Display an empty registration form when the user first visits the page. 2. The user will submit registration values by clicking a submit button. 3. The posted values will be validated. If the values are valid, send a confirmation email message and redirect to a success page. If the values are not valid, redisplay the form with the flawed submitted values in the form fields so the user can see what she submitted and doesn't have to retype everything. In the HTML, the form opens with this tag: <form action="./FormValidation.yuma" method="post"> That form tag instructs the browser to post submitted values to the same page where the form is displayed. So I need to add code to the page that will process the form submission. Although you can insert that code anywhere you'd like, I recommend adding it at the very top of your Yuma page, even before the HTML DOCTYPE tag: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html>... In other languages like PHP, it is necessary to handle page redirection before any text (HTML, etc.) is sent to the browser. Although that is not the case in Yuma (you can send redirection instructions anywhere in your page), it's not a bad idea to keep your form processing at the top of the document. PostParams is a dictionary that is automatically instantiated and populated by the Yuma server with form post data for each request. The ".Lookup" method on the Dictionary class allows you to request a value by key name. However, if the key is not found in the dictionary, a default value you pass as the second argument will be returned. This is really handy for our form processing. The form will most likely be first displayed as the result of a GET request (clicking some link on the site). So the PostParams dictionary will be empty, and all of the following variables will be initialized with an empty string. <?yuma dim emailAddress as String = PostParams.Lookup("email", "").Trim dim password as String = PostParams.Lookup("password", "").Trim dim flavor as String = PostParams.Lookup("flavor", "").Trim ... ?> However, when the user submits values in the registration form by clicking the button, the Yuma variables will receive those values instead. In this example, I'm only checking to make sure the email address value contains an "-at-" character and that passwords must be at least six characters long. In practice, you can use the RegEx class in the Yuma framework to perform much more sophisticated regular expression pattern matching to validate submitted values. Form validation code <?yuma ... dim validPost as Boolean if PostParams.Count > 0 then // Validate the submission validPost = true if InStr(emailAddress, "-at-") = 0 then validPost = false if password.Len < 6 then validPost = false end ... ?> We know that a form has been submitted if the number of key-value pairs in PostParams is greater than zero. If the submission is valid, we want to store the data, send a confirmation email message, and redirect the user to a "success" page on our site. For the sake of brevity, the database code has been omitted from this example. <?yuma ... if validPost then // Commit valid post values to the database here // ... // Send a welcome email message dim m as new EmailMessage m.AddRecipient emailAddress m.FromAddress = "Treats-at-SpankysFrozenCustard.com" m.Subject = "Welcome" m.BodyPlainText = "Enjoy the frozen treats!" dim sock as new SMTPSocket sock.address = "mail.SpankysFrozenCustard.com" sock.messages.Append m if sock.SendMessages then // Success end SetHeader("Location", "/Success.yuma") return end ... ?> That's all there is to the validation processing. But there is one last bit you'll want to add to your HTML form to keep your site visitors from cursing your name. "Sticky" web form field <input name="email" type="text" value="<?yuma print emailAddress ?>" /> When the form is first displayed as the result of a GET request, the value of emailAddress will be an empty string because there won't be a key-value pair for "email" in the PostParams dictionary. So the form field will initially be empty, which is what you want. But if the user submits a value in the email field, adding value="" as an attribute for your input tag, the user-submitted value will be echoed back to the form. That will save the user from having to retype all of the data in the form if they need to correct invalid data from a previously submitted form. The sample code does not populate the Password field with the previously submitted value so that you can see the difference in behavior. In Figure 2, you'll see the result of me submitting an email address of "brad" (invalid), a password of "password", and flavor of "chocolate". Notice that my email and flavor submissions are "sticky", and are echoed back to me when the form is redisplayed. Please visit www.YumaDev.com for product documentation, community discussion forum, and an occasional blog entry about Yuma development.

...End of Excerpt. Please purchase the magazine to read the full article.

Article copyrighted by REALbasic Developer magazine. All rights reserved.


 


|

 


Weblog Commenting and Trackback by HaloScan.com