A Word About Spam

Before going any further I want to clarify that this module is not intended to send unsolicited e-mail newsletters, or messages of any kind, to users who did not request them. Many countries have laws against this, but regardless of the legality of doing this, I strongly believe that it hurts a site's reputation considerably to undertake this kind of action, and it ends up damaging the favorable impression that you've worked so hard to create. This newsletter system is only intended to send e-mail messages to users who have specifically opted in. Furthermore, users must be allowed to easily change their mind and stop any further e-mails from the site.

Creating and Sending E-msails

The System.Net.Mail namespace defined in the System.dll assembly contains all the classes used to send e-mails. The older System.Web.Mail namespace, and its related classes, that were used with ASP.NET 1.x are still there, but its use has been deprecated now in favor of these new classes in ASP.NET 2.0 that provide more features. The principal classes are MailMessage, which represents an e-mail message, and the SmtpClient class, which provides the methods used to send a MailMessage by connecting to a configured SMTP server (SMTP is the Simple Mail Transfer Protocol, which is the low-level protocol used by Microsoft Exchange and other mail servers).

MailMessage fully describes an e-mail message, with its subject, body (in plain-text, HTML, or in both formats), the To, CC, and BCC addresses, and any attachments that might be used. The simplest way to create an e-mail is using the MailMessage constructor, which takes the sender's address, the recipient's address, the mail's subject, and the body, as shown below:

MailMessage mail = new MailMessage(
   "from@somewhere.com", "to@somewhere.com", "subject", "body");

However, this approach will be too limited in most cases, because you may want to specify the sender's display name in addition to his e-mail address (the display name is what is displayed by the mail client, if present, instead of the address, and makes the mail and its sender look more professional). You may also want to send to more than one recipient, use an HTML body (as an alternative, or in addition, to the plain-text version), include some attachments, use a different encoding, modify the mail's priority, and so on. All these settings, and more, are specified by means of a number of instance properties of the MailMessage class. Their names should be self-explanatory, and some examples include the following: Subject, Body, IsBodyHtml, From, To, CC, Bcc, BodyEncoding, Attachments, AlternateViews, Headers, Priority, and ReplyTo. The class' constructor enables you to specify a From property of type MailAddress, Address, and UserName properties. The To, CC, and Bcc properties are of type MailAddressCollection and thus can accept multiple MailAddress instances (you can add them by means of the collection's Add method). Similarly, the MailMessage's Attachments property is of type AttachmentCollection, a collection of Attachment instances that point to files located on the server. The following example shows how to build an HTML-formatted e-mail message that will be sent to multiple recipients, with high priority, and that includes a couple of attachments:

// create the message
MailMessage mail = new MailMessage();
// set the sender's address and display name
mail.From = new MailAddress("mbellinaso@wrox.com", "Marco Bellinaso");
// add a first recipient by specifying only her address
mail.To.Add("john@wroxfans.com");
// add a second recipient by specifying her address and display name
mail.To.Add(new MailAddress("anne@wroxfans.com", "Anne Gentle"));
// add a third recipient, but to the CC field this time
mail.CC.Add("mike@wroxfans.com");
// set the mail's subject and HTML body
mail.Subject = "Sample Mail";
mail.Body = "Hello, <b>my friend</b>!<br />How are you?";

mail.IsBodyHtml = true;
// set the mail's priority to high
mail.Priority = MailPriority.High;
// add a couple of attachments
mail.Attachments.Add(
   new Attachment(@"c:\demo.zip", MediaTypeNames.Application.Octet));
mail.Attachments.Add(
   new Attachment(@"c:\report.xls", MediaTypeNames.Application.Octet));

If you also wanted to provide a plain-text version of the body in the same mail, so that the display format (plain text or HTML) would depend on the user's e-mail client settings, you would add the following lines:

string body = "Hello, my friend!\nHow are you?";
AlternateView plainView = new AlternateView(body, MediaTypeNames.Text.Plain);
mail.AlternateViews.Add(plainView);

Once a MailMessage object is ready, the e-mail message it describes can be sent out by means of the Send method of the SmtpClient class, as shown here:

SmtpClient smtpClient = new SmtpClient();
smtpClient.Send(mail);

Before calling the Send method, you may need to set some configuration settings, such as the SMTP server's address (the SmtpClient's Host property), port (the Port property) and its credentials (the Credentials property), whether the connection in encrypted with SSL (the EnableSsl property), and the timeout in milliseconds for sending the mail (the Timeout property, which defaults to 100 seconds). An important property is DeliveryMethod, which defines how the mail message is delivered. It's of type SmtpDeliveryMethod, an enumeration with the following values:

