This project is read-only.

Type Surfaces

A “type surface” is an abstraction of a typed object. Working with type surfaces, as opposed to actual instantiated objects, allows for a high-level of development, termed as 4GLX (fourth generation language extended). Type surface development results in 4GL language generation (i.e. C#) through the use of wizards and designers.

Anything can be a “type surface”. Type surfaces do not necessarily map directly to a .NET type and all of its underlying constructs. During code-generation, type surfaces eventually resolve to a .NET type or code representing the type. Examples of things that can represent a type surface are as follows:

• .NET types from assemblies, projects, or uncompiled code
• COM types
• WCF or other SOA service types 
• Entities from an Entity Framework model
• XML constructs or database objects (tables, stored procs, rows, etc.)
• Javascript objects, including JSON, AJAX, and ODATA
• Resources or files
• References to controls in ASPX or HTML files
• Redirections to types on different servers (appear as local surfaces)

Typed surfaces are provided by what is called an “AbstraX Provider”. The AbstraX provider provides a hierarchy of constructs in the form of Elements, Attributes, and Operations. The following definitions are provided:

Elements – Any type that can be instantiated (usually represented by a class or struct) or a container (namespace, field, property, or some other general classification) of either a type or type collection. Elements usually contain other "container" elements, attributes, and/or operations.  Interfaces are also elements because they represent a type that can be instantiated.
Attributes – Primitive types, including bool, char, numeric types, strings, Guids, and DateTime.
Operations – Methods, operators, delegates, constructors, and events.  Operations can be incoming (methods, operators, and constructors) or outgoing (events and delegates).

Typed surfaces can be assembled to form an application. During the design process, surfaces are mapped together using “surface paths” which are represented by XPath or LINQ queries. Due to the unknown nature of things during the design process, these queries can include “placeholders” that eventually have to be resolved, either during design, or via code stubs, which are TODO items requiring custom code.

Last edited Oct 9, 2011 at 9:16 PM by dezrtluver, version 18


No comments yet.