Safari

Recently, i was too busy with this project. My role was to make the existing code compatible with broswer safari. "safari" browser? something new huh? yeah, it is a browser made available for Macintosh system only by apple computers. Nost of the people dont know about this browser. But today around 4% of the people in world use this. IE shares more than 50% and firefox shares more han 30%, rest of the part is shared anomg other browsers like mozzila, opera and all.

Problem with safari is that it supports only w3c standards html and javscript tags. This really makes the coding difficult. Most of us are aware of IE specific javscript and browser elements. So codes that we develop work beautifully in IE but just try to run it in firefox or other browser and see the effect.

Most of the developers love IE because it is very linient. Even if you make mistakes in specifyinh width of the element, or size of the font, IE does not show that mistake instead it takes the default value and shows the result. This might work for IE but will crash for the users accssing your site on other browsers.

This is very important for the developers. Every web designer or web developer must produce code such that it is compatible with all the browsers. If you dont make your site compatible, then it will be accessible only by the half of the world even if the entire world is interested in that.

So alwys follow the w3c standards, because that is supported by all the browsers including IE. If you want to check whether your site is compatible with w3c standsrds or not then you can check it on their site http://www.w3.org/ . Here you can verify your xml, HTML as well as css.

Even the safari has few problems. Many events and elements defined by w3c are still not supported. If you get to work with safari, then first thing to do is to update that software. Ask me more if you are really interested in knowing about developments in safari.

ASP.NET 2.0 : 'Atlas' Overview

Introduction

The new ASP.NET Web development technologies, code-named 'Atlas', integrate client script libraries with the ASP.NET 2.0 server-based development platform. 'Atlas' builds on the AJAX strategy for building Web applications, which enables you to make calls to Web-based applications from client script. 'Atlas' also enables you to perform significant portions of an application's processing on the client, without requiring a round trip to the server to update the page.

This development strategy enables you to build a new breed of Web application that has a number of advantages over traditional Web applications. AJAX-style applications offer better performance, work across browsers, and enable you to create a user interface with more extensive UI features. For more information, see Understanding AJAX Applications and ASP.NET "Atlas".
ASP.NET 'Atlas' applies this new strategy for building Web applications, and significantly enhances it by adding both client and server-side development components. This topic describes the goals of the 'Atlas' feature, and explains the architecture of an 'Atlas' application, including the 'Atlas' client script libraries and 'Atlas' server components.

'Atlas' Goals

The main goal of 'Atlas' is to give you a broad range of application building blocks with the following aims:
• Helping you create 'Atlas' applications.
• Integrating 'Atlas' client script features with the features of ASP.NET on the server to provide a comprehensive development platform.
The first aim of 'Atlas' is to help you create AJAX applications. AJAX development can be complex. 'Atlas' manages this complexity for you by providing features such as the following:
• A consistent, object-oriented set of APIs for developing in JavaScript.
• Automatic browser compatibility, so that you do not have to write code or deploy components to make your applications run in multiple browsers.
• Client-script APIs and components that support rich UI features, which saves you from having to write the extensive code normally required in AJAX-style applications. For example, 'Atlas' provides commonly used behaviors including drag and drop, and you can bind these to HTML controls with minimal coding.
• A declarative scripting model for client development that is similar to the declarative syntax for ASP.NET server controls. This can reduce or eliminate much complex coding.
The second aim of 'Atlas' is to integrate client scripting with ASP.NET server-side development. Rather than focusing all development on only the client or only the server, 'Atlas' provides tools for both, enabling you to handle application tasks wherever it makes the most sense. ASP.NET provides the following server-side features for 'Atlas' applications:
• Web services that are useful to integrate with 'Atlas' applications, such as a profiles service.
• ASP.NET Web server controls that emit the client script needed for 'Atlas' applications. These controls ease the process of creating 'Atlas' applications, because they reduce the task of learning the 'Atlas' client script APIs and components.
• Integrated development tools such as Visual Studio, which provide a design-time development environment, debugging, statement completion, administration, and other productivity-enhancing features.

ASP.Net 2.0 - New Compilation System

I was learning asp.net 2.0 from the PDF of the book "Professional ASP.Net 2.0" and found this great feature. Instead of putting it in my words i have simply copied and placed it here so that you get the exact idea of the concept. Here it goes.

"In ASP.NET 2.0, the code is constructed and compiled in a new way. Compilation in ASP.NET 1.0 was always a tricky scenario. With ASP.NET 1.0, you could build an application’s code-behind files using ASP.NET and Visual Studio, deploy it, and then watch as the .aspx files were compiled page by page as each was requested. If you made any changes to the code-behind file in ASP.NET 1.0, it was not reflected
in your application until the entire application was rebuilt. That meant that the same page-by-page request had to be done again before the entire application was recompiled.

Everything about how ASP.NET 1.0 worked with classes and compilation changed with the release of ASP.NET 2.0. The mechanics of the new compilation system actually begin with how a page is structured in ASP.NET 2.0. Most pages were constructed using the code-behind model because this was the default when using Visual Studio .NET 2002 or 2003. It was quite difficult to create your page using the inline style in these IDEs. If you did, you were deprived of the use of IntelliSense, which can be quite the lifesaver when working with the tremendously
large collection of classes that the .NET Framework offers.

ASP.NET 2.0 offers a new code-behind model because the .NET Framework 2.0 offers the capability to work with partial classes (also called partial types). Upon compilation, the separate files are combined into a single offering. This gives you much cleaner code-behind pages. The code that was part of the Web
Form Designer Generated section of your classes is separated from the code-behind classes that you create yourself. Contrast this with the ASP.NET 1.0 .aspx file’s need to derive from its own code-behind file to represent a single logical page.

ASP.NET 2.0 applications can include an \App_Code directory where you place your class’s source. Any class placed here is dynamically compiled and reflected in the application. You do not use a separate build process when you make changes as you did with ASP.NET 1.0. This is a just save and hit deployment model like the one in classic ASP 3.0. Visual Studio Web Developer also automatically provides IntelliSense for any objects that are placed in the \App_Code directory, whether you are working with the code-behind model or are coding inline.

ASP.NET 2.0 also provides you with tools that enable you to precompile your ASP.NET applications, both .aspx pages and code behind so that no page within your application has latency when it is retrieved for the first time. It is also a great way to figure out if you have made any errors in the pages
without invoking every page yourself.

Precompiling your ASP.NET 2.0 applications is as simple as calling the precompile.axd imaginary file in the application root of your application after it has been deployed. This one call causes your entire application to be precompiled. You receive an error notification if any errors are found anywhere within
your application. It is also possible to precompile your application and deliver only the created assembly."

so that expalins a lot about this new feature. great huh?