• Network: The e-mail is sent through a direct connection to the specified SMTP server.

• PickupDirectoryFromIis: The e-mail message is prepared and the EML file is saved into the default directory from which IIS picks up queued e-mails to send. By default this is <drive>:\Inetpub\mailroot\Queue.

• SpecifiedPickupDirectory: The EML file with the mail being sent is saved into the location specified by the PickupDirectoryLocation property of the smtpClient object. This is useful when you have an external custom program that picks up e-mails from that folder and processes them.

The delivery method you choose can dramatically change the performance of your site when sending many e-mails and can produce different errors during the send operation. If you select the Network delivery method, the SmtpClient class takes care of sending the mail directly and raises an error if the destination e-mail address is not found or if there are other transmission problems. With the other two methods, instead of sending the message directly, an EML mail file is prepared and saved to the file system, where another application (IIS or something else) will pick them up later for the actual delivery (a queue accumulates the messages, which means the web application will not have to wait for each message to be sent over the Internet). However, when using the second and third delivery methods, your web application cannot be notified of any errors that may occur during transmission of the message, and it will be up to IIS (or another mail agent that might be used) to handle them. In general, the Pickup DirectoryFromIis method is the preferred one, unless your ASP.NET application is not given the right to write to IIS mail folders (check with your web hosting provider service if you don't use your own servers).

If you set all SmtpClient properties mentioned above directly in your C# code, you'll have to recompile the application or edit the source file every time you want to change any of these settings. This, of course, is not an option if you're selling a packaged application, or you want to let the administrator change these settings on his own without directly involving you. As an alternative to hard-coding the delivery method, you can set it declaratively in the web.config file, which now supports a new configuration section named <mailSettings>, located under <system.net>, which allows you to specify delivery settings. The SmtpClient class automatically loads those settings from web.config to configure itself at runtime, so you should generally not set your delivery and SMTP options directly in your C# code. Following is an extract of the configuration file that shows how to select PickupDirectoryFromIis as the delivery method, set up the sender's e-mail address and the SMTP server's name (or IP address) and port, and specify that you want to use the default credentials to connect to the server:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
   <system.net>
      <mailSettings>
         <smtp deliveryMethod="PickupDirectoryFromIis"
            from="mbellinaso@wrox.com">
            <network defaultCredentials="true"
               host="vmwin2003" port="25"></network>
         </smtp>
      </mailSettings>
   </system.net>
   <!-- other configuration sections... -->
</configuration>

The SmtpClient's Send method used in the preceding code snippet sends the e-mail synchronously, which means that the task must complete before the execution of your application can resume. The term synchronous means "do what I asked, and I'll stop and wait for you to finish," and the term asynchronous means "do what I asked, but let me continue doing other work, and you should notify me when you're done." The SmtpClient class also has a SendAsync method to send the mail asynchronously. It returns immediately, and the e-mail is prepared and sent out on a separate thread. When the send task is complete, the SmtpClient's SendCompleted event is raised. This event is also raised in case of errors, and the Error and Cancelled properties of its second argument (of type AsyncCompletedEventArgs) tell you whether it was raised because the send was cancelled, because there was an error, or because the send completed successfully. Here's a sample snippet that shows how to send the mail asynchronously, and handle the resulting completion event:

SmtpClient smtpClient = new SmtpClient();
smtpClient.SendCompleted += new SendCompletedEventHandler(MailSendCompleted);
smtpClient.SendAsync(message, null);
...

public static void MailSendCompleted(object sender, AsyncCompletedEventArgs e)
{
   if (e.Cancelled)
      Trace.Write("Send canceled.");
   if (e.Error != null)
      Trace.Write(e.Error.ToString());
   else
      Trace.Write("Message sent.");
}

An asynchronous send operation can be cancelled before completion by calling the SmtpClient's SendAsyncCancel method. Note that you can't send a second e-mail while a SmtpClient has another send in progress; if you try to do so, you'll receive an InvalidOperationException.

Managing Long Operations on the Server

Because of the disconnected nature of the web, when you submit a form, you typically have to wait some time to get a response, and in the meantime you see nothing but a blank page. The browser can't check how the server-side processing is going, and it can't provide any feedback to the user. As long as the user only has to wait less than five seconds, that's normally fine. But if the application takes longer to produce a response, then you've got a problem because you can't leave users stranded without visual feedback for more than a few seconds, or they will start to think that the application got stuck, or had a serious problem, and they will close their browser and go away. If a user presses refresh to resend the data and restart the processing, that's bad as well, because that action actually requests the same operation a second time, and the server will do the same work twice, causing duplication and possibly data integrity problems. There are many situations where the server-side processing might take a long time to complete: you may execute long-running SQL queries, call an external web service, or forward a call to an external application (a payment processing application, for example) and wait for a response, and so on. In our case, you'll be sending potentially thousands of e-mails, and to do this you'll need to retrieve the profile for all registered members (that means multiple SQL queries), parse the newsletter's body and replace all the personalization placeholders, and insert the newsletter into the archive. This can possibly take many minutes, not just seconds! You can't expect your newsletter editor to look at a blank page for such a long period of time. In the previous edition of the book, we just set a much higher time-out for the page sending the newsletter, so that it wouldn't terminate with an error after the normal 90 seconds, but we didn't tackle the real problem: The page provided no feedback to the editor about the send progress, and this was a serious design flaw. In this new version we'll fix that flaw! Several techniques could be employed to solve this issue and provide some feedback to the user. Here is a list of some of the alternatives and their pros and cons:

• When users click the Submit button, you can redirect them to a second page that shows a wait message. When this wait page arrives on the client browser it uses some simple JavaScript, or the refresh metatag, to immediately post back to the server — either to itself or to another page. For example, the following metatag declared at the top of the page makes the current page redirect to processing.aspx after two seconds:

  <meta http-equiv="refresh"
  
  content="2; URL=http://www.contoso.com/processing.aspx">.
  

  After this second postback, the long processing task will be executed. While the task is running on the server, the current wait page will remain visible on the client. You can provide an animated gif representing an incrementing progress bar, in addition to the wait message, so that users get the idea that processing is taking place behind the scenes. This simple approach doesn't provide any real feedback about the task's actual progress, but it would suffice for many situations.

• When the user clicks the Submit button, on the server side you can start a secondary thread that will process the long task in the background. The page will then immediately redirect to a wait page that shows the user a message, while the real action continues on the server on that separate thread. The code executing on the background thread will also update some server-side variables indicating the percentage of the task completed, and some other optional information.

  The wait page will automatically refresh every "n" seconds, and every time it loads it will read the variables written by the second thread and display the progress status accordingly. To refresh itself, it can use some JavaScript that submits the form, or it can use the refresh metatag, but without the URL of the page to load, as shown in the following:

               <meta http-equiv="refresh" content="2">
  

  This approach can be quite effective, because it gives the user some real feedback about the background processing; however, with the page refreshing every few seconds, the user will continuously see the browser's content flickering. A better solution would be to load the wait/progress page into a small IFRAME, which would show only the progress bar and nothing else. When the processing completes, the wait page will not show the progress bar again, but will instead redirect the user to the page showing the confirmation and the results. Still, when the progress bar is updated, it will disappear for a short time when the page in the IFRAME refreshes, and this creates an ugly visual effect.

• The preceding option can be improved if, instead of refreshing the whole page or IFRAME, you just update the progress bar representing the processing status, and then use some JavaScript to call a server-side page that returns the required information, which uses this information to dynamically update some part of the page, such as the progress bar's width and the percentage text. The only disadvantage of this approach is that it requires JavaScript to be enabled on the client browser, but this shouldn't be a concern because all your users will likely have JavaScript enabled. Even if it were a problem, in our specific case the page requiring a real-time progress bar is only used in the administrative section, and thus it's not a problem to dictate some basic requirements (such as browser support for JavaScript) for your editors and administrators. Other than this small concern, this solution has everything you need: When the user submits the page, the page returns immediately and starts showing a progress bar that lets the user monitor how the long task is progressing in real time; in addition, you no longer have timeout problems because the page does almost nothing and completes instantaneously, while the background thread doing the real work can go on for a long time without problems.

Instead of showing you how to implement all three possible solutions, we will go straight to the best one, which is of course the third one. In the next section I'll provide you with some background information about multi-threaded programming and script programming for partial page updating, which you'll use in the "Solution" section to implement the newsletter delivery task.

// create and start a background thread
ThreadStart ts = new ThreadStart(Test);
Thread thread = new Thread(ts);
thread.Priority = ThreadPriority.BelowNormal;
thread.Name = "TestThread";
thread.Start();
// main thread goes ahead immediately
...

// the method run asynchronously by the background thread
void ExecuteTask()
{
   // execute time consuming processing here
   ...
}

// create and start a background thread with some input parameters
object[] parameters = new object[]{"val1", 10, DateTime.Now};
ParameterizedThreadStart pts = new ParameterizedThreadStart(ExecuteTask);
Thread thread = new Thread(pts);
thread.Priority = ThreadPriority.BelowNormal;
thread.Start(parameters);
// main thread goes ahead immediately

...

// the method run asynchronously by the background thread
void ExecuteTask(object data)
{
   // extract the parameters from the input data object
   object[] parameters = (object[])data;
   string val1 = (string)parameters[0];
   int val2 = (int)parameters[1];
   DateTime val3 = (DateTime)parameters[2];

   // execute time consuming processing here
   ...
}

private object lockObj = new object();
private int counter = 0;

void MethodFromFirstThread()
{
   lock(lockObj)
   {
      counter = counter + 1;
   }
   // some other work...
}

void MethodFromSecondThread()
{
   lock(lockObj)
   {
      if (counter >= 10)
         DoSomething();
   }
}

public static ReaderWriterLock Lock = new ReaderWriterLock();
private int counter = 0;

void MethodFromFirstThread()
{
   Lock.AcquireWriterLock(Timeout.Infinite);
   counter = counter + 1;
   Lock.ReleaseWriterLock();

   // some other work...
}

void MethodFromSecondThread()
{
   Lock.AcquireReaderLock(Timeout.Infinite);
   if (counter >= 10)
      DoSomething();
   Lock.ReleaseReaderLock();
}

void MethodFromThirdThread()
{
   Lock.AcquireReaderLock(Timeout.Infinite);
   if (counter != 50)
      DoSomethingElse();
   Lock.ReleaseReaderLock();
}

<%@ Page Language="C#" AutoEventWireup="true"
   CodeFile="Default.aspx.cs" Inherits="Default" %>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Test</title>

    <script type="text/javascript">

      function DoCalc(val)
      {
         var url = "multiply.aspx?val="+ val;
         var request = null;

         if (window.XMLHttpRequest)
         {
            request = new XMLHttpRequest();
            request.open("GET", url, false);
            request.send(null);
         }
         else if (window.ActiveXObject)
         {
            request = new ActiveXObject("Microsoft.XMLHTTP");
            request.open("GET", url, false);
            request.send();
         }

         if (request)
         {
            var result = request.responseText;
            alert(result);
         }
      }
      </script>
</head>
<body>
    <form id="form1" runat="server">
        <asp:TextBox ID="txtValue" runat="server" />
        <input id="btnSubmit" runat="server" type="button" value="Calc"
          onclick="javascript:DoCalc(document.getElementById('txtValue').value);"/>
    </form>
</body>
</html>

protected void Page_Load(object sender, EventArgs e)
{
   int val = int.Parse(this.Request.QueryString["val"]);
   Response.Write((val*2).ToString());
   Response.Flush();
   Response.End();
}

<%@ Page Language="C#" AutoEventWireup="true"
   CodeFile="Default.aspx.cs" Inherits="_Default" %>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Test</title>

    <script type="text/javascript">
      function ShowResult(result, context)
      {
         alert(result);
      }
   </script>
</head>
<body>
    <form id="form1" runat="server">
       <asp:TextBox ID="txtValue" runat="server" />
       <input id="btnSubmit" runat="server" type="button" value="Calc" />
    </form>
</body>
</html>

public partial class _Default : System.Web.UI.Page, ICallbackEventHandler
{
   protected void Page_Load(object sender, EventArgs e)
   {
      string callbackRef = this.ClientScript.GetCallbackEventReference(this,
         "window.document.getElementById('txtValue').value",
         "ShowResult", null);

      btnSubmit.Attributes.Add("onclick", callbackRef);
   }

   string callbackResult = "";
   
   public string GetCallbackResult()
   {
      return callbackResult;
   }

   public void RaiseCallbackEvent(string eventArgument)
   {
      callbackResult = (int.Parse(eventArgument) *2).ToString();
   }
}

<input name="btnSubmit" type="button" id="btnSubmit" value="Calc"
   onclick="WebForm_DoCallback(
      '__Page',window.document.getElementById('txtValue').value,
      ShowResult,null,null,false)" />

