Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Web Design & Development

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Understanding Page Properties

As I've said over and over and over and over again, ASP.NET is an object-oriented programming paradigm, and ASP.NET pages are no exception. They are objects, as well, and have properties and methods just like every other object.

Let's take some time to explore some of the key properties that the ASP.NET page object has. First, it is helpful to know where in the .NET Framework the Page object is. It is located in System.Web.UI. You can go there in the class browser that I mentioned in earlier chapters (http://www.gotdotnet.com) and investigate all the properties. In this book, however, we are going to cover the biggies, the heavyweights, the granddaddies. In other words, we're going to cover the ones that are used most commonly.

The Page object properties covered in this section are:

  • Application

  • IsPostBack

  • Request

  • Response

There are actually a few additional properties, such as Session and Validation, that are covered in other chapters and are pointed out as Page object properties then.

NOTE

If you come from a traditional ASP programming background, many of these probably look familiar to you. In traditional ASP, many of these ASP.NET Page properties were what made up the default objects in the language. You ask, "Why are they now properties of the page instead of remaining objects?" In reality they are still objects and can be found in the System.Web section of the .NET Framework. To simplify the use of objects, many properties of objects are really just instances of other objects. You will see this throughout the framework. Actually, just about every property is an instance of another object. For instance, any property that is a string is actually an instance of the System.String object. So properties in the .NET Framework are generally just instances of other objects.

Application

The Application property or HttpApplicationState object contains a collection of data that is available across the entire application during the life of the application. It is a shared variable among the users and is an easy-to-use place to store global information that will be needed across your application.

Setting an Application variable is a piece of cake:

Visual Basic .NET

Application("Publisher") = "New Riders"
OurLabel.Text = Application("Publisher")

C#

Application("Publisher") = "New Riders";
OurLabel.Text = Application("Publisher");

This would write the words "New Riders" to your browsers. You typically wouldn't go around setting an application variable all over the place every time a page loaded. Because it is an application-level variable, under most circumstances it really needs to be set only once during the life of an application. ASP.NET provides a way to set Application variables (in addition to many other things) within a file called the global.asax, which resides in the root folder of your application. On a web site, this is typically the folder that your domain points to, where your index or default home page is located. This example creates four application variables in the Application_OnStart event, which happens the first time a web page is requested from an application. This doesn't mean that web service on the server must be stopped and started if you make a change to anything in the Application_OnStart. ASP.NET is smart enough to recognize the change and reset the variable's value.

Visual Basic .NET—global.asax

<script language="vb" runat=server>
Sub Application_OnStart()
  Application("Publisher") = "New Riders"
  Application("BookTitle") = "ASP.NET for Web Designers"
  Application("Author") = "Peter"
  Application("Rating") = "5 Stars, WHAHOOO!!"
End Sub    
</script>

C#—global.asax

<script language="c#" runat=server>
void Application_OnStart(){
  Application["Publisher"] = "New Riders";
  Application["BookTitle"] = "ASP.NET for Web Designers";
  Application["Author"] = "Peter";
  Application["Rating"] = "5 Stars, WHAHOOO!!";
}  
</script>

Now, if you make a file that requests the application variables, you can see how they are retrieved.

Visual Basic .NET—page_application_vb.aspx

<%@ page language="vb" runat="server"%>
<script runat=server>

Sub Page_Load()  
  Title.Text = "<u>Title:</u> " + Application("BookTitle")
  Publisher.Text = "<u>Publisher:</u> " + Application("Publisher")
  Author.Text = "<u>Author:</u> " + Application("Author")
  BookRating.Text = "<u>Rating:</u> " + Application("Rating")
End Sub
    
</script>
<html>
<title>Application</title>
<body>
<asp:label id="Title" runat="server"/><br>
<asp:label id="Publisher" runat="server"/><br>
<asp:label id="Author" runat="server"/><br>
<asp:label id="BookRating" runat="server"/>
</body>
</html>

C#—page_application_cs.aspx

<%@ page language="cs" runat="server"%>
<script runat=server>

void Page_Load(){  
  Title.Text = "<u>Title:</u> " + Application["BookTitle"];
  Publisher.Text = "<u>Publisher:</u> " + Application["Publisher"];
  Author.Text = "<u>Author:</u> " + Application["Author"];
  BookRating.Text = "<u>Rating:</u> " + Application["Rating"];
}
    
