Introduction to Dynamic Languages for ASP.NET

In the ASP.NET Futures release, the ASP.NET Dynamic Language Runtime (DLR) provides a layer for integrating dynamic languages with the common language runtime. This documentation covers:

• ASP.NET features supported by dynamic languages.
• How code is handled in dynamic-language pages.

The addition of support for a wide variety of dynamic languages gives ASP.NET users a new set of tools and new flexibility for building Web applications. The following walkthroughs in this section illustrate some of the functionality of dynamic languages in ASP.NET.

• Walkthrough: Using Dynamic Languages with ASP.NET
• Walkthrough: Using Shared Code with Dynamic Languages for ASP.NET
• Walkthrough: Debugging with Dynamic Languages for ASP.NET
• Walkthrough: Databinding with Dynamic Languages for ASP.NET
• Walkthrough: Creating a User Control with Dynamic Languages for ASP.NET

With Microsoft IronPython for ASP.NET, developers can use popular dynamic languages for the .NET Framework to create compelling Web applications. IronPython for ASP.NET are free extensions to ASP.NET that are targeted at:

• ASP.NET developers who want to enjoy the simplicity and flexibility of a dynamic language.
• Python developers looking to harness the power of ASP.NET and its rapid application development (RAD) environment.

Python’s clean object-oriented design, dynamic nature, richness of expression, ease of use, and concise syntax has won over many users in the last several years. IronPython is an implementation of the Python programming language running on the .NET Framework. It is well integrated with the rest of the .NET Framework and makes all .NET libraries easily available to Python programmers, while maintaining full compatibility with the Python language. To learn more about IronPython and to download the complete source code, please visit www.codeplex.com/ironpython.

Implementations of Ruby and Visual Basic are under development. Future releases will expose hosting interfaces and the API for integrating other languages.

In thisrelease, support for dynamic languages in ASP.NET was expanded from the earlier support for IronPython for ASP.NET. Support for dynamic languages in ASP.NET is built on the Dynamic Language Runtime (DLR), a new platform currently under development at Microsoft. The DLR simplifies hosting dynamic languages on the common language runtime.

In addition, dynamic languages work well with dynamic data controls for ASP.NET, a set of server controls that simplify the creation of data-driven Web applications. For more information, see Introduction to Dynamic Data Controls for ASP.NET and Walkthrough: Using Dynamic Data Controls with ASP.NET.

ASP.NET Features Supported by Dynamic Languages

If you already develop .NET pages, using dynamic language pages will not require a great deal of new learning. Most standard ASP.NET features are supported, including the following:

• Pages (.aspx files), user controls (.ascx files), and master pages (.master files).
• Server controls; that is, elements with the runat="server" attribute.
• Code that is included either inline or in separate code files. There are some differences from the standard ASP.NET compilation model, which are discussed later.
• Code snippets; that is, <% ... %>, <%= ... %>, and <%# ... %>.

Application File

Dynamic languages for ASP.NET support a file similar to the Global.asax file. The file is named Global.ext, where ext is the language-specific extension. For example, the extension for IronPython files is .py, so the file name is Global.py.

Unlike the Global.asax file, which contains a directive (<%@ %> element) and a script block with a runat="server" attribute, the Global.ext file contains only code. For example, a simple global application file might contain code like the following:

IronPython

		
def Application_BeginRequest(app):
app.Response.Write('Hello application!')

App_Script Directory

A dynamic language application contains an App_Script folder that is similar to the App_Code directory, except that it contains dynamic-language script files instead of static language code files. The purpose is the same, however; files in this directory contain classes that can be used by code anywhere in the application.

Generic HTTP Handlers

A dynamic language application can contain an HTTP handler that is the equivalent of an .ashx file in a standard ASP.NET application, although there are some differences. Dynamic language handlers are implemented as .aspx files. As with the Global.ext file, handlers in dynamic language applications contain only code. For example, a simple dynamic language handler named HelloWorldHandler.aspx might contain the following:

IronPython

		
<%@ Page Language="IronPython" %>
<Script runat="server">

Response.ContentType = "text/plain"
Response.Write("Hello World")

</Script>

Features Not Supported

The dynamic languages for ASP.NET feature do not currently support an equivalent of Web services (.asmx files). The Web service architecture works only with standard .NET Framework types, which can be difficult to create with dynamic languages. In addition, Web service class methods must be decorated with special metadata attributes such as WebMethodAttribute, and many dynamic languages have no syntax for applying attributes.

In this release, there is very limited design time support, no intellisense support, and no support for writing ASP.NET MVC controllers using a dynamic language. These are all limitations we plan to address in future releases.

In the .NET Framework version 2.0, dynamic languages require full trust to emit Microsoft intermediate language (MSIL) for compilation at run time.

How Code Is Handled in Dynamic Language Pages

One difference between managed code and dynamic languages is the compilation model. Dynamic languages do not use CodeDOM, the core of the code-generation model for standard ASP.NET pages. The standard code-handling model requires inheriting from a base class and overriding members with specific type signatures. This can be problematic for dynamic languages.

In contrast to the standard compilation model, in which all user code in a page becomes part of a generated source file, each piece of dynamic language code in a page is treated as an individual entity. The implications of this are best seen by considering the various types of user code.

Code in <script> Elements

In standard ASP.NET pages, all user code in <script> elements that have the runat="server" attribute becomes part of the generated class. In contrast, in dynamic language pages, no new class is generated. Instead, ASP.NET directly instantiates the class specified by the inherits attribute. In this respect, the term "inherits" is inaccurate for dynamic language pages, because no inheritance occurs.

Instead of becoming part of a class, the code in a <script> element becomes a kind of companion code for the ScriptPage class. For example, the Page_Load method shown in the following example is not part of any class.

IronPython

		
<script runat="server">
def Page_Load(sender, args):
Response.Write("<p>Page_Load!</p>")
</script>

Instead, members of the ScriptPage class, such as Response in this example, are injected by ASP.NET so that they are directly available to your code. The effect is that the members appear to be part of the class.

In dynamic language terminology, the code in the script block lives in a module. Usually there is one module associated with each HTTP request.

Code-behind Files

Everything that applies to code in <script> elements applies also to code in separate files. In the standard model, the code file contains a partial class declaration, which the compiler merges with the generated class. With dynamic languages, however, there is no class declaration in the code file. Instead, methods appear directly in the file, outside of any containing construct. Therefore, as with normal ASP.NET pages, the question of where to put your dynamic language code is purely a matter of personal preference

Code Snippets

Snippet expressions and statements (that is, <%= ... %> and <% ... %>) also execute in the context of the module created for the code belonging to the page. As a result, these snippets have access to methods and variables defined inline, in <script> elements, or in separate code files. For example, if you define a Multiply method in a <script> block, you can write <%= Multiply(6,7) %> in your page.

Code snippets also have access to the members of the Page class. For example, you can write <%= Title %> to display the title of the page.

Data-Binding Expressions

Data-binding expressions are a type of code snippet, but they are worth discussing separately because they work more naturally with dynamic languages.

In standard ASP.NET code, you might have a GridView control with a templated column containing the data-binding expression <%# Eval("City") %>. The Eval method is used to get the value the column named City for the current row in the data source.

With dynamic languages, the snippet is simply <%# City %>. City is a code expression in the dynamic language instead of a literal string that must be interpreted by using the Eval method. This means you can write expressions containing arbitrary code. For example, with IronPython you can write <%# City.lower() %> to display the value of the column in lower case.

This straightforward and powerful syntax is possible because dynamic languages support late-bound evaluation. The meaning of City is not known at parse time, but the dynamic language engine is able to bind it to the correct object at run time.

Dynamic Injector Mechanism

The compilation model for dynamic languages enables you to use simple syntax into which additional code is injected at run time. For example, you might have code that reads a value from the query string. The URL for the page might look like this:

http://someserver/somepage.aspx?MyValue=17

In a C# page, you can use the following code to obtain the value:

String myValue = Request.QueryString["MyValue"];

The dynamic injector mechanism allows you to write much simpler code in dynamic languages, as shown in the following examples:

IronPython

		
myVar = Request.MyValue

The support code for dynamic languages enables the registration of an object referred to as an injector. By registering as an injector, the object agrees to handle code that matches a certain pattern. For example, if the dynamic language engine is unable to resolve the expression SomeObj.SomeName, where SomeObj is an HttpRequest object and SomeName is not a real property of the HttpRequest object, the engine calls the injector that has been registered to handle that pattern. The injector handles the expression by calling SomeObj.QueryString["SomeString"]. The net effect is exactly the same, but the syntax is much cleaner.

The injector mechanism has many potential uses. For example, wherever you would write SomeControl.FindControl("SomeChildControl") in C#, you can write SomeControl.SomeChildControl in a dynamic language application. The mechanism is extensible and can be applied to any collection that is indexed by strings.

Compilation of Dynamic Code

Dynamic language engines parse code at run time, compile it on the fly, and execute the compiled code. They are not interpreters. Compiled code is reused wherever possible, for better performance.

Posted in: .NET Framework| Tags: HTTP Dynamic Language Support Introduction Dynamic Data IronPython Overview Generic HTTP Handler App_Script Dynamic Code

---

Introduction to the Validation Application Block

This topic includes a series of brief sections that provide information to help you decide whether the Validation Application Block is suitable for your requirements. This topic includes the following sections:

• Common Scenarios
• Example Application Code
• Highlights of the Validation Application Block
• Determining When to Use the Validation Application Block
• Alternatives to Using the Validation Application Block

In addition to this introductory material, the documentation contains the following topics:

• Developing Applications Using the Validation Application Block. This topic explains how to include the Validation Application Block in your applications and how to configure it. It also contains more detailed information, such as how to create custom message templates and information on how validation works with inheritance.
• Key Scenarios. This topic shows different ways to use the Validation Application Block in your own applications.
• Design of the Validation Application Block. This topic includes a class diagram of the Validation Application Block.
• Extending and Modifying the Validation Application Block. This topic explains how to extend the application block by adding custom validators and attributes. It also contains advice about how to modify the source code.
• Deployment and Operations. This topic explains how to deploy and update the application block assemblies. It also explains the application block's instrumentation.
• Validation QuickStarts. This topic explains how to install and configure the two QuickStart applications and contains a series of walkthroughs that demonstrate how to incorporate common validation operations into an application.

For details of the system requirements for the Validation Application Block, see System Requirements. For details of the dependencies for the Validation Application Block, see Application Block Dependencies.

Common Scenarios

Validation has many applications. For example, you can use it to prevent the injection of malicious data by checking to see if a string is too long or if it contains illegal characters. You can also use validation to enforce business rules and to provide responses to user input. It is often important to validate data several times within the same application. For example, you may need to validate data at the UI layer to give immediate feedback when a user enters an invalid data value, and again at the service interface layer for security.

The Validation Application Block is designed to address the most common tasks developers face when they must validate input either from a user or another system. These tasks are arranged according to scenarios. Each scenario gives an example of a typical way to use the Validation Application Block and shows the code that accomplishes the task.

The scenarios are the following:

• Using Attributes to Define Validation Rule Sets
• Using Self Validation
• Validating Objects
• Integrating with ASP.NET, Windows Forms, and WCF; this scenario includes information about integrating the Validation Application Block into the following types of applications:
  • ASP.NET
  • Windows Forms
  • WCF

Highlights of the Validation Application Block

The Validation Application Block has the following benefits:

• It helps maintain consistent validation practices.
• It includes validators for validating most standard .NET data types.
• It allows you to create validation rules with configuration, attributes, and code.
• It allows you to associate multiple rule sets with the same class and with members of that class.
• It allows you to apply one or more rule sets when you validate an object.
• It can be integrated with ASP.NET, Windows Forms, and Windows Communications Foundation (WCF).

Determining When to Use the Validation Application Block

The Validation Application Block allows you to encapsulate validation best practices into easily maintainable code that you can reuse. Encapsulation also allows you to separate the application code from the validation logic. In some situations, you may be able to update the validation logic without redeploying the application. Another common situation where the application block works well is when your validation code must work across multiple layers of the application's architecture.

In very simple cases, when you only need to validate a few objects, you may not want to incur the overhead of adding the application block.

Alternatives to Using the Validation Application Block

Alternatives to using the Validation Application Block may include using the validation capabilities that are a part of ASP.NET and Windows Forms. Another alternative for WCF and other applications that use XML data is to use the XML Schema Definition tool (XSD), which allows you to validate messages at the XML level. If your validation logic only needs to be applied within these technologies you may not need to use the application block. However, if the validation logic needs to be reused, the application block is a better choice.

Posted in: .NET Framework| Tags: WCF Introduction Validation Application Block Validation

---

Take Advantage of the New Features in Internet Explorer 8

Introduction

Internet Explorer 8 is more standards compliant than any earlier version of Internet Explorer. This means that pages you have written to standards will work better with Internet Explorer 8. Cross-browser compatibility is much easier because you don't have to modify your pages as much to display on specific browsers.
Note  Even browsers that are standards-compliant will interpret some part of standards slightly differently. The Internet Explorer team has published the test cases used for testing Internet Explorer CSS compliance. You can use these test cases as samples for determining differences in the various browsers' interpretations of standards. Those test cases are located HERE World Wide Web link.

Internet Explorer 8 also adds some new end-user features that you can take advantage of on your sites. The new features are Web Slices, Accelerators, and Search Suggestions for Search Providers. Big improvements have been made to AJAX, JScript, and Developer Tools.

This article assumes that your site works well with Internet Explorer 8 and that you have decided against using the META tag to force rendering to the Internet Explorer 7 engine. If this is a problem for you, please see How Do I Fix My Site Today?. You should also consider using the Microsoft Application Compatibility Toolkit (ACT). If your site looks better in Internet Explorer 7 than in Internet Explorer 8, set the META tag and continue reading to see how you can take advantage of new and updated features of Internet Explorer 8.

For more information on all the new features for developers in Internet Explorer 8, see What's New in Internet Explorer 8.
CSS Support

Internet Explorer 8 fully supports CSS 2.1 and more of CSS 3. See CSS Overviews and Tutorials for a full history of CSS support in Internet Explorer, including Internet Explorer 8 support.

For more information, see CSS Improvements in Internet Explorer 8.
HTML and DOM Support

Internet Explorer 8 has improved support for HTML 4.01 and 5, also for DOM 2 and 3. Internet Explorer 8 also more strictly adheres to those standards. In terms of compatibility between Internet Explorer 7 and Internet Explorer 8, this area will cause you the most problems. Some objects you used with Internet Explorer 7 have changed to work according the various standards specifications. In other words, some methods, properties, and so on that worked in a non-standard way in Internet Explorer 7 now comply with standards in Internet Explorer 8.

Test your site in Internet Explorer 8 to look for problems caused by non-standard usage. For more information, see HTML Enhancements in Internet Explorer 8 and Standards Compliance Updates in Internet Explorer 8.
Better AJAX Support

Internet Explorer 8 more easily supports backward navigation of page fragments. It provides better communication between pages, frames, sites, and domains. JScript also now provides native JSON support. See the following pages for more information:

    * An Introduction to Cross-Document Messaging in Internet Explorer 8
    * XMLHttpRequest Enhancements in Internet Explorer 8
    * Connectivity Enhancements in Internet Explorer 8
    * Introducing AJAX Navigations
    * JSON Object

