Login
This action verifies that the user has introduced his/her correct login information. If so, it then places a cookie that will be later verified by the BeforeDispatch event. The cookie also holds the ID entry of the user. In this example we might not need this ID at all, but I'm placing it so that if you ever need information regarding the user, all you need to do is query the USER_LIST table given the ID and retrieve the necessary information.

Since most of the code has been explained in previous chapters, I won't go into details. The only really new thing is the Stored Procedure that checks to see if the user is valid. If the username/password is correct it then responds with the user's ID. All user ID's are greater or equal to zero, so if the user does not exist or the combination is incorrect it will return -1.

The "Page" action
Since the pages to access the application are in a private location (as intended), we need some way to access them. This is why we are going to create an action that returns a page requested. For example, before we can add a new record to the database we need to see the html form where we can fill in the information.

The BeforeDispatch event takes care of the security issues, so in our "Page" action all we need to do is to return the requested page that will be indicated by the "target" parameter (look at the source code for the menu.htm file). If you look at the code for this action you will see that it is very simple:

Note that the path to the private files is hard-coded. Other ways to do it is either using constants (but still would be coded) or use a INI file of some sort that would read the values from a the file in the OnCreate and store them in a global variable (remember, it would be ok since it would be a read-only variable). You could then easily change the paths without the need to re-compile.

Try calling this action without logging in first and see the result:. If you debug, you will see that it doesn't even get to the Page action. The BeforeDispatch takes care of it.

As you can see also, the errors and pages i've generating aren't what you could say the best or nicest. This is all for demonstration purposes and the error messages could be replaced with something more friendlier and less explicit!

The "Action" action
This is where it all takes place. First I want to start off by saying that normally I don't use strings as the target of the actions (i.e. AddRecord, DeleteRecord, etc). I prefer to use number in which case the whole lot of "if's" could be replaced by a much faster "case" sentence. However, so as not to be confused by numbers I thought it best to be explicit and use text to indicate exactly what action is going to be performed. In this part of Chapter 11 we will only focus on the "addrecord" target.

We call the function "AddRecord", which reads the contents of the form, creates an SQL instruction and executes it. If no exception is raised then it returns an 'OK' , otherwise it returns the message of the exception. Notice that there is no need to pass the Request.ContentFIelds as a parameter to the function since the current Request property of the web-module is instantiated with the current contents of the current request.

This was very easy. Examine the code carefully and make sure you understand everything before you proceed to the next part of this chapter.