</script>
<html>
<title>Application</title>
<body>
<asp:label id="Title" runat="server"/><br>
<asp:label id="Publisher" runat="server"/><br>
<asp:label id="Author" runat="server"/><br>
<asp:label id="BookRating" runat="server"/>
</body>
</html>

As you can see in Figure 4.5, the page requested these application variables and displayed them in the browser just as expected.

Figure 4.5 Application variables are a simple way to make routine and application- wide information available to you.

TIP

As I mentioned in Chapter 1, there is another file that can contain not only application variables but a ton of other information: the web.config file. This is an XML document that allows you to configure many elements of your web application and isn't limited to one file per application. You can add a web.config file to every folder in your application to set its configuration, rules, or variables. This file is a bit out of the scope of this book, but if you are looking for greater control over your application, the web.config file may be your answer. In addition, there are great performance advantages in using variables from within the web.config file over an application variable. You can learn more about configuring your web applications with the web.config file in the .NET Framework SDK at the following link:

ms-help://MS.NETFrameworkSDK/cpguidenf/html/cpconaspnetconfiguration.htm

IsPostBack

You saw the IsPostBack property mentioned in one of the earlier examples. This is an incredibly useful property that you will find yourself using all the time when you are processing forms.

As a matter of fact, this property is at the core of some of the most powerful features in ASP.NET and its pages. ASP.NET web forms are built on the concept of making round trips to the server. It's a simple property whose value is either true or false. The property is set to true whenever you post a page to the server with a runat="server" directive in the form tag. Form tags with runat="server" directives always post back to themselves. If you put an action property in the tag, it will basically be ignored.

This property is basically used, as I've said, to determine whether a page is being loaded for the first time or is being posted back to itself. Take a look:

Visual Basic .NET—page_postback_vb.aspx

<%@ page language="vb" runat="server"%>
<script runat=server>

Sub Page_Load()  
  OurTitle.Text = "No this page wasn't posted back"
  
  If IsPostBack then
    OurTitle.Text = "Yes this page has been posted back"
  End If
  
End Sub
</script>
<html>
<title>Was this page posted back?</title>
<body>
<form runat="server">
<asp:label id="OurTitle" runat="server"/><br><br>
<asp:Button id="PostBack" text="Post this Form?" runat="server"/>
</form>
</body>
</html>

C#—page_postback_cs.aspx

<%@ page language="cs" runat="server"%>
<script runat=server>

void Page_Load(){  
  OurTitle.Text = "No this page wasn't posted back";
  
  if (IsPostBack){ 
    OurTitle.Text = "Yes this page has been posted back";
  }
}  

</script>
<html>
<title>Was this page posted back?</title>
<body>
<form runat="server">
<asp:label id="OurTitle" runat="server"/><br><br>
<asp:Button id="PostBack" text="Post this Form?" runat="server"/>
</form>
</body>
</html>

You can see in Figure 4.6 that the first time you request this page, you are presented with the default message because the IsPostBack property is false on the initial load of that page, so the if branching statement doesn't execute its code.

Figure 4.6 The first time the page is loaded, the page's IsPostBack property is false.

Now what happens if you click the button and post the form? In Figure 4.7 you can see that after you post the form, the label's text value is changed because IsPostBack is now true and the if block executes.

Figure 4.7 Now that you posted the page. the IsPostBack property is true and the branching statement executes.

This technique will be used and demonstrated in abundance in later chapters, where you will be able to see it under many different circumstances. So hold your horses and don't get your undies in a twist.

Request and Response

I've always told people who ask me about the Internet that it's not a big mystical thing that can't be understood or pinned down. It's really very simple. It's a communication tool, just like a phone or even more simply a piece of paper and a pen. It's a way to say something to others and, thankfully, as dynamic languages have become so prolific, they can say stuff back and we can respond to what they said programmatically.

Picture two grandmothers sitting at a kitchen table enjoying a cup of tea and good conversation. The air is filled with the pleasing aroma of fresh baked apple pie so thick you can almost taste it.

    Ethel: "Bernice, do you want to see my latest masterpiece? It's a deep dish apple pie done to perfection."

    Bernice: "Certainly Ethel. Let me have a look see."

    Ethel gets up from the table and saunters over to the window sill where the golden brown pie sits. She carefully slides it off the sill onto her toweled hand and returns with the same grace to the table. She approaches Bernice and lowers it in front of her so the waves of succulent aroma waft up to her nose.

    Bernice: "Um Um!!!!! Can I have a piece of that?"

    Ethel: "You sure can."

    Ethel cuts and serves a slice of that delicious pie to Bernice, who proceeds to ravage it mercilessly. Whipped cream, crust, and apples fly as Bernice devours her prize. In between forkfuls, Bernice lifts her apple pie covered face and says:

    Bernice: "Can I have the recipe? This is delicious!"

    Ethel, also now covered in the remains of a once beautiful piece of apple pie from Bernice's frenzy, pulls the recipe from her recipe file and gives it to her dear friend...Bernice.

    —The End—

