PixieEngine: Chapter 3

Chapter 4 - Batch-Submit Web Apps and Example PX2

Introduction.
Setup and Running of Example Px2
Commentary on PX2 and PixieEngine's batch methods
Other batch-submit issues: Item/Record Locks, User tracking

Introduction

Our preferred Web App architecture is the persistent "Field-by-Field" model discussed elsewhere.

But this chapter is about the ways we also support the "classical" web app model of Form-submission where:

The user's web page completely rewrites itself as a new document at every interaction with the webserver.
Web Page Forms are disconnected from the webserver during data entry and therefore any validation-during-data-entry relies upon on-page scripting.
At the brief change-page connection, which happens at the moment of Form-Submit, the contents of the Form are transmitted to the webserver as a string remarkably like a PICK dynamic variable.
User identification and user progress needs to be recorded and tracked on the server to work with a "non-persistent" user which repeatedly connects and disconnects during a "session"
The user freedom-of-movement, which goes with the Web's original intention as a repository of hyperlinked passive documents, is a nuisance or even major security concern and needs to be controlled.

The main advantages of Batch-Submit are:

Has the maximum reach of Web Browser clients, including able to run well on older versions. A case of simplicity on the client achieved at the cost of complexity on the server.
Can save on number of licensed ports required, with eg 20 to 50 users able to run on 10 licensed ports.

The main reason we support this model is so BASIC already coded for proprietary Batch-Submit engines like FlashConnect(TM), Coyote(TM) and RedBack(TM) can, on conversion to PixieEngine, have a wider reach. eg PixieEngine can emulate FlashConnect for Datastores other than D3.

The 2 support modules for Batch-Submit-Web-Apps in PixieEngine are supplied as source code.

pixie.asp is a Webserver script for the IIS Webserver, written in VBSCRIPT. It is the only Webserver file required.
basW3PixieLibBatch.bas is a set of utility functions written in VB. It is supplied as part of VB Example "Px2" installed in subfolder \AppPx2.

You also need to copy and adapt the routine Sub MainProcess in supplied class module pxappbp.cls

Setup and Running of Example Px2

There needs to be an IIS Webserver, or its junior version PWS, running on the same machine as an installed PixieEngine package.

Copy pixie.asp from folder AppPx2 to any WebServer folder setup with "script permissions". In production use such a folder should NOT allow "read permissions". We call our folder "PxBatchE"

If you are using a datastore other than the supplied MS Access, make sure you have database/account "testpxe1" setup and working, and either have user "john" setup with password "john", or edit the "john" and "john" in pixie.asp to whatever login/password you are using.

Point your browser to http://mywebserver/myfolder/pixie.asp
eg http://localhost/pxbatchE/pixie.asp

Example PX2 - Login and test run.

The app should give you a login/password form. This login/password is NOT the login for the DataStore. That has already been carried out on your behalf by a "secret agent" eg "john/john" coded into pixie.asp. This visible login is app-controlled and in this example is validated on table/file "PERSONS". Such a login-on-behalf approach means that login/passwords given to web app users are only of use for the web app and can not be misused elsewhere on the datastore.
FAQ-arising: "What about security on the 'real' login coded into pixie.asp ?".
There are 2 levels of safety here: (1) If setup correctly, users can run pixie.asp but can not read it ("script permission only") . (2) When you are registered as a paying customer, we activate pixiecrypt.exe which can encrypt these login/passwords.

After validation, a minimal menu is presented. Select "Customer Maintenance" which gives:

Screen Shot PX2

Click on the [Search] button to get a selection list from table/file CUST

Example PX2 - Search

Select eg KTS to get the editable display

[OK] saves any changes and returns you to a blank form
[Cancel] returns you to a blank form while making no changes to the record
[Exit] returns you to the Menu.

The example code demonstrates special points in the handling of TEXTAREA boxes (...Address:), dropdown combo boxes(Banks:) and CHECKBOXes (Credit Stop:).

Commentary on Px2 and PixieEngine's batch methods.

Input = Batch submission

pixie.asp receives name/value pairs for all named input elements on the user form. These can come via 2 slightly different transmission formats called GET and POST, but pixie.asp collects them all into a PICK-style dynamic variable to feed into PixieEngine as the "Command Line Sentence", which feeds into variable gsSentence. .

gsSentence has a format of up to 6 attributes separated by CHAR(254)
001 Multivalued field names - parallel with 002
002 Multivalued field values - parallel with 001
003 Multivalued server property names - parallel with 004
004 Multivalued server property values - parallel with 003
005 IIS Webserver User Session ID
006 (Optional) debug on/off switch

You can use PICK-like functions like LOCATE and EXTRACT on gsSentence to read values and other submission data. We have supplied some ready-made wrapper functions for you. eg:

field_value = PxGetVal(field_name)
eg
If PxGetVal("fx13") > "" Then 'credit stop tick in the checkbox
sdRec = RReplace(sdRec, 14, "1") 'credit stop
End If

