Saturday, November 26, 2011

Databinder.Eval and Container.DataItem in Repeator?

The databinding expression <%# some expression %> is evaluated in the language of the page (VB, C#, etc.) This can have a big impact on the current syntax, so be very careful when you are looking at docs for the language you are using.

Container.DataItem is a runtime alias for the DataItem for this specific item in the bound list. For a grid which displays 10 rows of data, this is one row from the datasource. The actual type of DataItem is determined by the type of the datasource. For example, if the datasource is a Dataview, the type of DataItem is DataRowView. If the type of the datasource is an array of strings, the type of DataItem is String. If the datasource is a collection of strongly-typed objects (for example "Employees" objects), the type of DataItem is Employees.

Each of these cases requires a slightly different databinding expression, with further differences between VB and C#. In every case, you want the databinding expression to produce a string that can be displayed in the page.

Here are some examples:

Array of Strings:

VB/C# <%# Container.DataItem %>

Field from DataView:

VB <%# Container.DataItem("EmployeeName") %>

C# <%# ((DataRowView)Container.DataItem)["EmployeeName"] %>

Property from a collection of objects:

VB <%# Container.DataItem.CustomerName %>

C# <%# ((Customer)Container.DataItem).CustomerName %>

Non-String property from a collection of objects:

VB <%# CStr(Container.DataItem.CustomerID) %>

C# <%# ((Customer)Container.DataItem).CustomerID.ToString() %>

As you can see the syntax is tricky, especially for C#, which requires explicit casting. So we've provided a DataBinder.Eval() helper method that figures out the syntax for you and formats the result as a string. It's really convenient, with a couple of caveats: it's late bound (uses reflection at runtime to figure out the data types), and it only supports basic data types in the fields: string, int, datetime, etc.
You can use Eval instead of DataBinder.Eval in ASP.net 2.0

DataBinder.Eval takes 2 or 3 arguments. The first arg is the data object to bind to. In the case of DataGrid, DataList and Repeater, Container.DataItem is the single row. The second arg the string name of the field from the data object you which to display. DataBinder.Eval uses these two pieces of information to work out the rest of the expression syntax.

An optional third argument is a .NET formatting string. DataBinder.Eval will handle a single replacement for {0} only. So the example below:

<a href='<%# "default.aspx?CategoryId=" + Cstr(Databinder.Eval(Container.DataItem, "ID"))%>'>

could be simplified to:

<a href='<%# Databinder.Eval(Container.DataItem,"ID","default.aspx?CategoryId={0}" ) %>'>

Wrapping DataBinder.Eval in CStr() is unnecessary as the compiler will wrap the statement with a Convert.ToString like this:
control1.SetDataBoundString(0, Convert.ToString(DataBinder.Eval(item1.DataItem, "ID")));

Best of all, the Databinder.Eval syntax is the same for VB and C#.

<%# Container.DataItem %>

So what is this expression exactly? The <%# %> means this is a DataBinding expression and Container.DataItem is an alias for the current item in the datasource. In other words, if you are binding to a collection of objects Container.DataItem is the current row of that collection.

If we use a DataView (default type when using SQLDatasource) to bind then Container.DataItem is a DataRowView. For a collection of objects of type Animals the type will be Animal and for an array of strings Container.DataItem will be a string.

Since .NET doesn't know to what type of collection object you will bind to DataItem will return an object. For C# you will have to cast your DataItem:

<%# ((DataRowView)Container.DataItem)["SomeProperty"] %>

There's another way of achieving the same result and that is using DataBinder.Eval.

<%# DataBinder.Eval(Container.DataItem, "SomeProperty")%>

DataBinder.Eval is a helper method that uses reflection to find the type of the DataItem in order to display the data correctly. The benefit of the Eval method is that if your type changes in the future you don't need to change the code, but in the other hand reflection causes performance to slow down.