Okay, a little too dramatic for you? I'm sorry. Sometimes I get carried away. I have behaved quite professionally so far this chapter, and I though it was time to get silly again.

Anyway, the point of my dramatic depiction of Ethel and Bernice was to demonstrate communication and to give an example that shows a bunch of different types of requests and responses. Later we will try to programmatically reproduce this scene and help you see it in action. First, though, it's a good idea to look a bit more into the Request and Response properties of your ASP.NET pages.

Request

If you can think of the Request as a question mark, you will quickly and easily understand what it does in concept. It's similar to Bernice asking whether she can have a piece of pie or have a copy of the recipe. It's also good for finding out what the response was to a question we ask just like Ethel asked whether Bernice wanted to see the pie. We find out the condition of things being sent to the server with the Request.

As I said with the Application property, the Request and Response properties are both actually objects in their own right and can be explored in the class browser I redundantly mention.

You can get tons of data by using the Request object, and I covered a few of them here. There are a handful that you will find yourself using over and over—such as Request.Form, Request.Querystring, and others—and that you will find yourself using as a very pointed tools for specific tasks. You won't use all the properties of the Request all the time, but they are powerful nonetheless.

For instance, let's take the Request.IsSecureConnection property. This is a nifty little tool that checks to see whether you are communicating via an HTTPS secure protocol or not. It returns a Boolean value of true or false, depending on whether the connection is secure. It's a neat gadget that will definitely come in handy in certain situations, but it's not something you're gonna use every day. Table 4.1 provides a list of some that you will use just about every day.

Table 4.1 Request Object Properties

Request Property

Description

Browser

An instance of the HTTPBrowserCapabilites object that is chock full of information about the client's browser and its capabilities.

Cookies

Enables you to store information on the client's machine and retrieve it at a later time.

Form

Retrieve the values of form elements submitted during a form post.

QueryString

Retrieve the values of name/value pairs stored in the requesting URL. These can be inserted directly or can be the result of a form being submitted via the Get method.

ServerVariables

An ocean full of variables about the request.

Now take a look at a few of these in action. The following is a code example that incorporates a few of these Request properties.

Visual Basic .NET—page_request_vb.aspx

<%@ page language="vb" runat="server"%>
<script runat=server>

Sub Page_Load()  
    OurLabel.Text = "Here are some of our Request properties in action<br>"
    OurLabel.Text += "My Browser is: " + Request.Browser.Browser + "<br>"
    OurLabel.Text += "Our Querystring Color is: " +
Request.QueryString("color") + "<br>" OurLabel.Text += "This file is located at: " +
Request.ServerVariables("Path_Translated") + "<br>" End Sub </script> <html> <head> <title>Page Request</title> </head> <body> <asp:label id="OurLabel" runat="server"/> </body> </html>

C#—page_request_cs.aspx

<%@ page language="c#" runat="server"%>
<script runat=server>

void Page_Load(){
    OurLabel.Text = "Here are some of our Request properties in action<br>";
    OurLabel.Text += "My Browser is: " + Request.Browser.Browser + "<br>";
    OurLabel.Text += "Our Querystring Color is: " +
Request.QueryString["color"] + "<br>"; OurLabel.Text += "This file is located at: " +
Request.ServerVariables["Path_Translated"] + "<br>"; } </script> <html> <head> <title>Page Request</title> </head> <body> <asp:label id="OurLabel" runat="server"/> </body> </html>

NOTE

Please note that whenever you are specifying an item in a collection, such as the Request.Form or Request.Querystring, the bracket types around the item are different in the two languages. In Visual Basic .NET, you use parentheses and quotes around the item name, whereas in C# you use square brackets and quotes. If you come from a traditional ASP/VBScript background and decide to use C# as your language, you will need to watch out for this.

If you look at Figure 4.8, you can see we are requesting the value of the browser being used to view the ASP.NET page, a value in the QueryString—or in other words, name/value pairs passed in the URL of the page—and a ServerVariable called "Path_Translated".

