FILES:

UItest.exp		- export file
idf.asn			- asn file for IDF
uitest.asn		- asn file for application
usys7205.ini		- ini file for UNIFACE
solid.ini		- ini file for SOLID
xample_data.txt		- test data
UItest IDF.lnk		- shortcut for IDF
UItest APP.lnk		- shortcut for application
UItest SOLID.lnk	- shortcut for SOLID database

INSTRUCTIONS:

1) Create a folder call UITEST on your C: drive.
2) Amend shortcuts to point to the correct folders for these executables.
3) Start SOLID.
4) Run IDF, import file UItest.exp
5) Compile all central objects
6) Compile all forms 'U*' and 'X*', compile startup shell UITEST.
7) Run Application - when the file box appears select XAMPLE_DATA.TXT 
  (this will load test data. When the file box appears again hit CANCEL)
8) Form U_LIST1 will appear.

You are now ready to retrieve data.
The buttons on the right are for ADD, MODIFY, ENQUIRE and DELETE transactions.

Where a field has a button with a red upward-pointing arrow next to it, this signifies that 
a popup form is available to choose data - just click the button or double-click the field.

There is limited validation in the forms as most of it is carried out 
in the object service. I have created a global proc (VLDF_OBJSVC) and 
a new operation in the object service to make this possible.

All the forms use entities from the USER model.
All database access is via entities from the XAMPLE model.

DESCRIPTION:

The purpose of this prototype is to examine the possibility of using a separate application 
model for the User Interface (Presentation Layer) in order to hide certain complexities 
from the User Interface. All complicated logic is therefore in the object service. It should 
therefore be possible to make some kinds of changes to the physical database without having 
any effect on the forms.

The object service has been modified so that it will interface with the form through one 
entity (what I call the UI entity) but talk to the database through one or more actual 
database entities (what I call Real World entities). It therefore contains code to move data 
between the UI and RW entities.

The theory is that although the UI entities do not actually exist they should be treated in 
the forms as if they were real database entities.

Unfortunately it is not possible to return non-database occurrences from an object service 
to a form, so I have had to replace the normal <read> trigger with custom code. I also use 
dummy fields such as U_DBOCC to indicate database occurrences, and U_REMOCC to indicate 
occurrences which are in the process of being removed.

Another limitation is that stepped hitlists are not supported. This means that all the 
occurrences have to be passed back from the object service in one go. For large tables this 
would mean setting some sort of limit in the object service so that full table scans could 
be avoided.

I think that the idea of a separate application model for the User Interface has some rather 
interesting advantages, and it would be great if Compuware could integrate this idea into 
their standard product. It it were possible for an object service to pass back a constructed 
occurrence in the same way that it passes back real database occurrences then it would not 
be necessary to customise the <read>, <write> and <delete> triggers. One idea I have is to 
have a SET $DBOCC=TRUE command, but it probably will be more complicated than that.

Play around with this prototype and let me know what you think. Any suggestions or comments 
would be most welcome. If enough people show enthusiasm for this idea then perhaps we can 
persuade Compuware to take it on board.

Tony Marston

mailto: Tony@marston-home.demon.co.uk
mailto: TonyMarston@hotmail.com
