RAD Web development for Delphi applications: a comparative review of EWF, IntraWeb and ASP.NET

Part I  architectural overview

Abstract

This article surveys three leading web technologies - Express Web Frameworks from Developer Express, IntraWeb from AtoZed software, and ASP.NET from Microsoft (also available in Borland C# Builder)  that can be used in conjunction with Delphi to provide a RAD interface from your application to the internet.

This article is intended as an orientation to these three technologies - as they exist in September 2003 - for developers wanting to access RAD web development in conjunction with their Delphi development. New versions of the products may be released and further documentation may become available from the manufacturers, so be sure to also check with the manufacturers for the latest releases and information.

Introduction

For many years now Borland has been supplying powerful web technologies with Delphi out of the box. These offerings have included WebBroker and WebSnap. These technologies have been powerful and effective, with many industrial strength websites having been delivered using these technologies. Recently however, several third party RAD web development technologies have become available for Delphi developers, including Express Web Framework from Developer Express, IntraWeb from AToZed Software, and ASP.NET from Microsoft (also available in Borlands C# Builder) which have made it even easier to develop powerful, database-driven websites. These new technologies are a powerful extension to Delphi programmers abilities to rapidly build and deploy powerful, attractive, data-driven web applications.

The Delphi developer deciding to develop a new web application or to expose an existing Delphi application to the web, now faces a large number of powerful and attractive choices - and a considerable learning curve in assessing which technologies to use and in learning to utilize those technologies effectively. The purpose of this article is to simplify that learning curve by presenting an overview of and introduction to these technologies, aimed at Delphi developers.

General orientation

Each of the three technologies considered in this article try to make programming web applications just like programming Delphi applications. That is, to develop web applications, you drag and drop components on a web form, wire up the properties, code the events, and away you go. Very RAD! Just like using Delphi.

This is in contrast to other web technologies such as Cold Fusion, PHP, classic ASP, and Perl. Programming these is much like . . . programming the web. The focus in these tools is on fine-grained control of the HTML and JavaScript generated and sent to the browser, and the developer is intimately involved with the facts of web programming such as maintaining state and passing data around through URL, cookie and hidden form field variables (see below for explanations of these concepts).

In fact, for two of the new technologies considered here  Express Web Framework (EWF) and IntraWeb (IW)  it is not just like using Delphi, you are doing RAD development in Delphi to develop your web applications. EWF and IW extend Delphi so that you code your web application within the Delphi IDE, use the Delphi data connection components, and write your code (event handlers etc) in Delphi.

For the third technology considered here, Microsofts ASP.NET, you have to use a .NET language which at the time of writing includes C# and VB.NET but not Delphi. The good news however is that around November of this year Delphi 8 will be released and ASP.NET will be included as part of Delphi for .NET, and Delphi will be used as a language within ASP.NET. Until then, Delphi developers have the option of using Microsofts ASP.NET, say with Borlands C# Builder and the C# language to expose their Delphi data driven applications to the web. This review will consider the issues involved in using each of these technologies to create a data-driven website.

The Plan

The plan of this series of articles is to compare and contrast a number of issues across all three web application frameworks. These issues will include surveying the architecture and development metaphors, examining the quality of the documentation and getting started information or resources provided with each technology, and surveying the issues involved in developing data driven applications in each of the technology frameworks including core web application topics such as creating a security/login framework, how session management and state is managed, how scalability (the ability to add additional servers in a cluster or server farm to handle increasing load and to perform load balancing between servers) is addressed and, finally, how the application is deployed in each of these three technologies.

The present article focuses on an introductory overview of the architecture of each of the three approaches.

The basics

A brief word about state

We will consider state in more detail later in this article, but for those new to web development, the web is a stateless environment. That is, each request for a page is a separate request, and the HTTP protocol does not, in itself, remember where it was and what happened last time you made a request. Since you need to remember if a user of your website has put something in your sites shopping basket or not next time he or she requests a page, you need to maintain state in your web application.

The HTTP protocol provides for two ways of doing this: GET and POST. When a URL is requested, it may have a variable appended to it, for example

http://www.mysite.com?variablename=myvalue

In this case the URL variable variablename with the value myvalue is being appended to the URL request. This is a GET operation, as you get the page you requested.

Alternatively, if you have an HTML form with different form elements on it (say two edit fields, a hidden field and a submit button all in an HTML form) you click submit and the page is posted to the web server for processing. This, of course, is a POST operation.

In either case, a GET or a POST operation, variable name and value pairs are passed to the server along with the HTTP request and are subsequently available to the web server for processing. So for example, a GET request of http://www.mysite.com/secure/getinfo.aspx?userID=12689  would tell the server not only what page to serve, but pass in some information identifying the user session, which can be used to look up information on the user from a database.

A third way that state is maintained is through a cookie. A cookie is a piece of data that is stored on the client and your application can look for and use that data if it is there.

How web application frameworks work

A web application framework such as EWF, IW or ASP.NET works as follows:

1. A user requests information over the internet by typing a URL in their browser or clicking on a link
2. The web server receives that request and assesses what kind of page the user is looking for
3. If it is not a page it knows how to serve by itself, it looks for whatever technology is associated with the request
4. It passes the request to that technology
5. That technology processes the request and constructs an HTML page
6. The HTML page is passed back to the web server
7. The web server passes the HTML page back to the client
8. The user sees the HTML page in their browser

The Architectures

Now we have covered a little about how web applications work in general, lets take a first look at EWF, IW and ASP.NET architectures.

First a few words in general. As a developer in one of these web frameworks, you get a web form that looks rather like a Delphi form, and you drop components that look like normal Delphi components on it, wire up the components to each other, and code event handlers. The difference is that the form is not a normal Delphi form, and the visual components are not normal Delphi visual components: instead it is a special form that the web application technology knows how to convert into an HTML page when a user requests a URL, and the components are special components that go on the special forms that the web application framework knows how to convert into HTML elements when the page is turned into HTML and JavaScript and sent to a client browser.

So for example if you create a form with two web framework labels, two web framework edits and a submit button, this will be served up to a user in a browser as an HTML page with text instead of the labels, HTML edits instead of the framework edits, and an HTML submit button on an HTML form. You cannot use normal Delphi visual controls on your web application forms. But you can use non-visual controls, such as for example ADO data controls to connect to your database.

One or more web form pages of the right type for the web technology you are working with are created for you when you first create your web application, and you can add new web form pages as you go. The web enabled components are available for you from the Delphi palette under the appropriate tab(s) (eg EWF or IW tabs) for EWF and IW and similarly in Visual Studio.NET 2003 or Borland C# Builder for ASP.NET.

EWF architectural overview

The Home Data Module

One key to understanding both EWF and IW is to locate and understand their application object. In Delphi, there is an application object: the lines in a Delphi project source file

  Application.Run;

Or the command in a Delphi unit

  Application.Terminate;

are instructions to the application object. The application object encapsulates properties, methods and events relating to the operation of the application you produce as a whole.

In EWF, the equivalent to the application object is the Home Data Module (TcxWebHomeDataModule). The home data module is essentially a data module equivalent for web applications that is also designated as the place for storing all the application properties, methods and events. Properties such as the default page, whether or not to use cookies in maintaining state, and the timeout period for session variables are all set here. The Home Data Module properties, methods and events is an important place to spend time on when learning EWF.

The Web Page Module

The next important pit stop in understanding EWF is the Web Page Module (TcxWebPageModule). The Web Page Module is the EWF equivalent to a form in Delphi.

The Web Page Module is a receptacle on which you can deposit EWF components such as edits, grids etc in the same way that you deposit standard Delphi components on a standard Delphi form. The components dropped on the Web Page Module are wired up just as in a regular Delphi application. When the user requests an HTML page, this page is dynamically converted to HTML and served to the users browser.

The properties and events of this class are therefore the next place after the Home Data Module to spend time on.

The Event Hierarchy

EWF is highly object oriented, with a neat set of classes you can use. The first step therefore is to learn the class hierarchy and what the key events are and in what order they occur when a page is requested. Hidden in the EWF help file is an item The Order of Webmodule Events which is an excellent resource in learning EWF.

How EWF handles state

EWF handles state using either cookies or URL (GET) variables, depending on the property of UseCookie in the Home Data Module, along with hidden fields.

The cookie or URL holds a session ID, a unique ID to identify each user session as they track through the different pages in a website. This ID is used to retrieve the users Session object.

Sessions in EWF use the session object from WebSnap (TAbstractWebSession), and Request and Response objects from WebBroker (TWebRequest and TWebResponse). So the session object architecture should be familiar to many Delphi developers.

Session name=value pairs may be set for example as follows:

  Session.Values['Value'] := myWebEdit.Text;

 The hidden fields passed with each page are used by EWF to persist state about the components on the HTML page the user has been using (analogously to ViewState in ASP.NET). The developer can choose how components values get persisted using the ComponentsPersistent property of the web form.

Exposing other pages

When an EWF page is created, a function is created for that page, for example for a page MyPage

function MyPage: T MyPage;

begin

  Result := T MyPage (WebContext.FindModuleClass(TMyPage));

end;

This is generated to expose the EWF page MyPage by name and make it available to other pages in the web application.

Data Connectivity in EWF

EWF provides its version of data modules: a Web Data Module (TcxWebDataModule).

To use a data source in EWF, place your normal Delphi data connectivity components on the Web Data Module (for example an ADOConnection and an ADODataSet) and connect the data set not to a Delphi TDataSource but instead to a EWF Web DB Data Source (TcxWebDBDataSource). This can then be connected to an EWF grid or other data aware components in the normal Delphi RAD way.

The Home Data Module (discussed above) is a special case of a Web Data Module, and can therefore also double as being used as a Web Data Module while also performing its role as the application object for your EWF web application.

An EWF application

The source file for a standalone EWF application will contain lines like

begin

  Application.Initialize;

  RunTestApplication(WebApplicationName);

  Application.CreateForm(TLoginMainForm, LoginMainForm);

  Application.Run;

end.

Which is very similar to the initialization source for a normal Delphi application.

IW architectural overview

 IntraWeb has two modes  application mode and page mode. Page mode is to generate single pages, for example a dynamic report to include in an otherwise static website, or for pages that need to fit in to another web framework, such as WebBroker or WebSnap. Application mode is for full web applications developed using Intraweb, with application issues such as managing state handled for you by the IW web application. This discussion will focus on application mode.

The Server Controller

In IW, the application object that manages properties, methods and events relating to the web application as a whole is the Server Controller. A wide range of properties, methods and events are available from the Server Controller. A Server Controller is created for you when you create a new IW web application, and some time getting familiar with what the Server Controller offers is time well spent when you first start learning IntraWeb.

The IWForm (TIWAppForm)

In IW, the equivalent to a Delphi form is an IWForm (TIWAppForm). The IWForm is a receptacle for IW components such as grids, navigator bars, edits and so forth, which are dropped on the form and wired up just as in a regular Delphi application.

The IW metaphor

IW takes care to make RAD development as much like Delphi development and as intuitive to Delphi developers as possible. The difference is that only one form at a time can be shown (you can only have one HTML page at a time in a browser) and you cant use modal forms.

To move data around between forms, instead of needing to think about posting back to the server, using URL variables or using cookie variables, IW lets you do it analogously to moving data between one page and another in Delphi, so that you do something like

  SecondForm.webEdit1.Text :=  ThisFormWebEdit.Text; // set the next forms value
  SecondForm.Show; // show the next form

Similarly, the source for a IW project file might look something like:

 begin

  Application.Initialize;
  Application.CreateForm(TformIWMain, formIWMain);
  Application.CreateForm(TDataModule1, DataModule1);
  Application.Run;

end.

That is, very similar to a Delphi projects source code.

IW also allows you to use anchors on your HTML form in a manner similar to anchors on a Delphi app.

Data connectivity in IW

Data connectivity in IW is straightforward. IW gives you an option to create a datamodule when you create the IW project. This datamodule comes pre-configured with appropriate uses clauses and a function enabling you to use the datamodule in an intuitive and Delphi-like manner in a threaded web session environment.

After connecting your data connectivity components (eg an ADOConnection, an ADODataSet and a DataSource) to your datamodule, you can connect grids, etc on your IWForms to the datasource for data connectivity.

When using ADO, you must set the ComInitializtion property in the ServerController to ciMultiThreaded or you will get a "CoInitialize has not been called" error.

How IW handles state

An IW application manages state for you, so the developer does not have to be explicitly concerned with state and can write Delphi-like code, like

  SecondForm. SecondFormWebEdit.Text :=  FirstFormWebEdit.Text; // set the next forms value
  SecondForm.Show; // show the next form

 instead of passing information around in form, URL or cookie variables.

IW maintains an internal model of the users application state on the server. Like any other web framework however, IW has to handle state (transparently to the user) by passing around with each user request and with each page sent back to the user one or more variables to help it recognize a given user session. It can do this, transparently to the user, either by sending variables as hidden form variables, URL variables, or cookie variables - by default, URL variables.

IW in fact passes around two values to help it maintain state: a TrackID and a SessionID. The SessionID allows the IW server to recognize what user is making a request, and the TrackID is used to relate the state the client page believes it is in with the model of the application state IW maintains on the server.

To change the default method of IW passing the TrackID and SessionID values around, use the SessionTracking property of the ServerController.

Two more things need to be mentioned in relation to state.

Firstly, it was suggested above that for IW the ServerController is analogous to Delphis application object. While this is so, this is perhaps not the best metaphor for IW, because IW also has its own WebApplication object which represents the users application. That is, each user creates their own instance of WebApplication when they start their session. The ServerController therefore is the application object globally for all users, and the WebApplication object is the application object for a given users instance of a web application session.

Lastly, the ServerController contains a UserSession object that you can add members, properties and methods to. You can also code to create the TUserSession in the OnNewSession event. You could for example change the TUserSession declaration to:

TUserSession = class

Public

  Username: string;
  Password: string;

End;

and reference these properties elsewhere as

  UserSession.Username := Fred; // change the username
  Password  := Username.Password; // retrieve the password

The UserSession contains a .Data property that can be used to store a reference to an object (which is stored in memory on the server). You can create any object you wish and associate it with the user session through the UserSession.Data property.

The UserSession is declared in the ServerControllers class.

Exposing IW pages

The correct syntax for showing an IW form is

  TfrmMyForm.Create(WebApplication).Show;

Of course, you would much rather write

  frmMyForm.Show;

Because IW web applications are threaded, you need to create a reference to the form and add it to the user session, in the TUserSession constructor in the ServerController:

  TUserSession = class(Component)

  Public

    frmMyForm: TfrmMyForm;

    . . .

  End;

  Constructor TUserSession.Create(AOwner: TComponent);

  Begin

    Inherited;

    frmMyForm := TMyForm.Create(AOwner);

    . . .

  End;

In the unit for the form, add:

  Interface

  Function frmMyForm: TfrmMyForm;

  Implementation

  . . .

  function frmMyForm: TfrmMyForm;
  Begin
    Result := TUserSession(WebApplication.Data).frmMyForm;
  End;

Now in a given unit you can add the form you want to shows unit to the unit clause and reference the form in the normal Delphi way:

  Uses ufrmMyForm

   . . .

  TfrmMyForm.Show; // say in a button click event handler.

ASP.NET architectural overview

ASP.NET works in much the same way that EWF and IW work: the developer has an ASP.NET webform, and drops ASP.NET components on the form and wires them up. When the page is served on a web server and in response to a browser request, the webform is translated into HTML and JavaScript, and sent to the client browser.

The first thing to note about ASP.NET is that an ASP.NET web page it is explicitly divided into two parts: a presentation layer, and a code behind layer. Various components are laid out in the presentation layer, and the code is collated into code behind pages with one code behind page collating all the code for a given presentation page. This, of course, is exactly like a Delphi form and unit, except that it is a web form rather than a Delphi form, and you can place only ASP.NET web components on the web form.

The Web.Config file

ASP.NETs analog to the Delphi application object is, arguably, the Web.Config file. The Web.Config file is a central place in the application where preferences such as whether or not it can use cookies, setting session variable timeouts, and authentication and authorization settings are located.

Rather than being an object accessible only programmatically, the Web.Config file is an XML document.

As well as being potentially extensible by the web application developer, an ASP.NET config file generally may contain one or more of the following sections:

   <authentication>
   <authorization>
   <browserCaps>
   <clientTarget>
   <compilation>
   <customErrors>
   <globalization>
   <httpHandlers>
   <httpModules>
   <httpRuntime>
   <identity>
   <machineKey>
   <pages>
   <processModel>
   <securityPolicy>
   <serviceDescriptionFormatExtensionTypes>
   <sessionState>
   <trace>
   <trust>
   <webServices> 

So for example the SessionState section of the web.config file might contain

<sessionState
    mode="InProc"
    stateConnectionString="tcpip=127.0.0.1:42424"
    sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
    cookieless="true"
    timeout="20"
/>

Among other things, this is telling us that the web application is configured to operate without using cookies, and the timeout period for session variables is 20 minutes.

An ASP.NET web application can have one or more Web.Config files in its folder hierarchy, one Web.Config file per folder. Web.Config setting apply only to files within the current folder that the Web.Config file is located in, and any of its child folders. Web.Config files can therefore be used to setup different authorization and authentication rules for different folders in the web applications directory.

The Web.Config file in the web applications root folder has one Config file above it: the Machine.Config file, which sets configuration setting for all web applications on the computer (these can be over-ridden in individual Web.Config files in the individual web application directories).

The ASP.NET classes

ASP.NET is designed within the .NET framework, and to use ASP.NET is to use the .NET - and particularly the ASP.NET - classes extensively. Of particular interest to the ASP.NET developer therefore are the ASP.NET classes, such as those in the System.Web namespace.

Some of the classes relevant to the present discussion in the present article include the System.Web.UI.Page class, which corresponds to a web page and contains all the properties, methods and .event definitions for a web page, the System.Web.HttpContext class which encapsulates all HTTP-specific information about an individual HTTP request, the System.Web.HttpRequest class which enables ASP.NET to read the HTTP values sent by a client during a Web request and thereby retrieve  URL variables and form variables (such as hidden fields), that may have been sent with the request, and System.Web.HttpResponse, particularly for the Response.Redirect method for redirecting to another page.

The ASP.NET architecture is tightly bound with the .NET architecture, which is a large subject beyond the scope of this article. Some of the classes will be discussed in this and subsequent articles: to explore the .NET classes online, visit the Microsoft MSDN .NET framework documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWeb.asp .

How ASP.NET handles state

ASP.NET maintains state by passing around a SessionID, usually handled internally by ASP.NET. The sessionID is passed around via a cookie (the default) or a URL variable, depending on whether the attribute cookieless is set to true or false in the SessionState item in the applications Web.Config file (see above in the Web.Config section). If you choose not to use cookies, you will at times need to append URL sessionIDs as URL variables when placing internal links in your web application.

ASP.NET also passes around information pertaining to the current web page in hidden field variables, accessible as the ViewState object. See the System.Web.UI.Control.Viewstate property for more details: ViewState allows one access to a dictionary of state information that allows you to save and restore the view state of a server control across multiple requests for the same page.

When you just want to pass data from one page to the next and dont need to keep it around, you might choose to use Transient State. The Context object has a property items that can hold data (as a key-value collection). Because the context object is trashed after the request finishes processing, we can store whatever data we like here and it is cleared when the request is finished. Use Server.Transfer instead of Response.Redirect when moving to the second page, so that the context for the session is transferred with the redirection.

ASP.NET allows you to set and retrieve your own application variables (available globally to all users) and session variables (available to a given user) by means of the HTTPApplicationState and HTTPSessionState classes respectively.

So, for example, one might write for a page:

  Session[LoggedIn] = true;
  If (Session[LoggedIn] == true)
  {
      // do something
  }

To clear or remove session variables, use one of the following:

  Session[key] = null;
  Session.Remove(key);
  Session.Clear; // clears all keys.

See the System.Web.SessionState.HTTPSessionState class documentation for more details regarding the HTTPSessionState properties and methods.

Similarly for application variables, one may write

  Application[MyApplicationVar] = MyValue;
  MyLocalVar = Application[MyApplicationVar];

The use of application variables is generally discouraged in ASP.NET: generally, you should store application data in a database or in a system resource such as the Web.Config. This has a number of advantages in relation to scalability, robustness of application data to system crashes, etc.

In addition to using session or application variables, you can also store web application information directly in cookies, URL variables and hidden fields. 

For Cookies (quoting the MS documentation):

ASP.NET includes two intrinsic cookie collections. The collection accessed through the Cookies collection of HttpRequest contains cookies transmitted by the client to the server in the Cookie header. The collection accessed through the Cookies collection of HttpResponse contains new cookies created on the server and transmitted to the client in the Set-Cookie header.

MS provide the following example:

  HttpCookie MyCookie = new HttpCookie("LastVisit");
  DateTime now = DateTime.Now;
  MyCookie.Value = now.ToString();
  MyCookie.Expires = now.AddHours(1);
  Response.Cookies.Add(MyCookie);

Similarly, to retrieve the cookie one would use Request.Cookies, and manipulate the cookie collection to retrieve the data one wanted.

Passing data with URL GET variables is very simple, for example the link www.mysite.com/mypage.aspx?MyVar=23;

To retrieve the URL variable MyVar server-side following the request, one uses the request object QueryString property, eg

  ServerSideVar = Request.QueryString[MyVar];

For form fields (including hidden form fields) you use the request object form property, eg

  String MyValue = Request.Form[MyField];

Also related to state, ASP.NET has a sophisticated framework for authentication, authorization and other aspects of maintaining state for a secure environment. These aspects are considered separately in another article on login, authentication, security and authorization in IW, EWF and ASP.NET.

Data Connectivity in ASP.NET

Data connectivity in ASP.NET is much like in EWF or IW, except that in its plain state (i.e. without Borlands Borland Data Provider extensions in C# Builder or Delphi 8) it is much less RAD than EWF or IW.

Using ASP.NET in MS Visual Studio .NET 2003 Professional or Enterprise, you can drag and drop from the Server Explorer (which explores the databases and tables on your system) onto your web forms to create data connections and components (this part is quite RAD), but instead of wiring them together with properties, you have to manually code them, along the lines of:

  oleDbConnection1.Open();
    oleDbDataAdapter1.Fill(dataSet1);
    dgMyGrid.DataSource = dataSet1;
    dgMyGrid.DataBind();
  oleDbConnection1.Close();

where oleDbConnection1, oleDbDataAdapter1 and dataSet1 are the data connection components (analogous to an ADOConnection, ADODataSet and DataSource in Delphi) and dgMyGrid is a DataGrid.

Clearly this is much less RAD than just setting properties on components on a form. Borland have addressed this problem with their BDPs in C# Builder and presumably in the same fashion with the forthcoming Delphi.NET.

Conclusions

In this article we have reviewed the basic concepts of web programming and examined the basic architectures of EWF, IW and ASP.NET.

From this review it can be seen that EWF, IW and ASP.NET are similar in that:

• All three products use a Delphi-style RAD development metaphor, dropping components on a page and wiring them up with the page being converted to HTML when served to a browser
• All three products have an 'application' object (Home Data Module / Server Controller / Web.Config respectively in EWF / IW / ASP.NET)
• All three products have a page/form object
• All three products pass state around internally using a combination of URL variables, cookies, and hidden fields, and
• Each of the products make various degrees of effort to make sure session / state management occurs under the hood without the developer needing to be explicitly overly concerned with or even (particularly in IW) aware of it.

As well as the similarities, the products are also differentiated from each other in many ways. IW for example allows the use complex objects as part of session state and allows the use of anchors in your HTML forms. EWF has some very attractive and functional components such as its data grid. ASP.NET requires the use of a .NET language (e.g. C#, VB.NET) instead of Delphi and is based on the use of ASP.NET System.Web classes, part of the .NET framework.

This article should allow developers to rapidly orient themselves to and understand the EWF, IW and ASP.NET web technology frameworks and rapidly access any of these technologies.

In the next article, practical questions of how to program in each of these web frameworks is considered, including starting a new project using each web technology, adding a menu, and data connectivity and a data-aware grid to the project.

In subsequent articles it is intended to develop the application in each of EWF, IW and ASP.NET further by adding a login and security framework, and examine the scalability of these frameworks, look at deployment issues, and finally assess the pros and cons of each of these approaches for different developers needs.

Additional Resources

Further resources for learning each of these web frameworks are listed below.

EWF

The EWF website is at http://www.devexpress.com/products/vcl/ewf/index.asp.

White papers are available at the Developer Express website, and are accessible at http://www.devexpress.com/products/vcl/ewf/index.asp.

EWF also ships with an introduction PDF document and a help file.

Developer Express do not provide a trial version of the product but do have a 60 day no questions asked return policy after purchase, effectively enabling you to have a 60 day evaluation.

Developer Express have an EWF newsgroup at devexpress.public.vcl.expresswebframework .

IW

The IW website is at http://www.atozedsoftware.com/intraWeb/index.iwp

A number of IW articles can be found on the IW website at http://www.atozedsoftware.com/intraWeb/Education/Articles/index.iwp

IW has a trial version available for download, and ships with a manual in PDF and .hlp format as well as a getting started PDF document.

Falafel Software sells an IW training manual at http://www.falafelsoft.com/iw5course.aspx which is a useful addition to the materials available from IW.

Marco Cantus excellent Mastering Delphi 7 contains a chapter on IW (pp. 809-832).

IW have many newsgroups including one at atozedsoftware.intraweb .

ASP.NET

Internet resources

Online .NET Framework Class Browser:
http://www.csharpfriends.com/quickstart/aspplus/samples/classbrowser/cs/classbrowser.aspx

Microsoft MSDN Visual Studio.NET 2003 documentation online:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWeb.asp

Microsoft have many ASP.NET newsgroups including Microsoft.public.dotnet.framework.aspnet .

Borland have a similar newsgroup for C# Builder at Borland.public.csharpbuilder.aspdotnet.general

Downloads

A trial of C# Builder Enterprise is available from the Borland website.

C# Builder personal is available from the Borland website as a free product for non-commercial use.

Books

Some useful books for getting started with ASP.NET include

ASP.NET Kick Start (Stephen Walther)
Beginning C# Web Applications (Cazzulino et al)
Microsoft ASP.NET programming with Microsoft C#.NET Step by Step (Andrew Duthie)
ASP.NET Website Programming: Problem - Design - Solution C# Edition (Bellinaso and Hoffman)

Comparisons

Some web resources comparing the pros and cons of EWF vs. IW are at

http://www.brainendeavor.com/iwewf.html and
http://www.brainendeavor.com/mikengpost.html