Figure 4.8 The HTTPRequest object enables you to retrieve data either passed to a page or submitted by the user.

There are times when data that you request is a property like the Request .Browser.Browser property. This may look redundant with Browser.Browser being in the Request, but remember that you are dealing with an addressing system here, or a namespace. The first "Browser" is a property of the page and is an instance of the HTTPBrowserProperties object. That object has a property called Browser, and hence the Browser.Browser in the Request. It might have made more sense if I had written Request.Browser.JavaScript, which would have returned a Boolean true or false depending on whether a browser is JavaScript-enabled.

The second request type that you will see is called a collection and requires you to identify what you're looking for. With the QueryString, I knew I was looking for "color" and requested that from the QueryString collection. The Request.Form collection operates the same way. The contents of the Form and QueryString generally are determined by the programmers of the website, and you can pass whatever name/value pairs you would like through these methods.

With the ServerVariables, you need to specify the variable that you are requesting, but these aren't programmer-defined. The available variables are determined in ASP.NET and are a bit too numerous to list and describe in detail in this book. I would recommend that you investigate the .NET Framework SDK for more information on ServerVariables.

Now that you've seen how to get information from the user and how to request all types of different data, you need to be able to respond to those requests. ASP.NET has very generously provided an instance of the HTTPResponse object as a page property called Response.

Response

Every time that Bernice or Ethel asked a question or made a request, the other had a response. When Ethel asked:

"Bernice, do you want to see my latest masterpiece? It's a deep dish apple pie done to perfection."

Bernice had a response:

"Certainly Ethel. Let me have a look see."

There was a conversation. This is what the Request and its counterpart the Response allow us to do: carry on a conversation with the visitors of the web sites we create.

Table 4.2 lists a few of the common Response object's properties and methods.

Table 4.2 Response Object Properties and Methods

Response

Description

Buffer

This controls the flow of data from the server to the user's browser. When the buffer is set to true, which it is by default, data isn't sent to the browser until the server completely processes the page. When the buffer is set to false, data is sent to the browser as soon as it's processed and doesn't wait for the entire page to process.

Clear()

Use this when the buffer is set to true and you want to get rid of everything processed up to where the Clear() is.

End()

Use this when the buffer is set to true and you want to send to the browser what you've processed up to the point where the End() is and stop processing the page at that point.

Flush()

Use this when the buffer is set to true and you want to send to the browser what you've processed up to the point where the Clear() is.

Redirect()

Allows you to send the user to a new URL.

Write()

Allows you to write information into ASP.NET pages.

WriteFile()

Writes the specified file directly to an ASP.NET page.

I have this really great news; do you want to hear it? Nah. I'm not gonna tell you 'til I know everything. I want to wait 'til I know the whole story first before I let you know. Well...maybe I'll tell you what I know so far.

UGGHHHHHH!!! It's all over!! I don't want to talk about it anymore. I can't go on. I can't even face it anymore. I'm ruined...I'm ruined ......I'm ruined.

Dramatic, huh? In a feeble and yet to be determined successful manner I was trying to parallel how the Buffer and some of its methods would work in a practical application. If you want to hold back information from being delivered, you set the page's Buffer property to True. Then you can manipulate the page however you want as you progress. Look at an example of the HttpResponse object in action. You are using an object in the System.Threading namespace to pause the pages processing using a method called Sleep. You will hardly ever have need for this, but it helps me to demonstrate some of the Buffer features of the HttpResponse object.

Visual Basic .NET

<%@ page language="vb" runat="server" buffer="true"%>
<%@ import namespace="System.Threading"%>
<html>
<head>
<title>Hi</title>
</head>
<body>
<%
Response.Write(DateTime.Now + " The First Response.Write() has executed.<BR>" )
Response.Flush()
Thread.Sleep(5000)
Response.Write(DateTime.Now + " The Second Response.Write() has executed.<BR>" )
Response.Flush()
Thread.Sleep(5000)
Response.Write(DateTime.Now + " The Third Response.Write() has executed.<BR>" )
Response.Clear()
Thread.Sleep(5000)
Response.Write(DateTime.Now + " The Fourth Response.Write() has executed.<BR>" )
Response.End()
Response.Write("Where does this text go?")
%>
</body>
</html>

C#