<asp:Repeater id=Repeater1 runat="server">
<HeaderTemplate>
<table border=1>
<tr>
<td><b>Company</b></td>
<td><b>Symbol</b></td>
</tr>
</HeaderTemplate>

<ItemTemplate>
<tr>
<td> <%# DataBinder.Eval(Container.DataItem, "Name") %> </td>
<td> <%# DataBinder.Eval(Container.DataItem, "Ticker") %> </td>
</tr>
</ItemTemplate>

Wednesday, November 23, 2011

Configuring ASP.NET for sending Email

How ASP.NET Sends Mail
One of the most common uses of forms in a website is to send email. Sending email from a website used to be a complex and difficult task, but as with so many other tasks that used to be complex, ASP.NET makes sending email easy.
In this chapter you'll see two different classes from the .NET Framework used to send email with ASP.NET; the System.Net.SmtpClient class and the System.Net.MailMessage class.

The System.Net.SmtpClient Class
The SmtpClient class facilitates the sending of email with the Simple Mail Transfer Protocol or SMTP. The SmtpClient class is used to connect your ASP.NET application to the network (either the Internet or another network) and to authenticate you (if necessary) to the SMTP mail server.
We will use a few properties of the SmtpClient class to connect to the SMTP server on the network:
  • Host Property— The Host property is used to specify the name of the SMTP server to which you are connecting.
  • Port Property— Every connection on a network takes place over a specific channel on the network called a port. SMTP communication takes place on port 25 by default. The Port property defaults to a value of 25, but if your SMTP server requires a different port, you can specify that by using the Port property.

    Tip: It's uncommon for an SMTP server to not use port 25. Ask your network administrator, ISP, or hosting company if you're not sure what port your SMTP server uses.
  • Credentials Property— Most SMTP servers require that you provide a username and password or otherwise authenticate yourself before you can send email.
    Some SMTP servers (usually on corporate networks) allow you to use the credentials of the account running your ASP.NET code. In those cases, you can specify to use the default credentials, but in this web application, we'll specify a username and password.

