The Hub

Last edition to definitely use classic interprocess comms v2.097

WebHub v2.097 uses the original interprocess communication ("IPC") techniques. Thereafter we are actively transitioning to a new cross-platform model for use with Object Pascal on win32, Dot Net and Linux.

Configuration and WHTEKO syntax will remain as stable as possible during this transition.

In app config file, server profile identifiers may use (~AppID~) v2.097

This feature helps people who want more than one AppID to point to a single application-level configuration file, and the web application needs to run on both http and https, and the https domain is not always identical.

In that case, it will be necessary to define a server profile id for each distinct https domain. These should be named by using the AppID. Example: if the AppIDs are shopclothing and shopfood, the server profile ids for ecommerce could be named shopclothingssl and shopfoodssl. When these server profile ids are referenced in the application-level XML file, they would be listed as "(~AppID~)ssl" and the (~AppID~) would be expanded at runtime.

At this time, this is the only case of macro expansion, and it only applies to Server Profiles in the app config.

WebHubAdmin

GUI reviewed v2.097

There is a new Welcome panel which tells you some quick facts, helpful for WebHub technical support and troubleshooting. The ipc will be displayed as either "Windows mailslots" or "cross-platform" depending on which is in use. Right now (10-July-2008), the public files still all use the original ipc, Windows mailslots. In-house builds use the new cross-platform ipc.

The ZMContext for the machine is displayed (this was called "SetupID" in 1995-2004). Reference: http://webhub.com/dynhelp:view::catalog=Property,id=8078

The configuration branch is displayed; currently HREFTools\WebHub\cv004 meaning "configuration version #4".

The WebHub HTML syntax stage is displayed; currently 0214. This represents the highest syntax stage supported by the components. You can use any stage up to that number via a setting in the application-level configuration file.

Connected > Setups panel coming back to life v2.097

This panel lists all AppIDs defined on the machine and a right-click menu provides a few useful features: Cover App, Uncover App, Start instance.

Help menu v2.097

The cross-platform edition has a Connected > Current panel. For the Windows mailslots edition, use WebHubView to see the list of connected WebHub application instances.

WebHub Object Pascal Components

StringReplace renamed StringReplaceAll in ucString v2.096

Casual measurements show that the TPack version of StringReplaceAll is 20 to 30% faster than using SysUtils.StringReplace with rfReplaceAll and rfCaseInsensitive flags.

TPack function renamed from StringReplace to StringReplaceAll to distinguish it from the functions with the same names in the SysUtils and NativeXml units.

New: overloaded PosCI function which starts at offset v2.096

The ucPos unit now contains a case-insensitive Pos function which allows you to start at an offset other than the beginning of the string.

New: Cross platform synchronization routines v2.096

The tpSyncObjs.pas unit now contains the cross-platform code (win32, dot net and kylix)

New: tpStreams unit v2.096

Improved: whVarDel unit v2.096

Now TwhTempFileDelete component can be created independently from WebHub and any number of instances can be created. There is no need to instantiate a TwhCentralInfo component just to use the temp file deletion feature. A new property, InitialDelayMS, was added so that you can control the start time separately from the subsequent sweep interval. When this property has a zero value (by default), SweepDelayMS is used instead as in previous unit version. Code that depends on webInfoU was transferred to TwhVarsDelete.

Reminder: OnFileDelete handler is executed in the thread context. To access shared resources safely some synchronization means should be used.

Added content type CSS v2.097

Response.PrologueMode can now be proCSS, to make it easier to create dynamic css pages.

Enumerated types renamed for scan components v2.097

Until now, there have been duplicate enumerated types (e.g. dsPrior) used by various scan/grid components. Now, the types are shared when they are used in an identical way, and they are unique when they are used in a unique way.

Action required BEFORE opening your projects in Delphi IDE, as described below.

If you have used any scan components in your project, you should (1) use FuzRegex plus the provided script to fix all your DFM and PAS files and (2) Make sure that the uses clause of each PAS file has uses webScan (otherwise Delphi 7 (at least) can corrupt the DFM when it is opened in the IDE). FuzRegex is free at www.fuzregex.com and you will find an upgrade script in the download/share/2008WebHub area.

Here is a summary of the types as of WebHub v2.097 (30-Jun-2008):

webScan - defines types

  TwhScanMode = (dsByKey, dsByChecked);

  TwhScanButton = (dsbFirst, dsbPrior, dsbNext, dsbLast, dsbRedraw, dsbPost,
    dsbCheckBoxes, dsbInputFields);
  TwhScanButtons = set of TwhScanButton;

  TwhScanButtonsPos = (dsNone, dsAbove, dsBelow, dsBoth);

  TwhScanButtonMode = (bmJump, bmCaption, bmHide);

  TwhScanButtonStyle = (bsLink, bsLinkIMG, bsSubmit, bsSubmitIMG);

wdbScan - uses webScan

Session cookie support limited v2.097

Automatic session cookie support is limited to a cookie named exactly "session".

This setting in the application-level config is ignored: SessionCookieName.

It is questionable whether WebHub ever supported session cookies of alternate names. Look at WebHub version 2.098+ for resolution.

This setting in the application-level config is respected, for all cookies sent by the WebHub application: CookieDomainDefault.

Bug in v2.097 includes :443 in links to https pages

If you are using https with v2.097 please patch function TwhAppDynURL.GetLocSMU in webhub\lib\whcfg_App.pas as follows:

function TwhAppDynURL.GetLocSMU(sp: TwhNetworkServerProfileDetail): string; var Flag: Boolean; S: string; function ShouldForceAuthorityNow: Boolean; begin Result := False; if (NOT sp.AllowDynamicAuthority) then if posci(sp.HostActive, pWebApp.Request.Host) = 0 then Result := True; end; begin Result := ''; if Assigned(sp) then begin Result := ''; Flag := sp <> Self.FCurrentProfile; if ForceURLsUseScheme or sp.URLUseScheme or ShouldForceAuthorityNow or Flag then begin S := sp.LocUAuthority; if IsEqual(sp.Scheme, 'https') and (pos(':443', S) > 0) then S := LeftOf(':', S) else if IsEqual(sp.Scheme, 'http') and (pos(':80', S) > 0) then S := LeftOf(':', S); Result := sp.Scheme + { S = Scheme} '://' + { M = :// } //sp.LocUAuthority; { U = Authority } S; end; end; end;

Thanks very much to Sigi in New Zealand for bringing this to our attention.

A/V in WebAppUnUpdate

If you have customized whsample_EvtHandlers.pas and you get an access violation, coming from WebAppUnUpdate, please either comment out the pConnection.Active := False; line or make sure that you are a DFM based on the shipping whsample_EvtHandlers.dfm file. If you do not already have a utility for comparing pas and dfm files to see what has changed, consider ExamDiff Pro which we highly recommend (download from www.prestosoft.com.

Runners