<script src="/ScripCallbackDemo/WebResource.axd?d=u8VFVkrxgbyFhFIpAniF-
Q2&amp;t=632671582519943712" type="text/javascript"></script>

<%@ Page Language="C#" AutoEventWireup="true" Async="true"
   CodeFile="AsyncDemo.aspx.cs" Inherits="AsyncDemo" %>

public partial class AsyncDemo : System.Web.UI.Page
{

private ecomm.OrderProcessor orderProcessor = null;

protected void Page_Load(object sender, EventArgs e)
{
   this.AddOnPreRenderCompleteAsync(
      new BeginEventHandler(OnPageBeginMethod),
      new EndEventHandler(OnPageEndMethod));
}

   IAsyncResult OnPageBeginMethod(object sender, EventArgs e,
        AsyncCallback cb, object state)
   {
      orderProcessor = new ecomm.OrderProcessor();
      return orderProcessor.BeginProcessOrder("order123", cb, state);
   }

   void OnPageEndMethod(IAsyncResult ar)
   {
      string result = orderProcessor.EndProcessOrder(ar);
      lblResult.Text = result;
   }
}

Designing the Database Tables

Now that we've covered all the background information, we can start the actual design for this module. As usual, we'll start by designing the database tables, then move on to design stored procedures and the data access and business logic layers, finishing with the presentation layer's ASP.NET pages and controls. The database design is very simple (see Figure 7-1). There's a single table to store newsletters that were sent out previously but were archived for future reference by online subscribers.

