CogSchema

Overview

As mentioned previously, Cogs can be treated as “untyped” nodes, used flexibly and casually, or as “typed” nodes, with an associated type from a schema.

CogSchemas stored named CogTypes, and can be associated with a Cog graph via the root node’s CogHeader. Each Cog can declare a typeName, and this is used with the schema to look up the actual CogType for that Cog.

CogSchemas can inherit from other CogSchemas via the inheritedSchemas list property; this allows re-use of common types, layering of types, and overriding of individual types as needed. A type present in a CogSchema will take precedence over a type of the same name in any inherited schemas. These parent schemas also have inheritedSchemas, allowing a rich mixture of types to be defined.

CogType

CogType is an interface, with a default implementation provided by AbstractCogType.

CogType defines these properties:

  • name - same as that used to look it up in the schema,
  • javaClassName - if the type is associated with a Coggable class, the fully qualified class name,
  • controlName - name of the abstract GUI control to use when viewing or editing this type,
  • controlScriptPath - path to a script used to generate a custom GUI control for this type

It also defines these methods:

  • void cleanStructureOf(Cog cog)
  • List<CogValidationException> validate(Cog node)
  • Cog createNode()

The method cleanStructureOf(Cog) cleans the given node structure as best as it can based on available information. This typically involves setting the datatypes of children nodes.

The method validate(Cog) validates the given node structure according to the rules of the type, and returns a list of validation exceptions, which will be empty if there are no problems with the structure.

The method createNode() returns a valid default instance of a node of this type. Generally this is done by copying a prototype value but may involve some other mechanism.

Table Of Contents

Previous topic

Coggable

Next topic

Examples

This Page