Developer Tools Built In

You may have used downloaded and used the Internet Explorer Developer Toolbar. This add-on was released at nearly the same time that Internet Explorer 7 was released. The toolbar's functionality has been incorporated into the browser, so there's no need for an additional installation. The Developer Tools have been greatly improved to include a debugger, a profiler, and more. When using Internet Explorer 8, press F12 and try it out. For more information, see Developer Tools User Interface Reference.
Accelerators

You can make your Web services available to users as Accelerators. Users can add Accelerators to Internet Explorer 8 and use them anywhere they browse. The user selects some text (for example, an address on a page) and can select an Accelerator for a mapping Web service to see the location. Accelerators offer a preview of results so users don't have to navigate away from the page they are looking at and disrupt the flow of their work.

Setting up a Web service as an Accelerator is easy. It requires an XML file, similar to a manifest file, on your server. There are also scripting methods for adding the Accelerator to Internet Explorer. Microsoft has set up a Gallery (http://ieaddons.com/) where you can make your Accelerators available.

For more information about Accelerators, see OpenService Accelerators Developer Guide.
Web Slices

Like an RSS feed, you can set up portions of your Web pages that contain frequently updated information as Web Slices for your users. Users subscribe to a Web Slice and can monitor changes without having to navigate back to the original page unless they want to see more information. Microsoft has set up a Gallery (http://ieaddons.com/) where you can advertise your Web Slices.

For example, news feeds, auctions, social networking updates, and weather updates are all good scenarios for Web Slices, but there are many more.

For more information about setting up a Web Slice, see Subscribing to Content with Web Slices.

Posted in: Others| Tags: Introduction IE IE 8 New Advantage explorer version internet note cross-browser compliant compatibility

---

ASP.NET Dynamic Language Support

Introduction

Dynamic Languages are a class of high-level programming languages that do not rely on static typing. Many decisions that are made at compile time by a statically typed language are instead made at run time by a dynamic language. For example, many dynamic languages use dynamic typing, where an object’s type is determined at run time instead of at compile time. These languages make a trade-off between compile-time type-checking in favor of increased flexibility at run time.
There are many good static languages, such as C#, and many good dynamic languages, such as IronPython. The choice of what type of language to use comes down to personal preference and to the nature of the project you’re working on.
Giving ASP.NET users the choice of languages was part of the design since our first version of ASP.NET, and this Dynamic Language Support is just another step in that direction. Unlike other Web platforms that support only one language, the ASP.NET team wants to enable users to choose the language that fits them best.

This Release

This release is compatible with IronPython 2.6 Beta 1. Currently it does not include Language Services Support and project templates. To create a new IronPython ASP.NET WebForms project, simply copy the “examples\hello-webforms” to a new directory and rename the directory to your liking. A redistributed copy of IronPython 2.6 Beta 1 can be found in the “bin” directory; all files except Microsoft.Web.Scripting.dll, the IronPython ASP.NET integration, are from the IronPython 2.6 Beta 1 release.
Included in this release are two WebForms examples that are written in IronPython: “hello-webforms” and “album-handler”, which can be found in the “examples” directory. “hello-webforms” is a simple web application that shows PostBack handling, and “album-handler” is a larger web application that creates a photo album from a directory of images and generates thumbnails for them on the fly.

Current Limitations

There are some tooling limitations with this release:

• Limited support for designers
• No IntelliSense support.
• No support for ASP.NET MVC. This is planned in the future by extending the IronRuby ASP.NET MVC support: http://github.com/jschementi/ironrubymvc.

Why?

If you are an ASP.NET developer interested in trying out the simplicity and flexibility of a dynamic language, then this is for you - or if you are already investigating IronPython, then this opens up the door to developing ASP.Net Web applications using that language. For those interested in building ASP.NET applications with IronRuby, that's coming. Posted in: Website-asp.net| Tags: asp.net Dynamic Language Support Introduction Support languages run language class asp dynamic

---