Home > 2010 Winter BTI420 > BTI420 Lab 3

BTI420 Lab 3

February 1, 2010 Leave a comment Go to comments

Lab 3 helps you learn the Week 3 topics, by writing your own classes, a user control, and working with a master page. It is due by Monday February 8..

BTI420 Lab 3 – due Mon Feb 8

Assigned: During Week 3

Due date: Monday, February 8, 2010, at 11:00am

Grade value: 3% of your final course grade

Grading method: The following will be checked:

  • Your “labs/lab3.aspx” page
  • Correct interactive operation of the page’s logic
  • Implementation of the specifications



Write your own classes that model a real-life object

Write your own user control for modular functionality

Use a master page + content page structure

Get more practice creating an interactive web form / page

Use session state


Introduction to the problem that you will solve

You need a web form that will enable the user to create an instance of a Seneca “Student” object, fully configured with name and other identity information.

Additionally, your web app needs the ability to send email messages to recipients. (The sender will be the “Student” instance above.) You will create a user control, and then use it on your Lab 3 web form, and the user control will safely and successfully send email messages. This user control can then be re-used on your other web forms in the future.

Please note that all mail sending activity is logged on the warp server. The sender’s warp ID (e.g. “bti420_101a01”) is captured by the mail sending infrastructure, along with the date, time, computer IP address, and so on. Therefore, you cannot use this facility in a way that violates the College ITAUP (Information Technology Acceptable Use Policy).

Your Lab 3 web form will be interactive, dividing the work into three tasks:

  1. Gather information from the user, so that you can create a “student” object
  2. Display the gathered information
  3. Show an email-sending form, enable the user to send the email, and optionally to return to the first task

A working example of Lab 3 is here. You DO NOT have to exactly copy the appearance and functionality. Your lab MAY look and work a bit different.


Master page

This will be the first lab where you will use Master Pages. For this lab and future labs, you will use this master page. Create a master page layout with three horizontal regions:

  1. The top region, the header, will include information that identifies you (don’t include too much info!)
  2. The middle region will contain your actual Lab 3 content
  3. The bottom region, the footer, will include the current date and time, the content page address, and links back to your home page, and the course web site

Please locate your master pages in this folder of your web site: ~/ui/mp

The master page for your labs must be called “labs.master” (so I can find it).


User control

This will be the first lab where you will work with a User Control. The email form will be a user control, and it will be able to work with session state objects.

Please locate your user control in this folder of your web site: ~/ui/uc

The user control for this lab must be called “mailer.ascx” (so I can find it).


Visualizing the components of your Lab 3

For the student who is new to ASP.NET Web Forms programming, this Lab 3 is challenging. It has many moving parts. The following diagram will help to visualize the organization of the components, and their interrelationships.



Organizing the content page with three panel controls

As noted in the introduction, Lab 3 is interactive, with three distinct tasks. We recommend that you use ASP.NET Panel web server controls to organize your content page. You can show and hide (“Visible” property) each panel to meet your sequential processing needs.