The System.Net.MailMessage Class
The MailMessage class (as you've likely guessed) represents the actual message that is sent. The following list shows some of the properties of the MailMessage class, all of which should be self-explanatory:
  • To— The destination email address(es) for the message.
  • From— The email address of the sender.
  • Cc— The email address(es) that appear on the CC line.
  • Bcc— The email address(es) that appear on the BCC line.
  • Subject— The email's subject.
  • Attachments— A list of file attachments included with the email.
  • IsBodyHtml— A Boolean property that specifies whether or not the Body property uses HTML code.
  • Body The body of the email being sent. This is the actual text of the email message.
After you set the properties of the MailMessage class, you call the Send method and the SmtpClient class is used to send the message.
Modifying the Configuration File for internal Email Settings
In a real-world ASP.NET application, you may be sending email from many pages in your application. If the SMTP properties (such as server name, username, password, and so on) change, it's not efficient to have to make changes on each page that sends email.
Fortunately, many of the properties of the SmtpClient class can be specified in the configuration file for your ASP.NET application. If you specify properties in the configuration file, you have to modify only the configuration file if any of those properties change, and all pages that send email will automatically use the new settings.

Tip: If you specify a setting in your server-side code that's already been specified in your configuration file, the setting that you specify in code overrides the setting in the configuration file.

Adding Email Configuration to the web.config File
Mail configuration is specified in the <system.net> section of the web.config file. The web.config file doesn't contain a <system.net> section by default, so you need to add one.
Open the web application and then open the web.config file in Visual Web Developer. Add the following code to the web.config file directly before the opening <system.web> element:
<system.net>
<mailSettings>
<smtp>
<network host="smtp.yourServer.com"
password="yourPassword"
userName="yourUsername" />
</smtp>
</mailSettings>
</system.net>



Tip: The settings you specify for your SMTP server are often the same settings you use in your email client for the outgoing mail server for your domain. Your hosting company probably has instructions for setting up email clients on their website that you can use to find settings for your configuration file.


Using the Web Site Administration Tool
You can also use the Web Site Administration Tool to configure your SMTP settings. The Web Site Administration Tool enables you to add and edit SMTP settings while minimizing the possibility of errors due to incorrect configuration or typographical errors.


Tip: When using the Web Site Administration Tool to configure SMTP settings, all entries are optional. If you don't provide a value for a required property in the configuration file, you need to provide it in your ASP.NET server-side code.


To use the Web Site Administration Tool to configure your SMTP settings, follow these steps:




1. Open your website and click the ASP.NET Configuration button at the top of the Solution Explorer window

2. Click the Application tab or the Application Configuration link in the Web Site Administration Tool.

3. Click the Configure SMTP Email Settings link on the Application page of the Web Site Administration Tool.

4. Enter your SMTP server name, as shown in Figure 1.
Figure 1. SMTP configuration can be modified on the Application tab of the Web Site Administration Tool.



5. Enter the port if necessary. In most cases, the default value of 25 should not be changed.


6. Enter an email address in the From text box if desired. The email address you enter here will show up as the sender of the email that ASP.NET sends.
7. Select an authentication method. Choose None if your SMTP server doesn't require authentication. Choose Basic if your SMTP server requires authentication that differs from the credentials of the account that your ASP.NET code is using. Choose NTLM if you want to use the credentials of the account running your ASP.NET code.
8. Click Save to save the configuration settings to the web.config file in your application.

After you click Save, the Web Site Administration Tool automatically updates your web.config file with the changes, and they take effect immediately.

What Happens When a Configuration File Is Saved

Every ASP.NET application runs inside a special area set aside in memory called an application domain. The purpose of the application domain is to provide isolation between different ASP.NET applications. The application domain ensures that one ASP.NET application doesn't access protected areas of another ASP.NET application.

When an application domain starts up, ASP.NET reads the information in the configuration file to set up the application domain. It then begins monitoring certain folders and files within the application for any changes. If a change is detected, ASP.NET shuts down the application domain and restarts it again so that any changes will take effect.


When you make a modification to the application's web.config file (whether by directly modifying the file or by modifying it indirectly with a tool such as the Web Site Administration Tool), ASP.NET immediately recycles the application pool so that the new configuration applies immediately to the application.

Sample Code to send Email in Asp.net without ASP.net web.config settings: 

try
{
MailMessage msg = new MailMessage();

msg.To.Add(toId);
MailAddress frmAdd = new MailAddress(frmyahoo);
msg.From = frmAdd;

//Check user enter CC address or not
if (ccId != "")
{
msg.CC.Add(ccId);
}
//Check user enter BCC address or not
if (bccId != "")
{
msg.Bcc.Add(bccId);
}
msg.Subject = msgsubject;
//Check for attachment is there
if (FileUpload1.HasFile)
{
msg.Attachments.Add(new Attachment(FileUpload1.PostedFile.InputStream, FileUpload1.FileName));
}
msg.IsBodyHtml = true;
msg.Body = mailContent;

SmtpClient mailClient = new SmtpClient("smtp.mail.yahoo.com", 25);
NetworkCredential NetCrd = new NetworkCredential(frmyahoo, frmpwd);
mailClient.UseDefaultCredentials = false;
mailClient.Credentials = NetCrd;
mailClient.EnableSsl = false;
mailClient.DeliveryMethod = SmtpDeliveryMethod.Network;
mailClient.Send(msg);

clear();
Label1.Text = "Mail Sent Successfully";
}
catch (Exception ex)
{
Label1.Text = "Unable to send Mail Please try again later";
}
}


Sample Code to send email in ASP.net with web.config with <mailsettings> 

try
{
MailMessage mailMessage = new System.Net.Mail.MailMessage();
mailMessage.To.Add(userEmailAddress);
mailMessage.Subject = "Subject";
mailMessage.Body = "Body Text";
var smtpClient = new SmtpClient();
smtpClient.Send(mailMessage);
return "Mail send successfully";
}
catch (SmtpException ex)
{
return "Mail send failed:" + ex.Message;
}

manual MailSettings for web.config

<system.net>
<mailSettings>
<smtp deliveryMethod="Network" from="from@yourdomain.com">
<network host="smtp server addresss" userName="username" password="password" 
defaultCredentials="false" port="xxx" enableSsl="true"  />
</smtp>
</mailSettings>
</system.net>

iTextSharp - Convert html to pdf document

You can create this using two steps as follows:

// step 1: creation of a document-object
  Document document = new Document(PageSize.A4, 80, 50, 30, 65);
  // step 2:
  // we create a writer that listens to the document
  // and directs a XML-stream to a file
  PdfWriter.getInstance(document, new FileStream("file.pdf", FileMode.Create));
  // step 3: we parse the document
  HtmlParser.parse(document, "file.html");

ASP.NET 4 and using jQuery 1.4.1

Approximately ten years ago, Microsoft introduced ASP.NET — a framework for building web applications using the new .NET platform. ASP.NET was designed to assist developers to build, deploy, and maintain web pages and websites. ASP.NET integrates with Microsoft Internet Information Server (IIS) and provides developers with a rich set of tools to develop dynamic web applications.

When it was introduced, this framework focused on Web Forms. Web Forms abstracted away many of the low-level complexities of HTML and HTTP, giving developers an experience similar to one used to build Windows Forms. By using Web Forms, developers could quickly create an interactive web page, even if they knew little about the underlying technologies of the web. This development experience was similar to the popular Visual Basic language, so it appealed to developers familiar with that language.

Like its predecessor Active Server Pages (ASP), ASP.NET provides a developer with the ability to build web applications using a combination of code and markup. Unlike the classic ASP, ASP.NET is built on top of the Common Language Runtime (CLR) and uses the power of .NET. Because of this, ASP.NET can take advantage of CLR benefits, such as automatic garbage collection, a rich set of libraries, and a robust security model.

The latest version of ASP.NET includes enhancements to the ASP.NET Web Forms Framework and an updated version of the new ASP.NET Model-View-Controller (MVC) framework. Visual Studio .NET 2010 is also the first version to ship with jQuery libraries, which enable developers to build rich client-side functionality into their websites.

This article focuses on what is new in ASP.NET 4. First, you learn about some of the new features and enhancements of ASP.NET 4 Web Forms. Finally, this article covers how to effectively use jQuery to enhance your application. Along the way, a sample application provides guidance on how to implement these new features

 

UNDERSTANDING WEB FORMS

The Web Forms Framework was introduced with ASP.NET 1.0. Countless websites have been successfully built and deployed using this platform.

Essentially, the Web Forms Framework was designed to abstract away the complexities of Hypertext Markup Language (HTML) and Hypertext Transfer Protocol (HTTP) to make web development feel more like Visual Basic forms development. Following are characteristics of Web Forms application development:

·         The developer is presented with a design surface that looks like a web page.

·         Web controls are dragged onto this design surface.

·         Properties are set on the page and on the controls.

·         Code is written to manipulate the page, controls, and associated data.

Using Visual Studio, developers can quickly build a web application. A rich set of built-in controls and third-party controls adds to this abstraction and helps cut down on many development tasks. However, this rapid application development (RAD) comes at a cost. Web Forms and associated controls automatically generate HTML and JavaScript. Sometimes the generated code does not exactly match your needs. To add to the difficulty, different web browsers often render the same HTML in different ways, and understand JavaScript differently — particularly as JavaScript interacts with the web page’s Document Object Model (DOM). A common problem is that a page renders properly in one browser but improperly in another.

Using Web Forms, it is difficult to modify the output HTML or JavaScript. This is especially an issue when you target multiple browsers. If you have trouble tweaking HTML, you will have trouble supporting some browsers. For this reason, web developers should learn as much as they can about HTML, Cascading Style Sheets (CSS), and HTTP. Abstractions such as Web Forms are fine, but  they do not excuse the responsibility to understand the technologies they abstract.

Microsoft introduced a number of enhancements to ASP.NET with version 4. Following are a few of the most important ones:

·         Improved handling of View State provides users with greater fl exibility over the controls
that participate in
View State.

·         The web.config file has been greatly simplified.

·         A new Web Project template provides greater functionality.

·         web.config transformations make it easier to deploy to a new environment.

Let’s take a look at these in a bit more detail.

View State

By default, the web and its underlying transport protocol (HTTP) are stateless. This means that, by default, each request remembers nothing about any previous request. ASP.NET introduced View State as a way to maintain state between pages in a web application. View State works by automatically creating an extra, hidden input within an HTML form. To save the state of the submitted fields on a page, ASP.NET encodes View State data into a single string and sets the value of this hidden field to that string. This field is created on the server and sent down to the client with the rest of the web page. This convenience comes at a price. The encoded data is submitted each time the form is submitted and it is returned to the browser with each response. If you have a lot of data stored in ViewState that data can get quite large, slowing down communication between the client and the server.

Using a previous version of ASP.NET, a developer could turn View State on or off at the page level, or at the control level. Prior to ASP.NET 4, you basically had three options for enabling View State:

·         Turn off View State for the entire page — If you do this, you do not realize any of the benefits of View State.

·         Turn on View State for the entire page — If you do this, you may encode and add unneeded
items to
View State, bloating the payload sent between the server and the browser, slowing
your application, and degrading the user experience.

·         Turn on View State for the page, and then disable View State for controls that do not
need it
— This strategy works well if you want View State for almost every control on the
page, but not for a few controls. It can be a real pain if you want
View State enabled only
for a couple controls.

ASP.NET 4 provides two relevant properties to control View State: ViewStateMode and EnableViewState. Only ViewStateMode is new in version 4, but the two properties work together. EnableViewState has been around since the first version of ASP.NET. It can be set for an entire page, or for a single control, and it can be set to either True or False. EnableViewState does not turn on View State for any controls. Rather, it determines whether View State may be turned on for a control, and for any controls below it in the control containership hierarchy. A control’s ViewStateMode turns on or off View State, but only if EnableViewState is True. ViewStateMode can be enabled or disabled explicitly, or by inheriting this property from its parent container. Setting a Page or Control’s View State attribute to False disables View State for that Page/ Control and for any controls contained therein.

In previous versions of ASP.NET, the only way to selectively enable and disable View State on controls

was to set EnableViewState=”True” on the page, and set EnableViewState=”False” on the controls for which you did not want to maintain the overhead of passing View State between the

client and the server.

You can set ViewStateMode as an attribute of a page or control, or you can set it in code. Following are the allowable values:

·         Enabled — Turns on View State for a control.

·         Disabled — Turns off View State for a control.

·         Inherit — Tells ASP.NET to set the ViewStateMode to that of the control’s parent container.
This is the default value for a user control.

ViewStateMode is only relevant if EnableViewState is set to True for a control or the control’s parent. If EnableViewState is True, ViewStateMode turns View State on or off for a given control. By turning on View State, any data associated with a control is encoded on the server, saved with a hidden input field, and rendered to the client, so it will be submitted the next time the form is submitted.

My recommendation is to set EnableViewState to True on the page and to selectively turn on (set

to Enabled) ViewStateMode for the controls that will benefit from it. This minimizes the payload sent between the client and server and prevents you from accidentally adding to this payload as you add new controls to the page. Following is an example of this:

<%@ Page …

EnableViewState=”True” ViewStateMode=”Disabled” %>

<asp:Label runat=”server” Text=”Enter UserName:” ID=”EnterUserNameLabel” />

<br />

<asp:TextBox runat=”server” ID=”UserName” ViewStateMode=”true” />

web.config Transformations

One of the challenges of application development is migrating configuration files from one environment

to another. I typically develop my applications in a Development environment, using a Development database, Development web services, and the files on my own computer. Many of these settings (such as connection strings, file paths, and URLs) are set in the application’s web.config file.

At some point, I deploy my application to a Test environment, so that testers can try it out. The Test environment can use different connection strings, URLs, and file paths, so I need to modify the web .config at the time I deploy the application to this environment. This problem presents itself again when I deploy to a Staging environment, a Production environment, and any other environment my organization or customer uses.

ASP.NET 4 provides an elegant way to handle modifying a web.config file as the application is deployed to different environments. Using Transformations, you can create a base web.config file and a separate file for each of your environments. Each environment file contains only those elements that vary from the base configuration.

Simplified web.config

In earlier versions of ASP.NET,  the web.config file tended to become bloated and difficult to manage.

Even a newly created empty web project contained a large web.config file. With ASP.NET 4, much of the default configuration has been moved to the machine.config file, making the web.config much smaller. You can even create an ASP.NET application with no settings in the web.config file. Developers are encouraged to add only those settings specific to the application to which the web.config file applies.

A smaller web.config file makes configuration settings easier to find and to manage.

New ASP.NET Web Forms Templates

Visual Studio 2010 includes a new and improved web template that is designed to get web developers up and running faster. You can find the ASP.NET Web Application template in the New Project dialog under Installed Templates Í Web, as shown in Figure 1-1. From the Visual Studio menu, select File Í New Project to open this dialog.

FIGURE 1-1: Locating the ASP.NET Web Application template

This template creates an application that includes Home and About pages, and pages for managing users and roles. The site uses a default stylesheet and master page, giving it a polished look; but developers can modify these files to meet their needs. The application is ready to run and use as soon as it is created. You can add forms and code to the initial site to suit the specific needs of your application. Figure 1-2 shows the structure of an ASP.NET Web Application project as viewed from Solution Explorer.

FIGURE 1-2: Structure of an ASP.NET Web Application project

The ASP.NET Web Application template provides a good starting point for developers who are new to ASP.NET and want to see a sample implementation, as well as developers who want to quickly get a site up. Figure 1-3 shows the default page of this application.

The ASP.NET Empty Web Application template takes the opposite approach. It contains no pages or code — only a nearly empty web.config file. This template contains only the references required by an ASP.NET website. It is designed to give experienced developers maximum flexibility when building their website. Figure 1-4 shows the structure of an ASP.NET Empty Web Application project as viewed in Solution Explorer.

Developers who want maximum control over their web applications will prefer the ASP.NET Empty

Web Application template.

The features discussed thus far allow developers to improve on applications without changing the

way they write those applications. However, Microsoft recently released ASP.NET MVC — a set of

tools that provide a new way to build web applications.

 FIGURE 1-3: Default application page

FIGURE 1-4: Structure of an ASP.NET Empty Web Application project

 

JQUERY

Because web forms have been around for a long time, developers can find countless user controls to enhance their web applications. Microsoft and numerous third-party vendors have produced libraries of rich controls to provide extra functionality to ASP.NET websites.

Many of these Web Forms controls rely on page events and code-behind. Therefore, they do not work with the new ASP.NET MVC paradigm. Developers can still enhance their applications by adding rich client-side interactions using JavaScript. Many of the same component vendors who built Web Forms controls are working on and releasing controls designed for MVC. In many cases, they use JavaScript to provide client-side interactivity.

JavaScript is an excellent tool to interact with a web page because of the following reasons:

·         It is a standard language that runs within all modern desktop browsers.

·         It interacts with the Document Object Model (DOM) exposed by a web page, allowing web developers to manipulate the objects on a page.

·         It has a rich event model for building interactive applications. Unfortunately, JavaScript has several disadvantages that have limited its usefulness and popularity, including the following:

·         The learning curve for JavaScript can be steep for some developers.