<%@ page language="c#" runat="server" buffer="true"%>
<%@ import namespace="System.Threading"%>
<html>
<head>
<title>Hi</title>
</head>
<body>
<%
Response.Write(DateTime.Now + " The First Response.Write() has executed.<BR>" );
Response.Flush();
Thread.Sleep(5000);
Response.Write(DateTime.Now + " The Second Response.Write() has executed.<BR>" );
Response.Flush();
Thread.Sleep(5000);
Response.Write(DateTime.Now + " The Third Response.Write() has executed.<BR>" );
Response.Clear();
Thread.Sleep(5000);
Response.Write(DateTime.Now + " The Fourth Response.Write() has executed.<BR>" );
Response.End();
Response.Write("Where does this text go?");
%>
</body>
</html>

In Figure 4.9 you can see that three out of the five Response.Write() commands were rendered to the browser. Notice the times at which they were delivered to the browser. Can you see which two Writes are missing?

Figure 4.9 The HTTPResponse object offers several ways to respond and to control what is output to ASP.NET pages.

The first Write happens and is delivered to the browser when you execute the Response.Flush() method as is the second one with a lapse of five seconds between when the first and second Write. Notice that the third Write is missing from the browser window, but why? Simple. The Response.Clear() method disposed of everything that was still in the buffer. In other words, the buffer is like a container in which processed code is stored. If you use a flush, you dump the bucket to the browser. If you use a Clear(), you dump the bucket to the trash never to be seen again. Later, a Response.End() is used, which is just like a clear() except it completely stops page processing. Look at the generated HTML for this page. Do you notice anything peculiar about the tags that came after the Response.End()?

<html>
<head>
<title>HttpResponse</title>
</head>
<body>
2/6/2002 7:06:39 PM The First Response.Write() has executed.<BR>
2/6/2002 7:06:44 PM The Second Response.Write() has executed.<BR>
2/6/2002 7:06:54 PM The Fourth Response.Write() has executed.<BR>

The closing </body> and </html> tags are missing because the Response.End() isn't specific to stopping the processing of just ASP.NET but the entire HTTP stream of data. It basically dumps the bucket at that point and that's it. Nothing else gets processed.

What is a practical application for the buffer? One place we use it all the time and is a good example is on check-out pages of commerce applications we build. We have clients who send their credit card transactions to a third-party processing company and rely on this third-party processor's server to respond back to us indicating whether the card is accepted or declined. During this period of waiting, however, the visitor needs to be kept busy. Our technique is to build an HTML layer with a message that says "We're now processing your card." Then we flush the Buffer (dump the bucket) and send that message to the visitor's browser. Next, we send the credit card information to the third-party company and wait. When we get a reply from the transaction company we build code to hide the layer and do some fancy-schmancy stuff in the back end database depending on whether the card was accepted or declined. We either build a receipt page or a page with a message as to why the transaction was declined. Then we flush the buffer again and deliver the rest of what's in the bucket.

If we didn't have the buffer, the visitor would either be faced with a page that sat idle with no evidence of any activity and hope something was happening, or we'd be forced to jump through flaming hoops and redirect to different pages a bunch of times to accomplish the same thing. And visitors do not enjoy unexplained screen flashes and redirections. With the buffer, we can display a screen telling them what is happening and then deliver a response without any confusion.

I also want to add a thing or two about the Response.Write method. This was a highly used and abused method of writing data to traditional ASP pages. It was one of the only ways to dynamically write things into ASP pages.

This is not the case anymore, and with the proliferation of server controls such as the label used so far to display the example results, you will find yourself using Response.Write less and less. It is actually a bit out of place in the ASP.NET programming language because it really operates under the more traditional in-line, interpreted model than the event-oriented environment of ASP.NET. The Response.Write method doesn't allow you to affect other objects; it just does what it does, where it is, and that is that.

I must also mention the Response.Redirect method, as well. This is an oft-used method for transporting the user to another page or URL. The syntax for using this method is to simply place the desired location within the parentheses of the method call, enclosed in quotes if it is a string like the following example.

Response.Redirect("anotherpage.asp")

You can only use Response.Redirect if the HTML stream hasn't begun. In other words, if the buffer has begun to send HTML code to the browser, or if HTML code has been generated at all, using the Response.Redirect method causes an error.

As you can see, the Request and Response objects help you understand and carry on a conversation with the users of your web applications. These are critical tools in your toolbox and are objects you will be seeing over and over throughout the remainder of this book, as well as in your experience in programming in this wonderful language called ASP.NET.

  • + Share This
  • 🔖 Save To Your Account

Peachpit Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Peachpit and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Peachpit products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email ask@peachpit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.peachpit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020