Program Conversion - 'Classic' Active Server PagesIt shares certain characteristics with PHP: both are server side scripting languages with a lot of built-ins components for database access, for example. PHP is built on a PERL foundation, whereas Microsoft's uses internal development tools. They both operate in a very rich broth of web servers, web clients, protocols, markup languages, scripting, and formatting elements. Winforms applications, whether VB6, Visual Basic for Applications/Access, or C#/Winforms, tend to be 'event driven', where a button click or menu item selection triggers a subroutine call. Many programmers in the early 1990s were used to 'stateful' systems such as Cobol or QuickBasic, where the program was invoked on a command line and maintained state until execution ended. Web based scripting was 'another world' in which one rendered a page, at which point the program ended. From the users perspective the screen was one step of a multi-screen program: web servers had no way of knowing that a particular submission was 'new' or 'continuation'. The entire state of the system was transmitted to the client and resubmitted on the next page navigation. Depending on how such systems are written, they are masses of 'spaghetti'. The emergence of .NET and web services is an attempt to create a programming environment that looks 'stateful' in the more classic programming sense, and allows the developer to organize their code in ways that looks more like Winforms and older procedural code. In doing so, it is possible to use the same programming constructions for Winforms, Web pages, services, 'console applications', and database packages. The server and client side scripting elements with classic ASP were not strongly typed, meaning that a variable could be a number at one point in the script execution, a string in another, and a recordset object in a third. C# and VB.NET are strongly typed, which means that a variable defined in one use remains that way. This is far easier to design, debug, and document. The benefits of moving away from 'classic' ASP are that the code base is far more maintainable and many of the classes are 'portable' between 'internal' functions (such as database packages and services) and ASP.NET web pages. One is no longer in a totally different world when creating web pages. The caveat is that the ASP.NET paradigm is heavy with overhead. The IIS server transports enormous amounts of state and security information between the server and browser. Users with limited bandwidth may discover this impedes productivity. Good programming can limit this to some extent, but not entirely. The return to the 'earlier days' takes the form of client side code invoking web services. In short, the program is written in Javascript (or VBScript or Silverlight or Flash) and invokes round trips to web servers only on a 'retail' basis (i.e., to query a group of records or a single transaction). This occurs through AJAX, SOAP, XML, or similar HTTP data exchange protocols. Program code is no longer principally operating on the server, but within the browser. Client side program code is dependent on browswer and plugin support, which is a minefield. Even cursory searches using 'Browser Compatibility' as a search term brings up the differences between Internet Explorer Quirks Mode and Firefox DOM (the latter uses the term Namespace Poisoning to describe coding practices that will run successfully on IE). Silverlight is a Microsoft product; Flash and Apple are in a big fight over support for the former on iPhones, and HTML5 is an attempt to bring order out of browser chaos. Some considerations governing the technology to use are 'internal' versus 'public facing'. High bandwidth internal LAN corporate use would favor ASP.NET. Low bandwidth wide area access in circumstances where use of certain browsers can be mandated, such a state agencies, would favor client side apps accessing web services. In situations where the world at large runs the program, most of the rendering needs to stay on the server side, which might favor retaining the 'classic' ASP host for efficiency, or ASP.NET for development convenience. Many larger 'classic' ASP systems have custom written VB6 libraries associated with them, and many of these contain Achilles Heels. There are good reasons why the issue is not explained in detail here, but in some cases it would make sense to fix the VB6 libraries and leave everything else alone. For those that feel like their system is way overdue for an upgrade, please call 210-734-5575 for free initial consultation. Or, eMail us at Info@ResourceLogic.net |