·         Each browser has its own implementation of the DOM, forcing developers to write and test the same functionality multiple times to ensure the code runs correctly in a variety of browsers.

Several libraries have been built on top of JavaScript to address these disadvantages. These libraries abstract away the complexity of JavaScript, and (more important) automatically detect and handle the differences interacting with the variety of DOM implementations among the major browsers.

jQuery is an Open Source JavaScript library that has gained a lot of popularity in recent years, thanks to its rich set of functions and ease of use. With Visual Studio 2010, Microsoft made the decision to include jQuery with the product, which has boosted its popularity even more. A new ASP.NET MVC project includes a
Scripts folder that contains a dozen .js files. These files contain jQuery functions that the project’s web pages can call. You can replace these files with new versions downloaded from http://jquery.com. Each filename contains a number (such as 1.4.1) just before the file extension. This is the version number of jQuery with which the script file is associated
.

This naming convention makes it easy to tell which version of jQuery a site is running. To use jQuery in a view page, reference either files in the Scripts folder or files hosted on a Content Delivery Network (CDN), such as the one hosted by Microsoft at http://ajax.microsoft.com/ajax/jquery. The jQuery script files (for example, jquery-1.4.4.min.js) are stored in this folder.

Link to each .js file you wish to use on your page.

Each location typically contains two versions of each file: one ending in
.js and one ending in .min.js. The .min.js version is a minified version of the script, meaning that comments and excess white space have been removed, and variable and function names have been shortened. I always use the minified versions because they are smaller and, therefore, faster to download to the client.

 

Add the following line to the top of the page to make jQuery functionality available:

<script src=”[FULL_SCRIPT_PATH]” type=”text/javascript”></script>

In this snippet, [FULL_SCRIPT_PATH] is the path and filename of the script file used by the page.

For example, add the following line to use the main jquery file in the project’s Scripts folder from

within the sample site’s master page (Shared\_Layout.cshtml):

<script src=”@Url.Content(“~/Scripts/jquery-1.4.4.min.js”)”

type=”text/javascript”></script>

The Url.Content method specifies an absolute path, so that the .js file will be found, regardless which view is rendered, and in which folder that view is found. I prefer to reference this script from my site’s master pages.

 

JQuery code is simply JavaScript. Therefore, all jQuery code belongs within

<script language=”javascript”></script> tags.

A common pattern for jQuery syntax is as follows:

$(Selector).Event(Action);

In this snippet, $ is simply the dollar sign character, which represents the jQuery object; Selector is a jQuery selector function (more on this later); Event is an event fired by the selected objects; and Action is the code to run when the event fires. Each call to a jQuery function begins with the $ symbol. This symbol indicates that the JavaScript that follows is jQuery syntax. You can replace the $ with the keyword jQuery, but $ is far more terse. A jQuery selector uses syntax similar to the selectors in CSS and always returns a collection of elements that match the selector criteria. The selector syntax can take several forms:

·         Enclosing a tag name in quotation marks selects all elements of a given tag. For example, (“div”) selects all div elements on a page.

·         Preceding a string with # selects an element by its ID. For example, (“#custIdLabel)
selects an element with the ID custIdLabel. It would select multiple elements with this ID if
you were foolish enough to have multiple elements on your page with the same ID.

·         Preceding a string with . selects all elements to which a given class has been applied. For example, (.bodyText) selects an element with the class bodyText.

·         You can select elements within elements by separating selectors with a space. For example, (“headerDiv a”) selects anchor tags contained within an element named headerDiv.

Sometimes, the action might be to bind a function to an event, so that function’s code runs when the event is fired. The most common way to do this is to bind an anonymous function to the ready event of the document. For example, the following jQuery code displays an alert message when the user selects the text within a Div with an ID of MyDiv:

$(“#MyDiv”).click(function () {

alert(“You clicked me”);

});


jQuery code often starts by binding code to the
ready event of the document object. The document object represents a page’s entire DOM, and the ready event fires when all the elements of the DOM are loaded into memory, making it an ideal time to manipulate elements, or wire up any other events.