Figure 7-1

All fields are self-explanatory, so I won't spend time describing them, except to point out that Subject is of type nvarchar(256), while PlainTextBody and HtmlBody are of type ntext. The other fields, AddedDate and AddedBy, are common to all of the other tables, and we've discussed them in previous chapters.

The Stored Procedures

Because this module has only a single table, the stored procedures are simple as well. You just need the basic procedures for the CRUD (Create, Retrieve, Update, and Delete) operations:

As an optimization, the tbh_Newsletters_GetNewsletters procedure doesn't include the body fields in the resultset, because the body won't be shown in the page that lists the archived newsletters; only the AddedData and Subject are required in that situation. When the user goes to the page showing the whole content of a specific newsletter, the tbh_Newsletter_GetNewsletterByID procedure will be used to retrieve all the details.

Designing the Configuration Module

Like any other module of this book, the newsletter module has its own configuration setting, which will be defined as attributes of the <newsletter> element under the <theBeerHouse> section in web.config. That element is mapped by a NewsletterElement class, which has the following properties:

The first four settings are common to all modules. You may argue that the sender's e-mail address can be read from the built-in <mailSettings> section of web.config, as shown earlier. However, that is usually set to the postmaster's or administrator's e-mail address, which is used to send service e-mails such as the confirmation for a new registration, the lost password e-mail, and the like. In other situations you may want to differentiate the sender's e-mail address, and use one for someone on your staff, so that if the user replies to an e-mail, his reply will actually be read. In the case of a newsletter, you may have a specific e-mail account, such as newseditor@contoso.com, used by your newsletter editor.

