API Documentation
Interface contracts for PIComposer's EXPRESS-based data and project management
PIComposer's Dart API is split into two interface-only packages. Together they cover everything from a single EXPRESS record up to a multi-project workspace with templates.
The lower layer. Platform-agnostic contracts for EXPRESS schema definitions (TYPE, ENTITY, SELECT, ENUM) and for the IInstance data accessor with both imperative and declarative APIs. Also defines the Blockly template interfaces that power PIComposer's visual scripting.
Sits on top of schema_interface and adds the project-management layer: IStore, IProject, IModel and its IFC and STEP specializations, IReferenceModel overlays, backup and restore, and the cross-project ITemplateManager used by the Blockly workspace.
The picomposer_api workspace defines the Dart interface contracts that PIComposer applications use to work with data models described by the EXPRESS schema language (ISO 10303-11) — the foundation of engineering data standards such as IFC (Industry Foundation Classes), ISO 10303 STEP, and CIS/2. Because the contracts are interface-only, application code can stay portable across different backends: a native C++ desktop runtime, a server-side implementation, or an in-memory mock all expose the same Dart API.
Two packages are documented here. Together they cover everything from a single EXPRESS record up to a multi-project workspace with backups and Blockly templates.
The lower layer. schema_interface provides platform-agnostic contracts for inspecting schema definitions and manipulating EXPRESS data instances, plus the Blockly template interfaces that PIComposer's visual scripting system is built on.
ISchema, IEntityDescriptor, ITypeDescriptor, IEnumDescriptor, and ISelectDescriptor describe the static shape of an EXPRESS schema: its entities, attributes, enumerations, and select types.IInstance is the uniform handle to a single data record. It exposes both an imperative API (direct typed getters and setters such as getBool, setString, getInstanceByPath) for performance-critical code, and a declarative API (path-based access via PIAttributePath, and JSON-driven bulk updates via setAttributesByJson) for scripting, configuration, and template use cases.IBlocklyTemplate, IBlocklyProcedureTemplate, IBlocklyDictionaryTemplate, IBlocklySpatialTemplate, and related interfaces define the contracts that PIComposer uses to let domain experts generate, transform, and define models through visual block-based scripts.Read the schema_interface overview →
Sits on top of schema_interface and adds the project-management layer used by PIComposer applications: a singleton store, projects, models, backups, and the cross-project template registry.
IStore is the singleton entry point that owns a collection of IProject containers, manages license state, and exposes the cross-project ITemplateManager. Each IProject holds its own IModel instances and backup metadata for restore and purge workflows.IModel is the base interface for create, query, save, delete, batch, and path-based attribute operations. It is specialized as IIfcModel for BIM data (with spatial-hierarchy management across Project → Site → Building → Storey → Element, geometric representation contexts, property-set and material associations, and cross-model copying with composed dependencies) and as ISTPModel for ISO 10303 STEP data, supporting application protocols AP203, AP210, AP214, AP238, AP242, and CIS/2.IReferenceModel represents an immutable base model with a mutable overlay, recording added, updated, and deleted instances for non-destructive editing, audit trails, and revert or restore.ITemplateManager is the registry that backs PIComposer's Blockly workspace, supporting instance, procedure, transform, property-set, quantity-set, spatial, timer-event, user-defined-entity, and dictionary templates shared across all projects.Read the store_interface overview →
schema_interface defines the data primitives — schemas, descriptors, instances, attribute paths. store_interface composes those primitives into the higher-level concepts PIComposer actually uses day to day: projects, models, templates, backups. An application that needs the full PIComposer workflow typically depends on store_interface, which in turn depends on schema_interface. schema_interface is fully usable on its own if you only need to inspect or manipulate EXPRESS data outside the project workflow.