Manipulating DOM Elements with jQuery

Take a look at the DemoClick.htm page in the sample project. Following are the relevant parts:


<script type=”text/javascript” language=”javascript”>

$(document).ready(function () {

$(“#Img1”).click(function () {

var newHeight = $(this).height() + 20;

$(this).height(newHeight);

});

});

</script>

<img id=”Img1” height=”50” src=”../Images/Grin.png” alt=”Click to grow” />

 

The page contains an image tag with the ID “Img1”. The JavaScript binds an anonymous function to the document.ready event. The document.ready event fires when the browser has loaded into memory all the objects in the page’s DOM. In jQuery, you may shorten $(document).ready(function() to the more terse syntax $(function(), which I will do in later examples.

This anonymous function binds another function to the click event of the Img1 image.

$(“#Img1”).click(function () {

Notice the selector: $(“#Img1”). The # symbol preceding “Img1” tells jQuery to search for any elements with an ID of “Img1”. A selector returns a set of elements matching the selection criteria. In this case the selector finds one such element on the page, so it returns a set containing that one matching element. The code then binds an anonymous function to the click event of the matching element. The code of the anonymous function is as follows:

var newHeight = $(this).height() + 20;

$(this).height(newHeight);

In this code, the variable newHeight is declared and assigned. The code uses the keyword this to identify the element that fired the event. In this case, it is the image element that fired the click event, so $(this) refers to the image element. The code retrieves the height of the image element and increments it by 20 pixels before assigning this sum to the newHeight variable. The result is a page that displays an image. Each time the user clicks the image, it grows 20 pixels larger.

 

Calling Server Code with jQuery

A powerful use of jQuery is its capability to call RESTful web services on the server. This gives a web application the capability to call server code without posting back an entire page. ASP.NET MVC provides a simple way to expose RESTful services that can be called from jQuery. Recall that each Controller Action method returns an ActionResult object. The MVC framework provides the JsonResult class — a subclass of ActionResult that returns data in the JSON format. JSON is a lightweight, text-based data format designed for transmitting data across the web.

The EmployeeController class in the HR sample application contains a GetAllEmployees action

method that returns a JsonResult object. Following is the code:

public JsonResult GetAllDepartments()

{

var empBus = new DepartmentBusiness();

List<DepartmentDTO> departments = empBus.GetAllDepartments();

return Json(departments, JsonRequestBehavior.AllowGet);

}

 

This code looks similar to the GetAllDepartments method in the DepartmentController class. The difference is that the last line uses the Json helper method to pass to the view engine a JsonResult object, instead of a ViewResult object. The result is that data is sent to the client as JSON — a data format that is small and self-describing, and, therefore, well-suited for passing data between client and server.

return Json(departments, JsonRequestBehavior.AllowGet);

The Json method here passes the list of departments down to the view engine. The second parameter

of the method enables this service method to be called via HTTP GET. By default, only POST methods are enabled.

This method can be called directly from a jQuery script on a web page without refreshing that page.

The EditJQ.aspx page contains the following script:

$ (function () {

var url = “/Employee/GetAllDepartments”;

$.getJSON(

url,

null,

function (data) {

var options = “”;

for (var i= 0; i< data.length; i++) {
options += “<option value=” + data[i].DepartmentId + “>”

+ data[i].DepartmentName + “</option>”;

}

$(“#DepartmentSelect”).append(options);

});

});

When the document’s ready event fires, the script calls the jQuery getJSON function, which calls the RESTful web service function GetAllDepartments. The last parameter of getJSON is a callback function that runs after the web service returns. The data parameter is the return value from the web service — in this case, a List of departments.

The selector $(“#DepartmentSelect”) selects an empty drop-down list on the page with the ID DepartmentSelect. The function loops through the list of departments and builds up an option tag for each department. It then appends the list of option tags to the empty drop-down list.