The ArchiveIsPublic property has the same meaning as the similarly named property found in the poll module's configuration class — it enables the administrator to decide whether the archived newsletters can be read only by registered members; she may want to set this to True to give users another reason to subscribe. HideFromArchiveInterval is also very important, because it allows you to decide how many days must pass before the newsletter just sent is available from the archive. If you set this property to zero, some users may decide not to subscribe to the newsletter, and just go to the archive occasionally to see it. If you set this to 15 instead (which is the default value), they will have to subscribe to the newsletter if they want to read it without waiting 15 days to see it in the archives.

Designing the Data Access Layer

As usual, the DAL for this module is based on the provider model design pattern, and the SQL Server provider is included as an example, which is just a wrapper around the stored procedures described above. The DAL uses a NewsletterDetails custom entity class, which wraps the data of a single newsletter record. The diagram in Figure 7-2 describes the DAL classes and their relationships.

Figure 7-2

Designing the Business Layer

This is where things become interesting, because in addition to wrapping the data operations of the DAL in an object-oriented class, the MB.TheBeerHouse.BLL.Newsletters.Newsletter class also contains all the logic for sending out a newsletter asynchronously from a separate background thread, and for updating the progress status information. Figure 7-3 represents the UML diagram of this class (together with the usual Bizobject base class) and lists its public and private properties and methods.

Figure 7-3

When the user calls the SendNewsletter public static method, a new record is inserted into the tbh_Newsletters table, and the ID of the record is returned to the caller. Just before finishing the method, it spins off a new low-priority thread to asynchronously execute the SendEmails private static method. It's inside this method that the newsletter is actually sent to all subscribers, in plain text or HTML format according to their profile.

