1. You want your HD videos (16:9 aspect) to look like Cinemascope film (2.35:1 aspect). Image 1 below shows an example of this.
   
2. You've probably encoded your video for DVD/Blu-ray and tweaked those settings for online video and ended up with a video that has an aspect of 4:3 with the picture inside it with the normal aspect but with letterboxing (black bars on the top and bottom). Image 2 below shows an example of this.
   

Image 2: Picture is in HD aspect (16:9) but video is in SD aspect (4:3)

Crop your Cinemascope (2.35:1) Video.

Problems with Letterboxing your Videos

1. The video looks a whole lot better without letterboxing.
2. The picture quality is not as good as what it would be if you cropped your video instead of simply letterboxing.

Why the Picture Quality suffers

Image 3: Cinemascope aspect (2.35:1) picture and video. For Cinemascope video, crop the video to the correct dimensions.

Image 4: HD Video in HD aspect (16:9). Not letterboxing.

I

 

Why does something so simple end up being so difficult

1. The way your camera records and outputs video
2. The editing software you use and the abundant choices it offers for encoding, none of which really seem to apply to what you're trying to do.

HD, HDV, Full Raster

Pixel Aspect Ratio

Video Editing Software

The Solution 

• Choose Square pixels  - Do not choose Widescreen 16:9, HD Anamorphic 1080 or any other option
• Make sure you choose or set the correct dimensions (1920x1080 or 1280x720). For most online video hosting services that support HD video you'd probably choose to encode at 1280x720.

The image below shows and annotated version of Adobe Premiere Pro CS3's Media Encoder screen with the wrong settings.

 

Lets say, you were building a large system and one of it's functionalities was to be able to retrieve information about a certain FedEx package given the Shipment No. What you will do then, is use the "service" provided by FedEx to do this non-interactively (without human intervention) through your system.

Lets imagine that there are other similar "services" you could utilize in your system and you'd like to use these services rather than have to build them yourself. Essentially, you are building a system by "re-using" components that someone else has built and made available to you. It does not matter to you, what platform the service is running under or what tool was used to develop it. All you really care about is that you can find out how to use the service. This means your system is effectively decoupled from these "services" since you're not tied to using these services on a certain platform or using a certain development tool.

Lets sum it up now:

1. Re-useable "components".
2. Platform agnostic.
3. Implementation agnostic.
4. Following certain published specifications/standards.
5. Decoupled or loosely coupled.

SOAP for the Delphi developer

Why SOAP

Most distributed systems today use technologies such as DCOM and CORBA. Systems built with these technologies are:

1. Tightly coupled.
2. Often platform specific and therefore not interoperable.
3. Need to be configured on the client machines.
4. Have security issues, primarily when it comes to firewalls and the ability to get past them without having to punch holes through them to get them to function normally.

So SOAP sets out to achieve:

1. Interoperability.
2. Decoupled distributed systems.
3. Easy access through Firewalls etc.

Essentially, if you want to use a "service" you should not need to know the platform on which this service is running and nor should you be concerned about the implementation details. This is very similar to HTTP and Web Browsers. You can use a Web Browser today and surf the world wide web without the need to know what kind of server is serving you the web pages (platform, server vendor etc.) nor how it is serving you these pages (implementation - static pages, dynamic pages, ISAPI, ASP etc.). All you should need to know, is:

1. What are the methods of the service and parameters to these methods, and the types of these parameters (string, integer etc.)
2. If a method is returning some information, then what are the details of that (parameters, types etc.)

Wire Protocol

For those of you who are interested and know something about HTTP, a typical SOAP packet (including HTTP header) might look like this:

POST http://webservices.matlus.com/MyService HTTP/1.0
Accept: application/octet-stream, text/xml
SOAPAction: "urn:MyServiceIntf-IMyService"
Content-Type: text/xml
User-Agent: Borland SOAP 1.1
Host: webservices.matlus.com
Content-Length: 521
Proxy-Connection: Keep-Alive
Pragma: no-cache

<?xml version="1.0" encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/>
  <SOAP-ENV:Body>
    <NS1:MethodName xmlns:NS1="urn:MyServiceIntf-IMyService" SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
      <NS1:MethodParameter xsi:type="xsd:string">ParameterValue</NS1: MethodParameter>
    </NS1:MethodName>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Why HTTP as a Transport Protocol

WebService Description Language (WSDL)

1. Where is the WebService located (the URL)
2. What are the methods available
3. What are the parameters and type of these parameters
4. What is being returned (if anything) and what are the types

Ideally, given a WSDL file for a specific WebService, you should be able to build a client application that uses the services of this WebService. If the SOAP and WSDL specs are adhered to, you have all the information you need to start using the service. Similarly, when you build a WebService, you should make sure you adhere to the SOAP and WSDL specs and publish a WSDL file so others can access your WebService without a problem.

WebServices Today and Tomorrow

1. http://www.xmethods.com/
2. http://www.salcentral.com/

Please note, that things will not always be smooth sailing. This is due to a number of reasons, some of them are:

1. Some of these services were built conforming to earlier specs
2. Due to constantly changing specs. Delphi implementation may not always be current. I'm sure Borland on their part will do their best to release patches, fixes, upgrades etc. as soon as possible.

There are about 35-40 implementations of SOAP today. Each employing different methodologies or catering to different platforms and development tools. Most of them are free and most of them do their best to conform to the SOAP spec. At this point in time, differences in conformance are to be expected.

Let the games begin!

Delphi's SOAP Architecture and Implementation

Before I take you into the SOAP world as Delphi sees it, I'd like to touch upon one of the advantages of exiting distributed technologies such as DCOM, CORBA and Java RMI (Remote Method Invocation).

