DataFace Products » Knowledge Center

Let's assume you have an existing database.

You run our Application Manager against your existing database.
You will be able to bring up the runtime and see all your tables and views, and most of their interrelationships.
How good this first application looks depends on the quality of your database. For example, if its column names are cryptic or if many foreign keys and other constraints are missing, you will have to return to the Application Manager and make some cosmetic improvements.
Then you divide up the proposed screens into those that are simply for database maintenance, and those that are heavily used for data entry. You will concentrate on the second group, and we will help you to improve the most critical ones so that your people understand the power and flexibility of the DataFace framework.
You will probably want to add some menu items for transactions which affect many database tables or even the world outside the application. You are free to abandon the standard out-of-the-box appearance and design your own User Interface elements. Obviously you must respect certain interface contracts so that your elements can be loaded and displayed by the framework. You should consider commissioning DataFace to produce a few samples to your specifications so that your people have good models to work from.
Back to Top

You will want to bring in business logic that the framework could not possibly know from its inspection of your database.
Your application is an executable which references the DataFace framework. The framework raises more than 100 events to your executable. Event procedures are a very familiar paradigm to all .NET programmers.
If you require logic to be available to several different applications, you can place it in an "extender" project (DLL), which is referenced by the framework.
Data validation is the most frequent reason that you add logic. The framework performs validation based on data type and CHECK constraints from the database. You can write additional validation using JavaScript^™, regular expressions, built-in functions, event procedures, or extender methods.
All our standard screen elements observe published interfaces. You can replace any of them with a class of your own as long it implements the expected interface. The class must be placed in an extender project.
The framework is intended to as open as possible to customization, let us know any unforeseen needs.
Back to Top

Each user object can contain an unlimited number of security tokens.
By default, the user object is retrieved from a table called DFCUsers, but you can write an event procedure to construct it any way you like.
The Application Definition Language can specify which security tokens are required to read, insert, update each data field, and to execute each menu item, toolbar button, and hyperlink. The AppDef file is encrypted (except in the DBA Edition).
The user object also contains an indicator of the user's expertise level. This can be used to hide privileged screen elements independently of the security system.
Back to Top

User input is validated and type checked to whatever degree of strictness the application specifies ("white-list input validation"). However, everybody recognizes that gaps in validation can occur, therefore we apply "black-list validation" to disallow semi-colons, comments, or the keyword UNION in any dynamic SQL statement. We intend to adopt the OWASP ESAPI codec when a stable release for .NET is available.
You can review SQL statements in an event procedure. Also, you are free to substitute stored procedures if you wish.
Back to Top

The ability to enter a row with an effective future date (so that a price increase can be entered in advance).
The ability to enter a row with an expiration date (so that sales of a seasonal product can be discontinued according a predetermined plan).
The ability to "soft-delete" a row (so that historical data is not lost to the app).
The ability to carry multiple old revisions of a row (so that a foreign key to an obsolete shipping address is retained).
The ability to add comments to any row.
Row-level security.
Clustering of related rows (divisions of a customer which are treated as separate entities for sales purposes)
Simulation of a live environment for test purposes.
Storage of multilingual text.
Old-fashioned record locking.
Better processing of update collisions.
Back to Top