The first task your web form must do is gather information about the person using the page, who will be the email sender. The information will include:

  • First name and last name
  • Birth date
  • Gender (male or female)
  • My.Seneca ID (i.e. the part of the College email address before the “at” (@) sign
  • The 9-digit numerical student ID number
  • Program of study (e.g. one of BSD, IFS, CPA, CTY, DAD)
  • Semester of study (e.g. 1 to 8 for degree programs, 1 to 6 for diploma programs, and 1 to 2 for the certificate program)

You will write some classes to represent the sender. There will be a base class called Person, which will represent a person (obviously). It will include name, birth date, and gender. A second class called Student, using Person as a base class, will add the student-specific members and functionality.

Person will have fields and properties for first name, last name, birth date, and gender. Student will have fields and properties to hold the rest of the information gathered. The following is a class diagram, which will help you visualize their organization. (In the Person class, the properties were auto-implemented. The Student class used backing fields. Your classes can be flexible.

Make sure you mark your classes with the [Serializable] attribute, so that instances of them can be persisted in session state.


When a sender first visits your web form, it will gather information, and verify its integrity using input data validation. Then, an instance of Student will be created, and will hold all of the gathered information.

The information-gathering part of the web form will be contained in a Panel web server control. After gathering the information successfully, and creating the Student instance, you will then to store instance properties in one or more label web server controls that are located in a second panel. The second panel then becomes visible, and the first panel becomes invisible.

The second task your web form must do is display the entered information. As noted above, the information will be contained as one or more label web server controls in a panel that is made visible after the first task has been successfully completed.

As just described, the contents of each label will come from the members of your Student instance. Yes, I know that you are simply shuffling data from one place to another, and that you really don’t need the class, but it is one of the requirements of this lab exercise.

The third task your web form must do is enable the user to send an email message, and optionally to return to the first task.

The email sending form must be implemented as a user control. This will enable you to improve it and re-use it in other web forms in the future, thereby saving you coding effort.

After the email message has been successfully sent, disable the fields on the email form, and disable (or hide) the “send” button. Then, provide a way to start over (maybe just a button with a Response.Redirect() method call).

Of course, your Lab 3 will have to handle errors (exceptions) gracefully at all times. Therefore, use input data validation and exception handling to make this a reality. Choose your controls wisely – if we are allowing only five specific “programs of study” (i.e. BSD, IFS, CPA, CTY, DAD), then DO NOT provide a textbox for user entry. Instead, provide a list control.


Using session state for persistence

After you gather the “new student” information in step 1, save the resulting “Student” object in session state. This way, you can pull it out later if or when you need to. Remember – when you create an object in your code, and the object isn’t persisted on a visible web form control, it simply will not be there after a postback.

In the example Lab 3, you can see that the “From” address was filled out with the student’s email address, which was composed of their My.Seneca ID and a string (@learn…). The Message body was also filled out, by extracting the properties from the student object.

Therefore, use session state to also save the strings that the user control will need. See the next section for advice on a naming convention for the strings you save in session state.


Code design for the user control

When the user control loads (i.e. when its Page_Load method runs), it should attempt to pre-fill the email form textboxes.

Where does it get the data? Session state.

We will need strings for the from, to, and cc addresses. We’ll also need strings for the subject and message body. These strings will be set at the end of either step 1 or step 2 above.

We suggest that you use a very specific naming convention for the session state objects that the user control needs. Use these names:

  • Mailer.FromAddress
  • Mailer.ToAddress
  • Mailer.CCAddress
  • Mailer.Subject
  • Mailer.MessageBody

To review, the code to save a string in session state looks like this example (which could be in the content page’s step 1 or step 2 postback handler code block):

Session[“Mailer.FromAddress”] = stu.MySenecaID + “@learn.senecac.on.ca”;

And, the code to get a string from session state looks like this example (which could be in the user control’s loading code block):

tbFrom.Text = (string)Session[“Mailer.FromAddress”];

You should test for null values. If there’s a null value, then decide what to do (for example, you may just want to initialize the textbox with an empty string).


If you decide to set the strings at the end of step 2…

You may remember the Week 3 (lab period) discussion about the event sequence in a master page + content page + user control scenario. If not, look at the “Week 03 Jan27 7 EventSequence” code example before continuing.

The important part is this: When you cause a postback from the content page, the processing event sequence is as follows:

  1. Content page’s Page_Load runs, then…
  2. Master page’s Page_Load runs, then…
  3. User control’s Page_Load runs, then…
  4. Content page’s cause-of-postback runs

If you save the email-related strings in the step 1 postback code block, then they will be available when the user control appears after step 2.

However, if you save the email-related strings in the step 2 postback code block, then they will not be available. Why?

Look at the sequence. In #3 above, the user control configures itself. It doesn’t have the data then. The data is actually saved to session in #4 above.

So, to address this, you can either save the email-related strings in the step 1 postback code block, or do some extra work for it to work with the step 2 postback. What work?

  • Create a public method in the user control, and move the code to get the strings from session state into this code block
  • Call this code block from the user control’s Page_Load method
  • Also, call this code from the step 2 postback handler

It’s easier to save the strings in the step 1 postback code block, so we recommend that you do that.


Validation problems?

In step 1, you will use validation controls to improve the quality of data that comes into your app.

In step 3, when using the email form, you will do the same. You will have some required field validators, and some regular expression (for email addresses) validators.

However, in step 3, you will also put a “restart” button or something in there to Response.Redirect() you back to the page, so you can start again.

The problem is this: Clicking the “restart” button, with empty/invalid data, will still cause validation to happen. You won’t be able to restart until you make the validators happy – unless you create a “validation group”…

Using a validation group

This bit of goodness will be configured in the user control (aspx markup or web form designer view). The technique can be used anywhere, however, in your other forms, and in your future work.

If you set the “ValidationGroup” property to the same string for a group of controls, then validation applies only to those controls. For example, in the Lab 3 example, the “ValidationGroup” property was set to “Mailer” for these controls:

  • Validation controls for all the textboxes
  • The “Send message” button

You’re welcome.


Submitting your work

Update your web site home page to add a link to this lab.

When you do a lab exercise, you are creating it online on the warp server. Therefore, you do NOT have to submit paperwork to your professor. Just do the lab, and your professor will find it (as long as it is in the right location!).

Note: As an experienced Seneca student, we expect you to be able to follow instructions. When your professor marks this lab, a helper “lab marker” program will browse to your home directory web app’s “default.aspx” page, and expect to find a hyperlink to “~/labs/lab3.aspx”.

Remember – this lab should be located at the URL:
http://warp.senecac.on.ca/xxxxxxxx/labs/lab3.aspx (where “xxxxxxxx” is your login ID)


Categories: 2010 Winter BTI420
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: