<< Click here to display Table of Contents >> Navigation: Calpendo Configuration Guide > Bakery:

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 Calpendo. 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 Calpendo 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, Calpendo 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 Calpendo, 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 Calpendo. 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.

Biskit Format

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.

Biskit Format Definition

The syntax of the format is rather convoluted, and there will soon be an editor that will let you configure it without having to understand the syntax.

Dynamic Biskits

Use the Bakery to create new Biskit definitions. These will be dynamic Biskits. The user can use Calpendo 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 Calpendo 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.

Inheritance

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. When inheriting from the Booking Biskit Type make sure that the parent and child share a table in order to be able to mutate booking from one type to the other effectively, (this is the default).

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.

•If there is a booking sub-type defined, then:

1) Booking Rules will let you choose the sub-type they apply to. A Booking Rule that applies to a super-type will also apply to all descendant types too.

2) A Booking Rule that only applies to a particular subtype will only run on a booking that both is and was of that subtype or a descendant thereof. This means that if a booking is mutated from one subtype to another, if must be of a suitable type both before and after mutation for the Booking Rule to run.

3) Bookings can be mutated from one Booking super/sub type to another. Any property information not shared by the two Booking Biskit Types will be lost.