With the arrival of ASP.NET came the introduction of validation controls - one of the greatest timesaving features included with it. Such controls allow for data entered by the user to be validated both at the client and then at the server, providing a robust mechanism with standardised feedback, with no need for the developer to implement complicated validation routines for each input-form.

This two-part article by JS Greenwood looks at how such validation controls, with their distinctive format can be implemented in classic ASP, performing validation at both the client and server, thus allowing for a feature-rich system that is compatible with ASP.NET, and also helping ease the migration of applications.

In this, the second part, a server-side implementation of the validators is developed, and the shortcoming of the client-side code is redressed.

With the arrival of ASP.NET came the introduction of validation controls - one of the greatest timesaving features included with it. Such controls allow for data entered by the user to be validated, both at the client and then at the server, providing a robust mechanism with standardized feedback, with no need for the developer to implement complicated validation routines for each input-form.

In this, the first part, the nature of validators is looked at, and a client-side implementation is developed.

The release of the MSDE (Microsoft Data Engine) as a free, logical replacement for Access when developing applications has brought with it many advantages, such as the creation of robust and scalable applications that can later be migrated to SQL Server with ease. Although 100% compatible with SQL Server, it does lack one major feature, however - a tool such as Enterprise Manager that allows for the maintenance of databases, including backup and restore operations. If development is being carried out using an IDE such as Web Matrix then deploying a database to a live environment is made very difficult by this.

In this article, we look at how this deployment can be carried out by manipulating the database server using tools such as the OSQL command-line program that comes with the MSDE. Whilst covering this, the object model provided by MSDE, and other topics, a small application is developed that can be used to create packages for transferring databases between servers that have no other management tools.

One of the main advantages that ASP.NET provides over traditional ASP is the event-driven manner in which it performs its processing. The removal of the need to write complex and laborious code to detect what action the user selected on a web page can shorten the development cycle whilst also abstracting code from presentation. Another benefit that would be provided by the conversion of ASP to such an event-based programming model is the easier porting of applications from ASP to ASP.NET, where this is the natural paradigm for development.

In this in-depth article, JS Greenwood looks at a way of adding event-driven functionality to classic ASP making use of both server-side and client-side code, without adding complexity to the applications that are being developed – the only real change required being a runat="server" attribute added to HTML elements, similar to .NET. The end result is a workable system that can be used in both new and existing systems. More importantly, it demonstrates that there are many possibilities available for altering the way in which ASP applications are developed to suit specific applications. A basic knowledge of event-handling and object-oriented programming is assumed throughout.

One of the most productive features of .NET is the ability to reuse existing COM components alongside new code. Reuse of this vast repository of available code means that tried and tested functionality need not be re-implemented, reducing costs and lowering risks dramatically.

In the .Net documentation it is stated that reusing such components in .Net carries a performance penalty. This article firstly examines from an introductory level how much of a penalty must be paid for this backwards-compatibility by creating a test component that is consumed by .Net, and producing a set of performance metrics. A more detailed and technical description of the mechanisms involved in interoperability is then entered into, discussing type-conversions, COM wrappers, etc. A set of guidelines for the development of components to ensure compatibility is also given.

One of the most commonly viewed pages by ASP Developers is the "Error 500" page - the error page that is displayed whenever there is any un-trapped error during the processing of an ASP script. Compared to the error page displayed by ASP.Net, with more succinct data, a display of the source code containing errors, and a cleaner page layout, the classic ASP error page is very unhelpful.

This article first looks at how error information is stored and obtained in newer versions of ASP - the ASPError object. This information is then used in the creation of a new error page that mimics the display of the ASP.Net page, providing a unified error-display system. This is then extended to provide further functionality such as support for the editing of the offending page on the error page itself. This improved functionality allows for the easier location of errors, and a more rapid way of correcting them in a development environment.

Development tools have long been available for Visual Basic and other languages that allow for huge productivity gains through the automation of key tasks. These tasks include such things as syntax highlighting of code (pretty-printing) for more readable print-outs, and the automated documentation of applications using textual information embedded in the forms, classes, and modules.

This article looks at how an ASP file can be parsed to provide the same functionality. Coverage is given to the separation of HTML from ASP, and to how each of these two languages is structured and can be syntax-highlighted. This is then extended into a full syntax-highlighting tool for ASP pages. The techniques for embedding functional descriptions in the source code are then discussed, along with how to extract such information programmatically. This information is then combined with the syntax-highlighter to produce a full auto-documentation system for ASP applications.

One of the most useful features that IIS provides to a developer is the Directory Browser. Using it, the existence of files and folders can be checked, and the structure of a site can be navigated without knowing exact file-names. Despite such benefits, the default browser is a crude implementation when compared to the Explorer browser used within Windows - both aesthetically and functionally. The addition of standard Explorer features - adding, renaming, and removing files; viewing their properties; along with a revamp of the interface to something more commercial and polished would not only be of immense use to developers wanting to maintain sites, but also in document-sharing applications for end-users.

Unfortunately, the default directory browser is stored deep within IIS itself, making it difficult to customize. This article covers two topics - firstly it looks at where IIS stores much of the information that it provides to users - the directory browser, error messages, and so on. Details on how this information is made available and what parts of it can be manipulated are also provided. Secondly, an alternative directory browser is developed. The replacement browser that is developed for IIS-4 and IIS-5 supports file renaming, deleting, uploading, and so on.

The reuse of what began as bespoke (custom) Web Applications for multiple systems is an area that is commonly difficult to address. Copying the ASP files to another directory and creating a separate database for each is relatively painless, but reusing the components in a manageable manner can prove tricky.

DLL hell and maintainability issues can quickly ensue as the prospect of multiple DLLs with identical interfaces arises. The single difference between each of these components is the database being referenced. Extending such applications from supporting a single, static database to several, dynamically, without breaking the interface or requiring a large amount of additional code, is an issue that must be addressed.

This article looks at ways of doing this and gives a scaleable solution making use of NT user accounts, the registry, and the COM+/MTS Shared Property Manager.

As ASP.NET currently dominates web-development news items, it is easy to write off ASP 3.0, and the possibilities that have thus far been ignored. ASP.NET introduces the approach of separating presentation from business logic using code-behinds, but this still leaves similar presentation elements, and their associated logic replicated for each page. This involves a lot of duplicated work, however, and even the .NET sample applications demonstrate these limitations. An alternative to this is removing all standard look-and-feel elements from the individual page level, wrapping them up in objects. This way, on-going design changes become simpler to manage, and implementing advanced functionality such as affiliate schemes becomes trivial.

This article demonstrates a way of abstracting presentation away from the individual ASP pages in enterprise-level web applications. In so doing, this allows more rapid development, easier application maintenance, and tighter integration with COM+ components.

Ever since the first version of ASP there have been arguments over what is the best way to produce ASP pages - whether to take it from an HTML point of view, and intersperse bits of ASP where necessary, or whether to treat the page as a program that simply outputs HTML through a buffer/stream. This article briefly compares the performance of three different methods when producing identical output, and provides an insight into what performance we can expect from the ASP.NET platform.

...

Note: this article appears to have disappeared from the Web...