Step by Step with Open Web Studio – Part 3

Alright, I’ve read the first two posts, I get the requirements and I even understand Fetch now, so let’s do this already!

Ok, I agree, let’s get started. At a high level, we’re going to be performing three steps to implement this feature.

1. First, we’ll need to add a bit of markup that will display the message to the user when the user name they’ve chosen is in use.
2. Then, we’ll need to add a bit of JavaScript that will send the request to the server and will display the message from the server on the page.
3. Finally, we’ll wire up the server side logic that actually checks the username’s validity and returns a message to the user if it is in use.

Step One: The Markup

Open the Administration page for your OWS module and click on the “Actions” tab. On line three of our OWS Configuration, double click the “No Query Template” and add the following into the <td> that holds the User Name elements:

This is going to be the container for the message returned when a username is already in use.

Here is line three of the configuration:

Here is the markup detail (note the final span is the only element we're adding):

Step Two: The JavaScript

Next, let’s drop a bit of JavaScript (leveraging our favorite library; jQuery) into our form as well. Just place this at the bottom of the same No Query Template under the registration table:

This wires up an event handler to the Username text box’s “blur” event – which fires when the text box loses focus, as when the user tabs away from the text box or clicks somewhere else on the page after having had the focus in the text box.

If there is a value in the text box, it will send the Ajax request to the server. If not, it will make sure the contents of the message span is blank.

Go ahead and finalize the changes to the No Query Template by clicking the “save” link at the bottom of the page.

Step Three: Handling the event on the server side

First, we want to add an “Else-If” after the “If” on line five of the OWS Configuration. Click the “Region – Register User Scripts” text on line five

Then click “Else-If” in the “Actions” tab of the ribbon.

You’ll see the new Else-If action created at the bottom of the configuration.

Click on the new “Else-If” and use the arrow keys or the directional buttons in the ribbon to move it so that it exists at the same level as the “If” statement on line five.

Once you have the new “Else-If” action in place, double click it to open the editor for the action. In the “Left Condition” text box, enter the following:

'[Action,Querystring]'

Select “=” for the comparison operator, and then enter the following for “Right Condition:”

'ValidateUsername'

Click save.

You’ve now successfully set the module up to recognize the Ajax request that will be sent from the server, now we just need to add the custom logic to execute when the newly created condition is met.

Putting the submitted user name into a safe place

Knowing that we want to query the database for the username that has just been filled out on the form, we need to grab that value that the user typed in and put it in a safe place before we send it to the database.

OWS provides us with the ability to take the value from the query string and put it into a variable that takes some common security precautions. This helps us to easily avoid various types of malicious input that could potentially be sent over on the query string. Safe handling of user inputted content is standard practice in web development, therefore putting these values into variables within OWS is standard practice.

To perform the variable assignment, select the Else If action that you created in the previous step and then click on “Variable” in the action section of the ribbon. Now that the variable action is placed under the Else If action, double click it to edit its properties.

• Variable Type should be set to QueryString
• Source should be set to UserName
• Target should be set to @UserName

Other than that, the defaults settings will suffice. You’ll notice that the variable has options already selected for protecting against SQL and HTML injection attacks.

Querying the database

Now that we know what value we want to look for in the database and can safely work with it, let’s query the database and find out if that username is actually being used.

Select the parent Else-If action that checks to see if we’re validating the username and click the “Query” button in the Actions section of the administrative ribbon. The query action lets us specify a SQL query and then allows subsequent actions to work with its results. Double click the query that has just been added.

• Set the name to GetUsername
• Set the SQL query to the following:

• Hit save

This SQL query will always return an integer value. The value will be 0 if the username is not in use. The value will be the ID associated with the username if it is in use. This allows us to easily check to see if the username is in use in a subsequent action by checking to the value to see if it is greater than zero.

Note that you may need to modify your SQL query if your DNN website is not using the default database owner. This query assumes the table is dbo.Users, but for example, if your database owner is "ian" your query should select from ian.Users.

Returning the message to the user

Now that we have retrieved the variable from the query string and have used it to query the database, let’s render the output to the user to tell them if the user name is in use.

Select the Else-If action we’re working with again, and click the Template button to add a new Template action inside of our Else If.

• Set the Template value to

  Detail (No Query)

• Set the Content to the following:

  {IIF, "[UserIdInUse,GetUsername] > 0", "Woops, this username is already taken!", ""}

There are three main things to explain here.

1. First, we just added a "No Query Template” which is essentially a space for us to put content that is not (in contrast to other types of templates) associated with the previous query action. This effectively means we are using the template to indirectly display the results of our query.
2. Then, we’re using an IIF statement in our template, this allows us to test a condition which resolves to true or false, and render different values based on how that condition was resolved.
3. Lastly, we are using a token that will be resolved into the result of our SQL query:

   [UserIdInUse,GetUserName]

   The first part references the UserIdInUse column that the query returns and the second part references GetUserName, which is the name of the query in which that value can be found.

Double check! here is what the new section that we've added to our configuration should like:

Going for a test run

That’s it, our new feature is implemented! Try logging out of your DNN website and registering a new user with the module. If you enter a username that you already know to be used – what happens? You should see a message which tells you that the username is already in use.

Summary

As I had mentioned earlier in the series, there are plenty of things we could do to enhance this registration form, depending on what your requirements are we could go in a number of directions. Perhaps in the future the series will continue with new enhancements or revisions. Feel free to leave a comment and let me know what you think.

Finally, I’d like to give a special thanks to the OWS community member, adski, who contributed the original registration functionality on which we based our enhancement. Remember that if you ever have something to share with the community, there is a special section of the OWS forums where you can do just that.