or - W3GetVal = our FlashConnect-emulating variation
Call W3GetVal(field_value, field_name)
eg
Call W3GetVal(sRoutine, "w3exec"

Output = Write HTML replacement page.

Screen designs are kept as HTML template items in the database.
These can be complete designs, or sections of pages which will become part of a
complete page assembly.
In PX2, we use our table/file "PXHTML", but you can name your own.
eg for FlashConnect emulation you would keep these in a table/file called "W3HTML".

Our preferred method for substitutions is to include "placeholders" within the HTML
marked with square brackets and hyphens. We find this clear to the eye when editing
source code and also gives neutral behaviour in the 2 editing modes of raw-HTML vs
Visible Design. We then use our function PxSubst
eg
    Call PxSubst("[--FX0--]", sID) 'itemid
    Call PxSubst("[--FX1--]", Extract(sdRec, 1)) 'name
    Call PxSubst("[--FX2--]", Extract(sdRec, 2)) 'addr postal
    ...
    Call PxSubst("[--FX4--]", Extract(sdRec, 22)) 'email
    ...
    Call PxSubst("[--DISABLED--]", "")
    Call PxSubst("[--SEARCH_OPTIONS--]", "disabled")
    Call PxSubst("[--STATE--]", "UPDATE")

We also provide emulation for FlashBasic's wrapper functions based
on "##" as placeholder markers eg "##CONTENT##". These include functions named:
W3HTMLHeader, W3HTMLFormBeg, W3HTMLFormEnd, W3HTMLHidden, W3HTMLFooter
W3HTMLInsert, W3HTMLInit, W3HTMLSubmit, W3Input, W3Print

HTML Output is assembled as a string, and it can be worked with directly as variable gsHTMLWrite

Other batch-submit issues: Item/Record Locks, User tracking

Locks

In traditional MV-Engines, the item-locking functions, ReadU etc are of little use for batch-submit apps because they lose their locks as the user disconnects between actions. PICKBASIC Programmers have come up with ingenious solutions eg Phantom programs which hold locks-on-behalf while users are away.
With PixieEngine, you can reconfigure locking so locks persist when a user disconnects without explicitly logging off. This means that PixieEngine's RReadU etc will keep working for non-persistent apps.
Example PX2 begins every connection with "Sub MainProcess" in class-module "BP".

'010519 JPC reconfigure locks
Call ExecutePS("SYSTEM USERINST " & Extract(gsSentence, 5))
Call ExecutePS("SYSTEM LOCKTIMEOUT 1200")

"SYSTEM USERINST" identifies the user session for locking etc.
By default it takes the form "name*port" eg "john*53" , but here we are changing it to something more useful for a web app, the session.id supplied by the IIS Webserver and fed through to "PX2" as the 5th attribute of gsSentence.(aka TCLRead , Sentence()). IIS administers "session cookies" and so does all the work for us of identifying this user session at each connection. IIS is even clever enough to tell the difference between several browser windows being run by one multitasking user.

"SYSTEM LOCKTIMEOUT 1200" configures the lock to expire after 1200 seconds unless refreshed by a WWriteU etc, or renewed by another RReadU etc, or deleted by a WWrite etc or Release.

You should also include "Logoff" buttons in your app for explicit user exit and issue Release as part of that logoff process. Example Px2 has a hyperlink in its main menu which calls "Sub PxExit"

Public Sub PxExit()
'Clear files and any locks
Release
Call Delete("pxpersist", Extract(gsSentence, 5))
'
'Write final closing web no-page
gsHTMLWrite = "<EXIT><HTML>" _
& "<BODY onLoad=""JAVASCRIPT:window.close()"">" _
& "</BODY></HTML>"
End Sub

The "Delete" line above brings us to our next point, saving user state between connections.
Example Px2 keeps life simple by doing all item editing in one step with one web page form.
But that still exposes the danger of the user starting an edit, therefore taking out a lock, then
using the back button to get a blank form and start a new action leaving an unnecessary extra
lock hanging around. Hence the file/table "pxpersist" using the IIS Session.IDs as its Item.IDs

Items in "pxpersist" record a datetime stamp for the issue of a page. The page has the same datetime written into a "hidden field" so that stamp will come back with the form submission at the next connection. If the 2 datetimes match then all is OK. If there is a mismatch then (1) the user is given an educational message and bounced back to the main menu, (2) actions are cancelled and (3) any locks released. Any page that is not lock-critical, eg menus, searches, gets a blank datetime stamp which acts as the flag for skipping such checks.

We also use the device of running web apps in child windows spawned off a parent web page which is a passive introductory document. Spawned child windows can be configured not to have the "Forward" and "Back" buttons which cause many of the security concerns for web apps. By itself a spawned child window is no defence, but it cuts down the incidence of step-mismatches and therefore justifies handling them via simply and brutally stopping the user's current piece of work.

Code for spawning this kind of web app window ....
(1) in the <head> of the parent web page:>

(2) Hyperlink in the <body> of the parent web page:

<A href="JAVASCRIPT:start1('../pxbatche/pixie.asp');" >
<b>PX2: PixieEngine web app example using form batch-submit methods.</b></A>

Top Next = Appendix: Summary Reference Contents