Appster - Technical Information

Appster has been designed to enable SQL developers to create, maintain and deploy user interfaces rapidly and easily. The data types used within Appster mirror the data types available within SQL Server.

The interfaces are event driven (e.g. the user clicks a button, or double clicks an item in a listview). Events run macros. A macro similar to a SQL Agent job, but the types of steps are user interface related. More information about the way apps are constructed is below.

Structure of an Appster App

An app consists of an app object, one or more connections to databases, and a one or more forms which display/update data in those databases.

An app indicates which form is the startup form. This form is loaded first when the app runs.

	App	This contains the app name and description, and indicates which form to start the app with.
	Connections	A connection consists simply of a connection string (e.g. Server=myServer;Database=myDatabase;Trusted_Connection=True;). This is used to connect to a SQL database that you want the user to be able to view and update. A connection also has a name associated with it which is used throughout the app.
	Forms	There are one or more forms within an app. The app object defines the startup form. A form also has one or more modes associated with it which are indicative of how the form is being used. Forms use connections to access databases.

The entirety of an Appster app is stored in an Appster database in SQL Server.

Connections

Connection objects are simply objects that contain named connection strings, pointing to SQL Servers where you want to store data.

Forms

	Form	A form contains a design surface where the developer can place controls. It also contains queries that supply data to those controls. A form can also be parameterised to help select the data it uses, or modify its behaviour. In addition to this, a form must support one or more modes (ADD, EDIT, DELETE, VIEW). The behaviour of queries, controls and events can be made to vary depending on which mode the form has been called with. In this way, the same form can be used to insert/update/delete or view data. Additionally, events occuring within the form can run macros. For a SQL developer, a macro is similar in structure to a SQL Agent job. An event is something that the user does within the form, e.g. click a button, double-click an item in a list, etc. The types of control that may be included in a form are: Button Checkbox Date/Datetime/Time Image Label Floating point number Integer SQL driven dropdown SQL driven columnar list Textbox
	Modes	Forms support one or more modes (ADD, EDIT, DELETE, VIEW). A form mode allows the behaviour of some of the form's components to vary depending on the mode. For example, in ADD mode, the macro behind a form's OK button might call the stored procedure dbo.InsertCustomer, whereas in EDIT mode it might call dbo.UpdateCustomer. The form mode can be accessed via expressions that can be entered against properties of the form. Queries may also contain different SQL depending on the form mode. In this way a form may be used for multiple operations relating to the same data.
	Queries	A form normally has one or more queries to bring back data. Appster expressions can be embedded in a query; these are evaluated at runtime and can refer to any property of the form, controls, queries, parameters, or mode. Appster expressions lie within pairs of double at signs (@@). When a query is created it applies to all modes, but it is possible to add mode-specific versions. The mode-specific queries must return data with the same columns and types as that of the core query.
	Parameters	A form may be parameterised so that it is possible to modify the data it queries or the way it behaves. Parameters can be incorporated into Appster expressions throughout the application.
	Events/Macros	Events occur within a form when a user performs an action. Macros are built to respond to those jobs with a series of steps. A macro is very similar to a SQL job in construction. A macro can be made to respond only to an event for a specific form mode, or it is possible to have a "catch all" macro for all form modes.
	Macro Steps	Macro steps are the individual actions taken within a macro that either succeed or fail. Types of steps are: Close form - closes the current form. Open form - opens a form. Refresh control - refreshes the value shown in the control, using the value or expression assigned to that control at designtime. Refresh control list - where a control maintains a list (like a dropdown or a listview) this refreshes that list from the query that the control uses. Refresh properties - refreshes specified properties of controls within the form. Refresh query - this refreshes a query within the form. Select file - allows a user to select a filename to display in an ImageBox. Stored procedure - calls a stored procedure. User message - displays a message to the user. Validation - performs validation on the controls in the form and displays a message to the user if validation fails. Where a step type requires parameters or configuration, these can either be hard-coded values, or expressions to be evaluated at runtime.

Code Control >