The one thing that these technologies have in common is the concept of a "Stub". In terms of COM and CORBA, this is a type library (IDL). One of the advantages of having a stub, besides the fact that one gets to see the interface of the object (it's methods and their parameters, properties etc.), is that the compiler can help detect errors in code at compile time. In most implementations of SOAP this is one aspect that is missing and developers that have no real need for some of the advantages that SOAP has to offer, see no point in using SOAP simply due to this fact.

Delphi however, has the best of both worlds. Delphi's run time type library has been enhanced and some new classes have been provided to allow for the way SOAP is implemented in Delphi. A brand new interface IInvokable two new classes TRemotable and TRIO and the Invocation Registry, make up the core of how Delphi implements SOAP. You can read about these in the on-line help.

You should also realize, that it is not required, that one accesses an "Object" in a WebService, even though SOAP has the word Object in it. Once a WebService receives a request for a certain method, how it implements this request is totally up to the WebService. It may or may not use an object in its implementation. In Delphi however, we use objects that implement Interfaces. This is not new to the Delphi developer, so when building WebServices with Delphi, you'll find yourself in familiar territory.

Method Invocation - Object Pascal style

Refer to Figure 1

1. A SOAP Request is received by a Delphi built WebService.
2. The SOAP Dispatcher recognizes this to be a SOAP Request and so, hands the Request over to the PascalInvoker.
3. The PascalInvoker, parses the request. After parsing the request, It figures out the class that needs to be instantiated and the method that needs to be called. It instantiates an instance of the required class and calls the appropriate method, sending it any parameters if applicable.

Similarly, when you build a client for the WebService, and your WebService returns an object, an instance of this class/Interface is automatically created for you. That's great is it not? Yes, that's great when you build a WebService and the client that uses this WebService. What about when someone attempts to use your WebService and he or she is using Java on a Mac for example? Here is the beauty of it. The Delphi implementation conforms to the SOAP spec. So when others call on your WebServices, they don't see anything untoward about the response sent back by a Delphi built WebService. It's the way that a Delphi built client interprets the SOAP message (This is handled for you by TRIO or Remote Interface Object) that is unique. In other words, when a Delphi built client application receives a SOAP message as a response to a request, it instantiates instances it requires. That's just the way it has been implemented. Similarly, if you build a Delphi client for a non-Delphi built WebService, you still work with objects if that is how the response gets interpreted. So it doesn't really matter what platform the WebService is running under or the tool used to build it. If you build a WebService client in Delphi you work with classes and interfaces.

The Interface Stub

What about the WSDL

I can image that a lot of the things I've said in this article don't make much sense. It seems to be out of context in a way. I suggest you read the next few tutorials and you'll find things will start to fall in place. Unfortunately, there is so much to be said about so many things, that I can't say much about one thing without including the other. So please bear with me.

1. The Number of Slave Web Modules for Multi-Module ISAPI project
2. Addtional Components (that are part of my package)
3. Output Folder (such as C:\inetpub\scripts)
4. The Host Application (used for debugging)

It should be noted that currently, only the default settings are implemented. That is you can build a multi-module ISAPI extension, you can choose the number of slave modules and you can determine the output folder of the compiled dll and the host application.

The expert then builds one Master WebModule (You can have only one Master WebModule per project), and one or more Slave WebModules (in reality, you don't want any slave modules, until you've named your Master Web Wodule. The reason for this will be explained later). There is also a New Slave Module Expert so you can add additional slave modules at a later time.

{**********************************************}
{  Multi-Module Support for ISAPI Applications }
{       Developed by Shiv R. Kumar (2001)      }
{              Master Web Module               }
{**********************************************}
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, MsMultiModule, HTTPApp;

type
  TMsMasterWebModule1 = class(TMsMasterWebModule)
    procedure MsMasterWebModuleCreate(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  MsMasterWebModule1: TMsMasterWebModule1;

implementation

{$R *.DFM}


procedure TMsMasterWebModule1.MsMasterWebModuleCreate(Sender: TObject);
begin
{***************************************************************}
{ If you add Slave WebModules to your project, be sure to       }
{ to include a call to the ModuleFactory of the Salve WebModule }
{ Example usage of ModuleFactory                                }
{ ModuleFactory(TMsSlaveWebModule2, True, True);                }
{***************************************************************}
end;

end.

The Dispatching Mechanism

The Master WebModule's dispatcher fields all requests made on the ISAPI Dll. The Master WebModule's dispatcher handles dispatching requests either to itself, or the other Slave WebModules.

Lets assume the name of the ISAPI dll is Multimodule.dll. A URL like this:

http://www.matlus.com/scripts/multimodule.dll/MyPathInfo

http://www.matlus.com/scripts/multimodule.dll/SlaveModule1/MyPathInfo

Session Management

The Session Management has been built with Remote Session Management in mind and will allow session information to reside across application and machine boundaries. (there is a Port and Server property available at design time as part of the Master WebModule). This feature has not been implemented as yet, but the hooks are in place.

  { TMsSessionManager }
  TMsSessionManager = class(TPersistent)
  private
    FSessionManagerIndentifier: string;
    FSessionManagerTimeOut: DWORD;
    FSessionBroker: TMsSessionBroker;
    FCurrentSessionID: string;
    FServer: string;
    FPort: string;
    FOnBeforeDeleteSession: TOnBeforeDeleteSession;
    procedure SetSessionIdentifier(const Value: string);
    procedure SetSessionManagerTimeOut(const Value: DWORD);
    function GetSessionManagerTimeOut: DWORD;
    procedure SetData(Value: Pointer);
    function GetData: Pointer;
    procedure SessMgrOnBeforeDeleteSession(Sender: TObject; SessionID: string; Data: Pointer);
  public
    constructor Create;
    destructor Destroy; override;
    function CreateSession: string; overload;
    function CreateSession(const TimeOutInMinutes: DWORD): string; overload;
    procedure ClearSessionInfo;
    procedure AddSessionInfo(const Name, Value: string);
    function GetSessionInfo(const Name: string): string;
    procedure DeleteSessionInfo(const Name: string);
    procedure DeleteSession;
    function GetSessionData: TStrings;
    property CurrentSessionID: string read FCurrentSessionID Write FCurrentSessionID;
    property Data: Pointer read GetData Write SetData;
  published
    property SessionTimeOut: DWORD read GetSessionManagerTimeOut write SetSessionManagerTimeOut;
    property SessionIdentifier: string read FSessionManagerIndentifier write SetSessionIdentifier;
    property Server: string read FServer write FServer;{ TODO -oShiv -cFuture : To be Implemented }
    property Port: string read FPort write FPort;{ TODO -oShiv -cFuture : To be Implemented }
    property OnBeforeDeleteSession: TOnBeforeDeleteSession read FOnBeforeDeleteSession write FOnBeforeDeleteSession;
  end;

The Session Management can use Fat URLs, Cookies or Hidden fields. The order of precedence is in that order. By default, the SessionIdentifier is sid, which means when you pass the session id back and forth between the browser and ISAPI, it should be in the form:

  
    http://www.matlus.com/scripts/multimodule.dll/somepathinfo?sid={12805C36-7ABE-4E4D-B6B5-31C3CA0B9BA8}
  

  
    http://www.matlus.com/scripts/multimodule.dll/somepathinfo?sid=
  

If you're using cookies, then it should be in the form

  
    sid={12805C36-7ABE-4E4D-B6B5-31C3CA0B9BA8}
  

If you're using a hidden field then the name of the field should be sid.

The Master WebModule has a property called SessionIdentifier. The value is this property is sid by default. If you change this property to something else, be sure to use this new value everywhere including the special tag .

  
    SessionManager.CreateNewSession;
  

The CreateNewSession method has a default parameter called SessionTimeOut. This property is defaulted to whatever the Master WebModule's SessionTimeOut property is. The Session Manager allows for each session to have it's own timeout. If you need to use this feature, you simply set the value at the time of creating a new session. The timeout value is in minutes.

When you create a new session, the SessionManager.CurrentSessionID is set to a GUID. You should hardly ever need to use this property, since where you need to put the GUID (in html) you can simply use the special tag .

When a Request comes in, the Session Manager automatically puts you in the context of the session. So any operations you do with respect to the Session Manager is with the session that was identified in the URL (or cookie or hidden field).

In practice, you never have to put the GUID in the URL yourself. If the html you send as a Response is in the form

  
    http://www.matlus.com/scripts/multimodule.dll/somepathinfo?sid=<#sid>
  

The Master WebModule will automatically replace the <#sid> tag with the GUID of the current session. So no matter where you put the <#sid> tag in your html, it will be replaced by the Master WebModule's in built PageProducer. This PageProducer understands some other tags as well. Such as:

• <#scriptname> is replaced by: Request.ScriptName
• <#sid name="NameOfSessionItem"> is replaced by the Value of the item
• <#sid name="sessioninfo"> is replaced by an html page listing all the name=value pairs of the current session

Tagging objects with Sessions

procedure TMsMasterWebModule1.MsMasterWebModuleBeforeDeleteSession(
  Sender: TObject; SessionID: String; Data: Pointer);
begin

end;

Since the Data property is a pointer, you are free to tag any object to the session. It could be an ObjectList or a DataModule that has other objects and Objects lists.

Additional Events

In addition to the events of a normal WebModule, the Master WebModule publishes the following events:

    property OnModuleHTMLTag: TOnModuleHTMLTag read FOnModuleHTMLTag Write FOnModuleHTMLTag;
    property OnException: TExceptionEvent read FOnException write FOnException;
    property OnSessionInvalid: TOnSessionInvalid read FOnSessionInvalid write FOnSessionInvalid;
    property OnSessionExpired: TOnSessionExpired read FOnSessionExpired write FOnSessionExpired;
    property OnBeforeDeleteSession: TOnBeforeDeleteSession read FOnBeforeDeleteSession write FOnBeforeDeleteSession;

  TExceptionEvent = procedure (Sender: TObject; E: Exception; var Handled: Boolean) of object;
  TOnSessionInvalid = procedure (Sender: TObject; SessionID: string) of object;
  TOnSessionExpired = procedure (Sender: TObject; SessionID: string) of object;

The Master WebModule has a few "helper" methods as well. They are:

    function ExtractMultipleRequestFields(const FieldName: string): TStrings;
    function GetRequestFieldValue(const FieldName: string): string;

The ExtractMultipleRequestFields coms in handy when you have a multi-select list box in a form and you need to find out which items were selected (The WebBroker framewrork does not support this out of the box). This method (given the field name) returns the StringList containing all the Values that were selected in the list box.

The GetRequestFieldValue makes processing Requests easier since it decouples code from the need to know the type of method (GET or POST) that was used. Frequently, one needs to process boths kinds of Requests in a certain action. Internally, this method determines the method type of the Request and uses either the Request.ContentFields property or the Request.QueryFields property and returns the Value for a given Name.

The (read only) property ModuleName returns the Path and File name of the ISAPI Dll. The read access method of this property uses the GetModuleFileName API.

Handling Special tags - A "Catch All" OnHTMLTag event (built in Page Producer)

Communicating between Slave WebModules and the Master WebModule

{**********************************************}
{  Multi-Module Support for ISAPI Applications }
{       Developed by Shiv R. Kumar (2001)      }
{               Slave Web Module               }
{**********************************************}
unit Unit2;

interface

uses
  Windows, Messages, SysUtils, Classes, MsMultiModule, HTTPApp, Unit1;

type
  TMsSlaveWebModule2 = class(TMsSlaveWebModule)
    function GetMaster: TMsMasterWebModule1;
  private
    { private declarations }
  public
    property Master: TMsMasterWebModule1 read GetMaster;
    { public declarations }
  end;

var
  MsSlaveWebModule2: TMsSlaveWebModule2;

implementation

{$R *.DFM}

function TMsSlaveWebModule2.GetMaster: TMsMasterWebModule1;
begin
  Result := TMsMasterWebModule1(MasterWebModule);
end;

end.

Notice that the expert has included the Master WebModule's unit (Unit1 in this case) in the uses clause of the Interface section. Notice also, that the (read only) property Master, returns a type TMsMasterWebModule1. This happens to be the class name of the Master WebModule at the time of creating the new Slave WebModule.

It is therefore recommended that one should first name and save the Master WebModule (class and unit) before creating additional Slave WebModule. The Expert will then use the unit name and class name when generating the code for the Slave WebModule class.

procedure TMsSlaveWebModule2.MsSlaveWebModule2WebActionItem1Action(
  Sender: TObject; Request: TWebRequest; Response: TWebResponse;
  var Handled: Boolean);
begin
  { Adding "ProductID" to the Current Session as received from a Posted Form }
  Master.SessionManager.AddSessionInfo('ProductID', Master.GetRequestFieldValue('ProductID'));
end;

Registering Slave WebModules

  ModuleFactory(TMsSlaveWebModule2, True, True);

To circumvent this issue in the OnHTMLTag event of your PageProducer, you could have code like this:

procedure TForm1.PageProducer1HTMLTag(Sender: TObject; Tag: TTag;
  const TagString: String; TagParams: TStrings; var ReplaceText: String);
begin
  if AnsiCompareText(TagString, 'sometag') = 0 then
    ReplaceText := 'Something'
  else
  begin
    if TagParams.Text = '' then
      ReplaceText := Format('<#%s>', [TagString])
    else
      ReplaceText := Format('<#%s %s>', [TagString, TagParams.Text]);
  end;
end;

Rule No:1 HTML should not be mixed in with code.

1. Makes the code cleaner and therefore more maintainable/manageable.
2. Speeds up the application quite a bit. (Due primarily to the intricacies related to string handling in 32 bit Delphi)
3. Allows the use of HTML designers (designers being either tools or people) to design the "templates", while you the programmer can code the business rules. (yea right if only we were that lucky!)
4. Allows for changing the page layout of your web sites/applications without the need to re-compile the application.

The TPageProducer has a property called HTMLFile. You should use this property to load up static html templates at run time. If you're having problems loading up files/images at run time due to "path" issues, I suggest reading the article titled - Relative/Virtual Paths Explained.

Defining a Language

I won't go into HTML/JavaScript specific things here, but rather talk about how templates should be designed from the perspective of using a TPageProducer to "process" templates.

Rule No:2 Define a minimal "tag language" that you use over and over again across applications.

1. Streamlining your templates
2. Making your templates more readable/maintainable/configurable
3. When working in a team where there are HTML designers (people) they start to understand your "language" and can start to apply it in templates they build for you.

So what is this language about? It's simple really. It's tags that you "re-use". Tags that have "attributes" that when set control the "behavior" of the processing. Kind of like an object that has properties and setting different properties change the behavior slightly. The more generic you make your tags, the more reusable they become.

1. We use Request.ScriptName wherever we need the "path" of our application to be included in things like hyperlinks, form actions and the like.
2. The action attribute of forms.
3. The target attribute of forms.
4. The src attribute of images.

All your page producers should "understand" this tag (Or at least one PageProducer in your application should). In the OnHTML event you could have code like the following:

If AnsiCompareText(TagString, 'scriptname') = 0 then
  ReplaceText := Request.Scriptname;

Similarly for the "form" tag <#form action="" target="" method="">

if AnsiCompareText(TagString, 'form') = 0 then
  ReplaceText := Format('<form action="%s" target="%s" method="%s" />', [
    TagParams.Values['action'], TagParams.Values['target'], TagParams.Values['method']]);

This kind of tag gives you the flexibility to define attributes in your template while also giving you the flexibility to change them later. Granted, if you're using templates, you could simply change them there (the hard coded value of a form action say). But believe you me a time will come, when you wished you used tags in the template! For example, you might need to change either the target or the action of the form depending on some condition. Instead of having two similar templates (that need to be synchronized each time there is a change) you can have just one.

Rule No: 3 - Get used to coding your html in xhtml style. That is all tags and attributes in lowercase, all attribute values within double quotes and all empty tags closed.

Designing Templates

1. All <input> elements will have one and only one tag.
2. All <select> elements will have one and only one tag.

Of course one could go a step further and say that we need have only one tag for ALL controls. This is the kind of thing I do personally in fact. But I have a component that does this for me (and a lot more). But for this discussion we'll stick to the 2 proposed above.

We won't be talking about the html aspects of the design here (the look and feel). We'll only look at the tags involved. The tags shown below can satisfy our needs for any type of &lg;input> tag we need in our forms:

<#input type="etText" name="foo" value="" maxlength="10" />
<#input type="etPassword" name="foo" value="" maxlength="10" />
<#input type="etHidden" name="foo" value="" maxlength="0" />
<#input type="etCheckBox" name="foo" value="" caption="bar" checked="false" />
<#input type="etRadioButton" name="foo" value="" caption="bar" checked="false" />

It goes without saying that this is only one tag. As a result, we can process these tags using one conditional statement in our code. It's the attributes that make all the difference. The code that processes these tags might look like this:

type
  TMsHTMLElementType = (etText, etPassword, etHidden, etComboBox, etLookUpCombo,
    etMemo, etCheckBox, etRadioButton, etButton, etLabel);
...
...
...
...

implementation

{$R *.dfm}

uses TypInfo;

procedure TForm1.PageProducer1HTMLTag(Sender: TObject; Tag: TTag;
  const TagString: String; TagParams: TStrings; var ReplaceText: String);
const
  sHTMLTextInput = '<input type="%s" name="%s" value="%s" maxlength="%s" />';
  sHTMLCheckRadio = '<input type="%s" name="%s" value="%s" maxlength="%s"%s />nbsp;%s';
var
  sChecked: string;
  sRadioOrCheck: string;
begin
  If AnsiCompareText(TagString, 'input') = 0 then
    case TMsHTMLElementType(GetEnumValue(TypeInfo(TMsHTMLElementType), TagParams.Values['type'])) of
      etText    : ReplaceText := Format(sHTMLTextInput, ['text', TagParams.Values['name'],
                    TagParams.Values['value'], TagParams.Values['maxlength']]);
      etPassword: ReplaceText := Format(sHTMLTextInput, ['password', TagParams.Values['name'],
                    TagParams.Values['value'], TagParams.Values['maxlength']]);
      etHidden  : ReplaceText := Format(sHTMLTextInput, ['hidden', TagParams.Values['name'],
                    TagParams.Values['value'], TagParams.Values['maxlength']]);
      etCheckbox,
      etRadioButton:
        begin
          if AnsiCompareText(TagParams.Values['type'], 'etCheckBox') = 0 then
            sRadioOrCheck := 'checkbox'
          else
            sRadioOrCheck := 'radio';
          if AnsiCompareText(TagParams.Values['checked'], 'true') = 0 then
            ReplaceText := Format(sHTMLCheckRadio, [sRadioOrCheck, TagParams.Values['name'],
              TagParams.Values['value'], TagParams.Values['maxlength'], ' checked="checked"', TagParams.Values['caption']])
          else
            ReplaceText := Format(sHTMLCheckRadio, [sRadioOrCheck, TagParams.Values['name'],
              TagParams.Values['value'], TagParams.Values['maxlength'], '', TagParams.Values['caption']])
        end;
    end;

end;

Similarly, you could define a tag that (depending) on an attribute can become either a Combo Box or a List Box. Better yet, if it's a list box, whether it's a multi-select list box or a normal list box. You can then go on to define a "data aware" combo box tag that will allow you to define the stored procedure to use to populate it, the "name" field, then "value" field and so on.

Sooner or later you're going to want to build a specialized descendant component that does all of this for you thus allowing you to reuse your vocabulary. That's what object oriented programming is about. So don't let anyone stop you!

One could go in all sorts of directions with this concept. For instance, you could define a template that has a special tag like so:

<#embedtemplate filename="">

buried deep inside it somewhere. The filename attribute is the name of another template, a template for an html form for instance. That way, the same basic template can be used over and over throughout your system. You could even determine the embedded template to use at run time. Or the template to use is determined by the value of a parameter in the URL or content fields of a posted form. It's up to you really. But where ever you do, make sure the concept is re-usable and is generic enough to be reusable. Give a lot of thought to naming your tags and the attributes they can/should have.

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="<#statevar name="StyleSheet">
    <title><#title></title>
    <script>
    <#script>
    </script>
  </head>
<#body>
  <table border="0" cellpadding="0" cellspacing="0" width="100%" align="" valign="">
    <tr>
      <td colspan="2">Page Header goes here</td>
    </tr>
    <tr>
      <td><#embedtemplate id="1" name="LoginForm"></td><td><#childtemplate></td>
    </tr>
    <tr>
      <td colspan="2">Page Footer goes here</td>
    </tr>
  </table>
</body>
</html>

A Template that Shows Database information

Take a look at the template below:

<table>
  <tr class="tableheaderrow">
    <td class="tableheadercell" align="center" style="font-size: smaller;">Customer ID</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Company Name</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Address</td>
  </tr>
  <tr class="tablerowrow">
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="CUST_ID "></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="COMPANY_NAME"></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="ADDRESS "></td>
  </tr>
</table>

Given a dataset that holds a record, the code to process this template might look like this:

  if AnsiCompareText(TagString, 'fieldvalue') = 0 then
    ReplaceText := MyDataSet.FieldByName(TagParams.Values['fieldname']).AsString;

The next thing that comes to mind is; "Ok, now how do we do this for a record set that contains a number of records?". This is probably a more common need than the previous one. So let's explore this case a bit. The solution is to break up your templates in "snippets".

1. A Main "Table" template
2. A Header Template
3. A Row Template
4. A Footer Template

The Main "Table" template essentially, has "place holders" for the other templates. This template might look like this:

<table border="0" cellpadding="0" cellspacing="0" width="100%" align="" valign="">
  <tr>
    <#tableheadertemplate name="SoAndSoTableHeaderTemplate">
  </tr>
  <#tablerowtemplate name="SoAndSoTableRowTemplate">
</table>

Notice that the "insertion" point where "Rows" are inserted does not have the <tr> tags around it. Unlike the tag for the header.

Using the earlier templates as a starting point, the header template would look like this:

    <td class="tableheadercell" align="center" style="font-size: smaller;">Customer ID</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Company Name</td>
    <td class="tableheadercell" align="center" style="font-size: smaller;">Address</td>

The Row Template would look like this:

  <tr class="tablerowrow">
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="CUST_ID "></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="COMPANY_NAME"></td>
    <td class="tablerowcell" align="center" style="font-size: smaller;"><#fieldvalue fieldname="ADDRESS "></td>
  </tr>

Notice that the "row" template has the <tr> tags, while the "header" template does not.

I hope this article has shown you how best to utilize the power of the TPageProducer component.

Web sites on the Internet are known by their Domain Names, such as www.Microsoft.com / www.Datasourceinc.com. Domain names actually resolve to an IP address such as 207.176.25.218. So actually, to get to the DataSource web site one could actually type in http://205.177.16.151 and the browser will take you to the site. But remembering numbers such as these is not easy and so Domain Names were introduced. Domain Names (that end in - .com or .org) have to be registered with an organization called INTERNIC. There is an annual charge of $35 for this registration and the Domain Name has to be unique! When one types in a domain name, the browser actually goes to Internic's DNS (Domain Name Service) server, that resolves the Domain name to an IP address from a lookup database and gives the browser the IP address of the web site in question. The browser then goes to the IP Address. The IP address is also a unique Address. No two servers on the same network can have the same IP address. The WWW can bee looked at as one big network. Each server on the Internet can be uniquely identified by its IP address. So it follows that typing in the IP address will be a lot faster than using the domain name.

Transfer Control Protocol / Internet Protocol. This is the protocol used by the WWW. For this protocol to work we have what are called clients and servers. These are software applications that can "talk" to each other. The server application has to be up and running and "listening" on a certain port number (just a number from 1 to 65535). The client application that wants to talk to the server application must use the same port number and must know the IP address of the server application. Once a connection is established between the client and server, the two can communicate.

Services such as HTTP, FTP, POP, SMTP are what are called "known services" and therefore use a fixed port.

HTTP: Port 80

FTP: Port 21

POP: Port 110

SMTP: Port 25

Again, the names of the service can be used instead of the port No., such as http://www.datasourceinc.com actually resolves to http://205.177.16.151:80. This really tells the browser and the server to use the HTTP protocol on port 80. Since port 80 is the default port, one need not specify it (and so one normally does not). One is free to use any port for "unknown services". On any one server machine/PC one can have one and only one server application listening on a port. So for a given IP address (that uniquely identifies a PC), you can only one server application listening on a given port.

Web servers are both a physical machine as well as a software application that is listening on port 80. An FTP server is another application (also called service or more accurately TCP/IP service) listening on port 21. So you could have both, an HTTP server (Web server) and an FTP server on one single machine, since they use different ports.

Also one can build ones own TCP/IP applications that "talk" across the Internet using a certain port. The server application needs to be listening on a certain port and the client application needs to know the IP address and the port to use. Only clients can connect to servers. Servers can not initiate a connection by themselves. Servers typically "service" multiple clients and so the name - Server. To learn more about TCP/IP and protocols take a look at th eTCP/IP tutorials in the Tutorials section on my web site.

One can have multiple web site on a single machine. The web server (application) has a way of understanding which site is required by which HTTP request it receives. Web servers have what is known as the "root" folder. The root folder is the equivalent of the "C:\" folder of the hard drive. This root folder can be any subfolder on the HDD but the server needs to be informed of it's root folder. The web server in turn can not "see" anything before this root folder. This is to provide for some form of security. The root folder is the starting point for the web server. It can "see" all the folders and subfolders in its tree. Most folders are read access only but some are read/write/execute access. Normally, one of the subfolders of the web server is /scripts (or /cgi-bin) and it is only this folder that has read/write/execute access.

The home page is an HTML page in the root folder by the name default.htm. So when a surfer types in the URL (Uniform Resource Locator) for your web site, the web server (application) looks for a file in its root folder by the name default.htm and sends it back, to the surfer's browser via TCP/IP or more accurately the HTTP protocol which is nothing but a layer over the TCP/IP protocol. The most common and the easiest way to have a web site is to have numerous HTML pages as physical files on the server that are hyper-linked to help navigate through the web site. This kind of site is also called a static web site. Each time you want to make a change to the web site, you have to edit/change/add the HTML pages you want. For large sites this can be a nightmare to manage. Most sites are a mix between dynamic pages and static pages. If some of your web site's information needs to come from a database of some kind, these pages need to be generated dynamically (on request) by some form of script (application programs). Examples are CGI, ISAPI, ASP etc. For your information, the contents of this page are stored in a database. When you linked to this page, an ISAPI application extracted the information for this particular page from a database and dynamically converted the information into HTML format and sent it back to you, for you to see in your browser. In fact this web site is 100% dynamic, which means there are no static HTML pages on the server's hard disk. All content resides in a database and is servered to you dynamically.

Since HTML is very "static" and does not "respond" to the surfer of your web page, Dynamic HTML was introduced. DHTML is a combination of HTML and JavaScript or VBScript. Combining HTML with a scripting language allows for a more dynamic or active web page. Due to scripts embedded within the HTML document the browser is able to respond to certain events, similar to normal event driven programming tools. Events such as mouse moves, mouse clicks etc. are exposed by the browser to your HTML page and the HTML page can in turn "react" to these events. In this way, the HTML pages produced seem to be more responsive or alive than regular static (HTML) pages.

One needs to know one of the scripting languages in order to create DHTML pages. Further, DHTML is supported only by version 4.0 of both IE and Netscape. JavaScript is supported by IE and Netscape while VBScript is supported only by IE. The level of support differs between these browsers. This means that certain DHTML pages may not "work" on all browsers unlike pure HTML (HTML version 3.0 is supported by most browsers in the market today).

ActiveX is Microsoft's answer to Java applets. Once again ActiveX is supported only by IE version 3.02 onwards, and not by Netscape. Java applets are supported by both IE (3.02 and above) and Netscape versions 3 and is also Windows platform dependent. Besides the incompatibility issue there is a big security risk with ActiveX on a web page. The ActiveX control or document is fully capable. In that, it can access any resource on the PC. It has full access to the Win32API and all of the drives and folders. Ironically, it's these "benefits" that are the downfall of ActiveX. ActiveX is better implemented in an Intranet environment where the platform is the same, the browser versions are compatible and the ActiveX document comes from a trusted source (such as the internal IT department).

Java applets on the other hand are platform independent. But once again, it due to it's benefits that it has limitations. The fact that these applets are platform independent means that these applets can not make use of certain functions (API or the UI capabilities) of the operating system. The moment an applet tries to use platform specific features it looses its platform independence. For a Java applet to run in the browser the target machine needs to have the JVM (Java Virtual Machine) installed on it to be able to interpret the Java byte code in the applet. The JVM comes in many flavors and versions and is most times the cause for applet misbehavior on certain machines. Once again, Java Applets are best suited in an Intranet environment where the environment can be better controlled. Java Applets that are very basic in functionality and made for earlier versions of the JVM are and can be used in Internet applications provided of course that the browsers' version understands them.

Seeing that static HTML is very limited in what it can do, web server developers designed a way to allow programmers to extend their capabilities by providing server extensions. Server extensions in their simplest form a scripts that are executed on the server side with the help of interpreters. Examples of these are Perl and Rexx and later came JavaScript and VB script. Scripts allow for server side processing and return HTML pages. Scripts allowed for data access on the server side as well. So with the help of a script, one could query a database local to the server and in return, send back the result set in the form of HTML that the web server sends back to the requester. CGI (Common Gateway Interface) is the interface that most web servers understand. This interface allows web pages to send parameters to the script via the URL and the script processes these parameters and sends back the information via the standard I/O.

Win-CGI is specific to the Windows platform and Microsoft's Internet Information Server (IIS) and other compatible web server software. Here, the parameters are sent to the CGI application (normally a .exe file) via an .ini file. The script in turn writes data (the result) in this same .ini file which the web server reads and send back to the requester.

ISAPI (Internet Server Application Programming Interface) is specific to IIS and other IIS compatible web server software. Microsoft, went a step further (after Netscape introduced NSAPI - Netscape Server API) to provide more functionality and faster response by introducing the Internet Server API. Using this API, one has access to the web server's functionality. ISAPI application can be written with any tool that produces a compiled native machine code output. The compiled code is generated in the form of a DLL (Dynamic Link Library). This DLL is loaded into memory by the web server upon the first request (by a web page) and is kept in memory until the HTTP service is stopped or the machine is re-booted. ISAPI applications have no limitations on the number of parameters that can be passed to them (CGI applications have a limit of 255 bytes). Further, the way the data is transferred or handed to the ISAPI is much faster than the way CGI applications are pass information to and fro.

CGI applications are generally .exe files. This means that each time a request is made via the web server, an instance of the exe is loaded into memory and the data passed to it. This exe file is later unloaded once its job is done. So, if you had 100 surfers hitting your site simultaneously and making the same request, you'll actually have 100 instances of the CGI application, all loaded in memory at the same time. The system resources required for such a feat are phenomenal. Besides that, the time it takes for an instance of a CGI application to load and initialize causes a performance hit.

ISAPI applications on the other hand are DLL files. A DLL is run in the process of the calling application (in this case the web server application) and only one instance is loaded. The ISAPI DLL has to be built in such a way as to incorporate safe multi-threading. For each request, the web server spawns a new thread and does not need to load and initialize the ISAPI application. Since there is no load time involved and multi-threading is employed instead of multi-instancing, the system resources required are at a minimum and the response times are far less than those with CGI applications.

On the other hand CGI applications, by virtue of the fact that they are .exe files and don't need to cater for multi-threading are far simpler to build than ISAPI applications. Also, since an ISAPI runs in the process space of its calling application has the capability of crashing the calling application if errors are not handled internal to the DLL. Basically, this means that if an ISAPI DLL crashes, it takes the web server application down with it. This means all web-sites hosted by that web server will not be accessible until the machine is re-booted. This is one of the primary reasons ISPs (Internet Service providers such as AOL, Erols etc.) do not allow ISAPI applications.

Web applications or browser based applications use the browser as the front end with some form of web server extension application (CGI/ISAPI/NSAPI/ASP) running at the back end. Ideally these applications are a very powerful technology. They are zero configuration thin clients. Which means, the surfer has to do nothing on his/her PC to be able to use these applications. They are platform independent as well as browser and browser version independent. But in reality, these applications are never zero-configuration. Due to the speed with which technology is moving and the inability of individuals to keep upgrading their machines, operating systems and browsers, the zero configuration thin client can not use the new and emerging technologies. Thus browser- based applications will always have to built to conform to earlier versions of operating systems as well as browsers.

Besides the compatibility issues stated above, browsers, by their very nature are isolated from the PC, such that they can not access the resources of the machine they are running on. Therefore they are very limited in their capability to integrate/interface with existing systems or use the Os's API or GUI capability for better and more functional/feature rich UIs. Even in corporate environments, where operating system versions and browser versions can be controlled, these kinds of applications are not the best suited for such a need as 9 times out of 10, these applications will need to interface/integrate with existing systems in the corporate environment.

Browser based application therefore tend to be used for very simple needs.

These are applications built as normal PC based applications but access data over the Internet. Effectively, these applications use the Internet infrastructure as their network. This allows for remote connectivity to data from anywhere in the world. Similar to browser based applications. With the advantage of being able to access the resources of the machine on which they are executed and thereby allowing for integration with other existing corporate systems.

On the GUI side, these applications are fully capable, thus allowing for "standard" features such as drag/drop, tree-views and list-views (like in windows Explorer [not Internet Explorer]). This not only gives the user of the application an interface s/he is familiar with but also saves on training needs. The UI is not limited in any way.

Advantages and Disadvantages of Web based and Internet based Applications

Each technology has its place. Where a simple data entry, data view and reporting capability is required, browser based applications are very well suited. On the other hand, if you require the full functionality and capability of a standard PC application as the front end, but need the "remote" connectivity as well, then Internet enabled applications are ideal. In most corporate scenarios, you will find a combination of browser based and Internet enabled applications. For the simple user or "on off" user (surfer) you'll find a web interface and for the power/corporate user you'll find Internet enabled applications.

When the user/surfer is unknown, that is the browser type, platform etc. in not known or controllable, a browser-based application has its advantages. On the other hand, if cross-platform is not an issue and the environment can be controlled to a high degree, then Internet enabled applications are the right choice, due to their interfacing/integrating capability and UI capability.

Figure 1: Showing the Process of a client request in terms of a browser and web server

As shown in Figure 1:

1. The client sends a request to the web server via an HTTP GET or POST method.
2. The connection persists while the web server spawns a new process to handle the request.
3. The CGI application processes the request, builds the output and sends it back to the web server.
4. The Web server adds the protocol (HTTP) headers and passes all of it back to the requesting client.

ISAPI

Looking at Figure 1 again, let see what would happen if the CGI executable were to be replaced by an ISAPI extension application.

An ISAPI application, does not spawn a new process after it has been called the first time by a request. Rather, it runs in the server's process space, thus reducing both memory overhead and startup time. Only a single copy of this server extension is loaded and is then shared if additional client requests for the same application come in. Furthermore, once an ISAPI application is loaded into the process space, it stays loaded until IIS is stopped and restarted, or until some unspecified period when IIS decides to unload it. This means new requests for the ISAPI will get much quicker responses and resource utilization is kept low due to a single instance model, rather than a multiple instance model in the case of a CGI.

All in all, this speed improvement is a strong argument for using ISAPI to do anything that requires back-end server processing over a CGI. If one were to look at CGI scripts or any other scripting mechanism, its easy to see that these types of applications will perform far slower than even CGI executables as they are interpreted rather than compiled. One should also note, that the interpreter needs to be loaded in memory to do its job as well. So resource utilization is much higher in scripting mechanisms such as, Perl, ASP etc. and performance is poor due to the interpreted nature.

As per Microsoft

Designing High-Performance ISAPI Applications

ISAPI is the highest-performance interface for Web applications. If you create an ISAPI extension or filter, it will outperform ASP scripts or even components performing similar tasks.

However, the inherent speed of the ISAPI interface does not mean that you can ignore performance and scalability considerations. Indeed, ISAPI cannot utilize much of the application support services provided by ASP and COM. If you would like your ISAPI application to maintain session state, for instance, much of that session-state functionality would have to be implemented by you.

Quote continues...

Here are some suggestions for improving the scalability and performance of your ISAPI extensions:

• Avoid ISAPI filters, unless adding an ISAPI filter is absolutely necessary to your application architecture. You should especially avoid filters that perform processing on raw incoming or outgoing data. If you determine that a filter is absolutely necessary, be sure to carefully optimize the main code paths through the filter event notification code.
• Create your own worker thread pool, so that the main I/O threads can be freed to accomplish other tasks. This option is available only for ISAPI extensions, and not for ISAPI filters. For more information about how IIS processes requests, see IIS Request Processing. A sample that demonstrates a worker thread pool, implemented in an ISAPI extension, is available in ISAPI Examples.
• Consider using asynchronous operations and I/O completion ports, when feasible. IIS supports asynchronous reading and writing by using the I/O completion ports, available in Windows NT 4.0, and Windows 2000 or later. Depending on the type of I/O operations being performed, asynchronous operations can make better use of the CPU time available, and generally work particularly well when implemented using a worker thread pool.
• ISAPI extensions should use the Win32 TransmitFile function, exposed by the HSE_REQ_TRANSMIT_FILE ServerSupportFunction.
• Use Connection: Keep-Alive headers. Keeping persistent HTTP connections will provide better performance than using non-persistent connections, in most cases.
• Minimize need for thread synchronization by maintaining state information with the request context. If thread synchronization is required, make sure that critical sections are kept short.
• If your ISAPI application uses the heap intensively, consider other heap alternatives. Intensive use of the Windows? heap can cause resource contention. Several memory allocation alternatives are worth exploring, including:
  • Heap Partitioning, accomplished by creating multiple custom heaps, in addition to the default process heap. Each custom heap would then be controlled by a separate, non-global lock, and lock contention would be reduced.
  • Cached Allocation, which involves using custom allocation operations that operate at a middle layer between the object users and the heap. Calls to the Win32 heap are made infrequently, and only for large memory blocks. These blocks are then subdivided and managed by the custom allocator.
  • Stack Allocation, using the C run-time function _alloca to allocate memory for your objects on the stack instead of the heap. This method is feasible only for relatively small objects, because the space available on the stack is limited. In addition, your newly allocated object will be available only within the current functions, or functions called by that function. Once the current function returns, the storage allocated on the stack will be lost.
• Object Encapsulation, accomplished by simply incorporating a buffer as a member data structure of a class. This buffer is then used for tasks that would otherwise require accesses to the Win32 heap.
• Avoid using global locks within your ISAPI, if possible. Global locks can often adversely affect scalability.

An intersting page on the Microsoft site compares ASP and ISAPI performance, scalability etc. Check it out here

ISAPI and the Web Application Architecture

• Highest performance: A properly planned, developed, and used ISAPI-particularly ISAPI extensions-can outperform any other Web application technology available currently for IIS.
• Low-level control: From an ISAPI extension or filter, you have access to the whole array of Win32 API functions. For instance, you can create a customized worker-thread pool for your ISAPI extension to speed processing, using the Win32 thread functions to access the native thread functionality of Windows 2000.
• Often, ISAPI extensions and filters are best positioned to solve critical bottlenecks in your Web application-especially if you expect scalability to be an important issue for your application, due to high traffic v