Biskit Definitions
Contents
It can be a bit confusing to talk about definitions of properties. So let's start by using an example, and looking at the definition of the Session Biskit that is used to store information about who is using Exprodo DB. A Session has the following properties:
Name |
Data Type |
Description |
user |
Biskit |
The user whose session this is |
started |
Date Time |
The date/time when this session started |
lastUsed |
Date Time |
The date/time when this session was last used |
IPAddress |
String |
The IP address of the user's computer |
sessionID |
String |
An ID used to represent the session when the user's web browser sends requests to the server |
userAgent |
String |
The web browser's reported user agent information. This tells you which web browser they are using. |
Now, the BiskitDef for a Session must contain information about each of the above six properties. For each one, it has to know the Data Type, its name, the label used to display it and so on. However, the Session BiskitDef must also store meta-properties of Session itself, such as its type ("Session"), its database table name and the text used to display the name "Session" in a number of contexts.
There are quite a few different types of property that a Biskit can store, and these are described in the next section, Property Definitions. The meta-properties of a Biskit are much simpler, and here is what they look like in the editor:
Here is a description of what each meta property is for:
Name |
Data Type |
Description |
Type |
String |
This is the internal string that represents the Biskit's type. |
Parent |
BiskitDef |
Some Biskit's extend others (in the programming subclass sense) and this indicates the Biskit Type that is the parent of this one. |
Group |
String |
Only used by the Bakery itself, use any group name required on a BiskitDef. Then filter the BiskitDefs that are displayed by setting a filter Biskit group. |
Primary Key |
Integer |
This is the unique database identifier for the BiskitDef. |
Version |
Integer |
Used internally to manage changes to the BiskitDef. Increased by one every time a change is made. |
Name Property |
String |
The name of a property on the Biskit that can be used to represent that Biskit. This is not used if Format is specified. Important to do this or the Exprodo DB chooses the name for each instance of the Biskit that is created. |
Sort Property |
String |
The name of the property that should be used to sort Biskits of this type. |
Version Property |
String |
The name of the property that should be used to hold the version number of the Biskit. Only those properties of type Int with an Automated Property Type of Create & Update will be used. |
Created Property |
String |
The name of the property that should be used to hold the created date and time of the Biskit. Only those properties of type Datetime with an Automated Property Type of Create or Create & Update will be used. |
Updated Property |
String |
The name of the property that should be used to hold the last modified date and time of the Biskit. Only those properties of type Datetime with an Automated Property Type of Update or Create & Update will be used. |
Creator Property |
String |
The name of the property that should be used to hold the creator of the Biskit. Only those properties of type Biskit with Biskit Def set to User, with an Automated Property Type of Create or Create & Update will be used. |
Updator Property |
String |
The name of the property that should be used to hold the updator of the Biskit. Only those properties of type Biskit with Biskit Def set to User, with an Automated Property Type of Update or Create & Update will be used. |
Format |
String |
Lets the user specify a format for representing the Biskit when there isn't a single property that contains the name. See below for more details. |
Abstract |
Boolean |
True if there can be no instances of this Biskit Type, only instances of subtypes. |
Enumerable |
Boolean |
True if there are likely to be a large number of Biskits of this type, too many for display in a list. |
Hierarchy Property |
String (property name) |
Some Biskits represent a hierarchy. For example, there might be a Location Biskit, where the Location "Oxford" is a child of the Location "England", which is a child of "United Kingdom" which is a child of "Europe". A hierarchy is a Biskit that has a property containing a Biskit of the same type, representing the parent in the hierarchy, and also a property containing a set of its children. So, Europe has children "United Kingdom", "France", "Germany" and so on.
When a user selects a Biskit from a hierarchy, they are presented with a "tree" widget making it easier for them to choose the right item. For this to work, Exprodo DB needs to know which property contains the children. This must be a OneToMany Biskit property. |
Label Lower |
String |
Text used to display the Biskit Type, when the context calls for a lower case label. |
Label Upper |
String |
Text used to display the Biskit Type, when the context calls for an upper case label. |
Labels Lower |
String |
Text used to display the Biskit Type, when the context calls for a plural lower case label. |
Labels Upper |
String |
Text used to display the Biskit Type, when the context calls for a plural upper case label. |
Null Value Label (Read Only) |
String |
The label to show for Biskits of the type represented by this BiskitDef when that Biskit is null, and we're displaying in a read only context. |
Null Value Label (Read Write) |
String |
The label to show for Biskits of the type represented by this BiskitDef when that Biskit is null, and we're displaying in a read write context. |
Tooltip |
String |
Text to display as a tool tip describing this type of Biskit. |
Visibility |
Nobody, Root, Admins, Users or Everybody |
Indicates who can see that this Biskit Type exists. |
Storage Mechanism |
Static or Dynamic |
Indicates whether this BiskitDef is defined statically, in the source code for Exprodo DB, or dynamically in the Bakery. |
Shareable Table |
Boolean |
Shareable with sub-types if you want dynamic sub-types to be able to share this BiskitDefs database table. |
Allows Deletion While Referenced |
Boolean |
Allows Deletion if you want Biskits of this type to be deletable even while something references them. |
Table Name |
String |
The name of the database table for storing instances of this BiskitDef. The table name for a static BiskitDef cannot be modified, since it is defined in the source code for Exprodo DB. Also, not all static Biskit Types will have a table associated with them, for example if they are abstract or if they are only ever used as components of another BiskitDef. |
ID Column Name |
String |
The name of the column which provides the primary key into the table. In a Master-Slave combination these must be different in the Master and each Slave. |
Set the Name property meta-property of a Biskit to specify the name of the property that should be used to represent the Biskit. when something more complex than just the label is required. For example, a user has a login name, a given name and a family name, but any one alone can not be used to display the person's name. Instead, a combination of them is required. This includes being able to use the Biskit Type.
|
Use the Bakery to create new Biskit definitions. These will be dynamic Biskits. The user can use Exprodo DB to handle create, read, update and delete values in any table with the following restrictions:
•There must be an integer-valued primary key
•The new dynamic Biskit must contain only dynamic properties. This means that, if an extra property is added to the dynamic Biskit, the database table must contain a column for it. If the column doesn't already exist, then Exprodo DB can create the column for the user, or the user can create it.
Dynamic Biskits can be used in exactly the same way as static Biskits.
Creating Biskits
Biskits can have links to each other via properties, also some meta-property values of a Biskit depend on having appropriate properties, which means that creating Biskits and their properties is not a linear event. i.e. the user cannot start at the beginning and hope to move step by step to the end saving completed Biskits as they go. Sometimes the user will need to create a Biskit with its properties, save it with errors, create a second Biskit, save it with errors, go back to the first Biskit, set up new information now available in the first Biskit because the second Biskit has been created, re save the first Biskit, go back to the second Biskit, update that with information from the first Biskit and save. This means when creating your own Biskit's make sure there is a plan on how they are going to connect together.
Biskits can inherit from other Biskits, inheriting all their properties To do this set the Parent meta-property to be the Biskit the new Biskit is inheriting from.
When a Biskit inherits from another Biskit it needs to be specified whether both Biskits will share the same table or whether the new Biskit will have a table of its own for its own properties (those it does not share with the parent). This is done by setting the Share Super Type Table meta-property. A Biskit can only share the table of the Biskit it inherits from, if that Biskit has the Shareable Table meta-property set to allow it.
This may seem very similar to copying a Biskit, but there are certain major differences:
•When editing the child Biskit the parents properties are not seen.
•After adding a property to the parent the child automatically has access to the new property.
•When changing any meta-properties of properties in the parent the child Biskit will automatically inherit the changes. (e.g. Default Value).
•A property in the child cannot be created using the same name as a property in the parent.
•If the child Biskit has a sibling (same parent Biskit) and they all share the same table, do not create properties of the same name in both child and sibling. (Currently there are no checks for this but it will cause problems in the database).
•Automatic emails applied to a super-type will automatically apply to any sub-type.
•Permissions applied to a super-type will automatically apply to any sub-type but may be overridden in the sub-type.