Introduction

The Office Abstract located in cm/abstract/office aims to make it easy for customizations to build their own commercial interior system. Some main classes and features of this abstract are: 

• Panel – Concept of real-world panel. Including panel frame (snapper class), panel skin (core object class), panel tile (core object class), panel junction (snapper class). An abstract panel is represented by combining these key components.
• Worksurface – Abstract snapper class of worksurface. 
• Behavior – Classes that define a specific functionality of a snapper. 
• AccessoryEnv – Factory-like class that controls the accessory creation behind the scenes. 

Panel

A real-world panel is represented by the following key components in the abstract office framework:

Frames and junctions are snappers that interact with each other in CET, and they correspond to the physical objects (panel and junction) in real life. Frames always connect to junctions, and during the frame snapping behavior, the user can change the type of junction by moving the mouse.

Frame

PanelFrame (cm/abstract/office/panelFrame.cm): snapper class that communicates with other panel frames, Junction Snapper, and Worksurface. You can directly extend from PanelFrame if you only wish to get the panel and junction snapping behavior, without having to deal with tile split/merge.

SkinPanelFrame (cm/abstract/office/skinFrame.cm): snapper class that holds skin and tile related functionality. Extend from this class if tile split/merge behavior is required.

Skin

PanelSkin (cm/abstract/office/panelSkin.cm): a class that sits in panel frame class through OfficeFrameProxy. Skin manages a set of panel skin items, which mainly tiles, for tile merge, split, drag functionality.

Tile

PSTile (cm/abstract/office/panelTile.cm): object that represents panel tile object.

Junction

PanelJunctionSnapper (cm/abstract/office/panelJunctionSnapper.cm): snapper class of junction that communicates with its neighbor panel frames.

PanelJunction (cm/abstract/office/panelJunction.cm): object class serves as a proxy class that contains the logic for the junction snapper. For example, instead of a snapper calling its own updateConnectors() method, it will instead be handled inside PanelJunction class, It will also hold important information such as properties, connectors, and geometries.

Worksurface 

Top

WorksurfacePath: path is the system to draw worksurface PGC graphics, it also creates worksurface edge PGC graphics, connect type, and worksurface edge ID. It also offers a sequence of worksurface connections, where each connection knows its adjacent neighbor.

Path fields:

• path – the main path, you can assign edge, connect type, and id.
• deductedPath - if this is not null, final graphics will be this path excluding the path.
• additionalPath - additional path, you can assign edge, connect type, and id.
• additionalDeductedPath - if this is not null, final graphics will be this path excluding the additionalPath.

WorksurfaceSnapping: since worksurface has multiple edges and a more complicated snapping behavior with other worksurfaces, panel, storage, chair, we have this specific class just to handle the snapping behavior rather than handling everything in worksurface class. In the worksurface animationTrySnap(..) method, it will re-direct to the WorksurfaceSnapping class to handle snapping to different products/systems, with the knowledge of edge id and edge connect type provided by the path class.

Edge

Edge (cm/abstract/office.WorksurfaceEdge.cm): edge has an ID system, you can use it to verify if this is a front/back/left/right side of the worksurface. You can also get a translated ID and stretch translated ID if you want to “group” some IDs into one, for example you can group left and right ID into “width” in some cases, and group front and back ID into “depth”.

Edge also provides graphics effect to the 3D, you need to customize extrudeProfile (and pathDeduction if you want the main worksurface to shrink back some distance).

Support (Accessory)

Support is an object stored in worksurface, manipulated through AOWksfSupportGenBehavior and AccessoryEnv.

AOWksfSupportGenBehavior

Snapper behavior is an implementation of the “Composition Design Pattern”. It uses a design principle of preferring composition over inheritance. Instead of an “is a” relationship typically used in traditional Object-Oriented Programming, it uses the concept of “has a” relationship. As in, an object has many components providing properties and functionality.

By using AOWksfSupportGenBehavior, one can easily plug in or replace with other behaviors, together with AccessoryEnv, a flexible combination and re-usage of manipulating accessories amongst different snappers and vessels.

AccessoryEnv

AccessoryEnv (cm/abstract/accessoryEnv.cm): This is like a “Factory” design pattern, in that it defines the generation of Accessories (by here the supports) and controls some of the logic/rules behind their creation. The interactions with the owner snapper are controlled by the AccessoryGenerationBehavior for the owner.