When the SendNewsletter method begins, it also sets the IsSending static property, so that the caller (from the administration page) can check whether another newsletter is currently being sent, to avoid calling SendNewsletter again before it has finished. As discussed previously, every time you access a property/field that's shared among multiple threads, you must synchronize this operation; and in this case it is done by means of the static field Lock, which is an instance of ReaderWriterLock. The Lock field is public because the caller will need to use the same ReaderWriterLock used by the business class in order for the synchronization to work properly. Note that the Common Language Runtime does not automatically handle locking, so if your code doesn't properly handle the synchronization, it could cause performance problems, occasionally lock-ups, and possibly even data corruption.

The TotalMails property is set from within the SendEmails method, before the first mail is set, and just after counting the number of site members having their Newsletter profile property set to a value other than SubscriptionType.None (this enumeration was defined in Chapter 4, when discussing membership and profiles). Every time SendEmails sends an e-mail, it also updates the SentMails and PercentageCompleted static properties, using the same synchronization approach based on the ReaderWriterLock.

Finally, as soon as SendEmails has sent the last e-mail, it sets IsSending back to false, so that the administrator can send another newsletter if desired. The SendEmails method uses the Has PersonalizationPlaceholders and ReplacePersonalizationPlaceholders methods, respectively, to check whether the newsletter's plain-text and HTML bodies contain personalization placeholders (the supported ones are <% username %>, <% email %>, <% firstname %>, and <% lastname %>, but you may add more if you wish), and to actually replace them for a given user. If HasPersonalization Placeholders returns false, the call to ReplacePersonalizationPlaceholders is completely skipped, to avoid running the replacement regular expression if you already know that no placeholders will be found. SendEmails calls HasPersonalizationPlaceholders just once for each of the two body formats, but it can save thousands of calls to ReplacePersonalizationPlaceholders, which is done separately for each user.

Designing the User Interface Services

The last part of the design phase is to design the pages and user controls that make up the module's presentation layer. Here is list of the user interface files that we'll develop later in the "Solution" section:

• ~/Admin/SendNewsletter.aspx: This page lets the administrator or editor send a newsletter to current subscribers. If another newsletter is already being sent when this page is first loaded, an error message appears instead of the normal form showing the other newsletter's subject and body, and a link to the page that displays that newsletter's progress. The page must also take into account situations in which no newsletter is being sent when the page loads, but later when the user clicks the Submit button to send this newsletter another newsletter is found to be under way at that time, because another user may have sent it from another location while the first editor was completing the form on her browser. In this case, the current newsletter is not sent and a message explaining the situation is shown, but the form showing the current newsletter's data is kept visible so that the data is not lost and can be sent later when the other newsletter has completed transmission.

• ~/Admin/SendingNewsletter.aspx: This page uses the script callback feature to update the statistics on the number of e-mails already sent (out of the total number of e-mails) and a progress bar representing the percentage of completed work. The lightweight postback will take place every couple of seconds, but you can change the update interval. The editor is automatically redirected to this page after she clicks the Submit button from SendNewsletter.

• ~/ArchivedNewsletters.aspx: This page lists all past newsletters sent at least "x" days before the current date, where x is equal to the HideFromArchiveInterval custom configuration setting. Anonymous users will be able to access this page only if the ArchiveIsPublic setting is set to true in the web.config file's <newsletters> element, under the <theBeerHouse> section. The list of newsletters will show the date when each newsletter was sent and its subject. The subject is rendered as a link that points to another page showing the newsletter's entire content.

• ~/ShowNewsletter.aspx: This page displays the full plain-text and HTML body of the newsletter whose ID is passed on the querystring.

• ~/Controls/NewsletterBox.ascx: This user control determines whether the current site user is logged in; if not, it assumes she is not registered and not subscribed to the newsletter, and thus it displays a message inviting her to subscribe by typing her e-mail address into a textbox. When the user clicks the Submit button, the control redirects her to the Register.aspx page developed in Chapter 4, passing her e-mail on the querystring, so that Register.aspx will be able to read it and prefill its own e-mail textbox. If the user is already a member and is logged in, the control instead displays a message explaining that she can change her subscription type or cancel the subscription by going to the EditProfile.aspx page (also developed in Chapter 4) to which it links. In both cases, a link to the newsletter archive page is shown at the bottom of the control.