All Packages Class Hierarchy This Package Previous Next Index
A node is a container or leaf. A container node is the ContainerNode interface, which extendds Node. A leaf node is just the Node interface.
Responsibilites are to maintain the state that applies to the plugpoint structure only. This is the node's name, part, and parent node. That's all. The design philosophy is a Node should remain small and simple, serving only a "plugpoint structure role", with nearly no behavior.
But name, part and parent node are not enough. The systen or tool designer will eventually need to associate various properties with parts. Rather than have the part carry that data, or a custom parallel tree structure carry it, a Node has inherent and simple named properties.
Inherent properties are used by core parts or tools, and possibly a few
domain parts. These are the boolean "abilities" a part has. They
are isCore(), isContainer(), isInheritable(), isVirtual()
and isHidden().
Custom properties are for any use and should have a key namespace. We hope we haven't opened up a Pandora's Box with custom properties. They are to be used wisely. :-)
public abstract void setName(String name)
The name "MyCell" is not allowed. This is reserved for use in Cell.findPart(String name).
Our convention is to capatalize the first letter of each word making up the self-documenting part name. Examples are "Root", "ControlRegistry" and "UserSecurity".
If part names are used for finding the part in other containers, then to avoid name space conflicts the names need careful design. This can achieve branch or system uniqueness. This will happen if service parts are used a lot. To support unique naming we allow periods in the name, such as "org.jcon.security.UserAuthorization".
public abstract String getName()
public abstract void setPart(Object part)
If the part implements NodeUser then setNode(Node) will be called, using "this" node.
public abstract Object getPart()
public abstract void setParent(Container parentNode)
public abstract Container getParent()
public abstract boolean isRoot()
public abstract Container getRootNode()
public abstract boolean isContainer()
A unique type of core part is a container. It holds other container or leaf parts. All non-container parts are leaf parts. A container part requires the other core parts to run. Thus the core parts form the "container" portion of a system. We do not call this "isCell" to allow other types of containers, such as organs.
public abstract void setCore(boolean isCore)
public abstract boolean isCore()
Parts are divided into two groups: core and domain. Core parts are required for a System Tree to run. They are domain neutral, and are normally hidden. Domain parts are the ones supplied by the system builder, have the domain functionality, and form the bulk of a system. The use of core parts by domain parts should be minimized and fascaded to preserve core encapsulation.
public abstract void setInheritable(boolean isInheritable)
public abstract boolean isInheritable()
Parts may play a "local" or "inheritable" role in their collaborations with other parts. Most parts are local, and are used via Messages or occasionally directly. Some parts play a "service" role by sitting near the upper region of a System Tree and serving the needs of many parts below by being inheritable. This is the Service Architecture Pattern, though that pattern is not limited to trees.
We recommend the use of "message services" instead of "part services" for most use. This has looser coupling.
An example of the use of isInheritable is core service parts. This allows cores that don't use Messages, gives greater speed, and allows part sharing of stateless part by many containers for efficiency. One purpose of this property is so the designer can declare that a part NOT be used as a service, which can improve cell encapsulation. Another advantage is automatic management of service parts by a service registry or such.
public abstract void setVirtual(boolean isVirtual)
public abstract boolean isVirtual()
Parts may be normal or "virtual". Normally all parts are defined in Container DK. But virtual parts are not defined by Container DK. This allows more dynamic system behavior, less DK, and lighter system weight. An example of virtual parts is core parts in subcells below the root.
TODO - Perhaps we need a better word, but "virtual" means a part definition is hidden, and so the part appears out of nowhere. Is this property really needed?
public abstract void setHidden(boolean isHidden)
public abstract boolean isHidden()
Most parts are visible in the visual System Tree tool and to "get all parts in a container" calls, etc. But the core parts (except for container) are hidden, because that would clutter up things visually, and expose them to possible misuse by non-core parts. This also helps preserve core encapsulation.
This property can be used to control the behavior of classes like "PartReader" to hide sensitive parts. (It's a little muddy because of the show container exception)
public abstract Flexitron getProperties()
public abstract Object findProperty(String propertyKey)
public abstract Node findNodeWithProperty(String propertyKey)
public abstract String buildPathToNode(Node toNode,
String delimiter)
public abstract String toString()
All Packages Class Hierarchy This Package Previous Next Index