All Packages Class Hierarchy This Package Previous Next Index
java.lang.Object | +----org.jcon.core.part.std.NodeStd
The name "MyCell" is not allowed. This is reserved for use in Cell.findPart(String name).
Responsibilites are to maintain the state that applies to all parts, such as name, parent and isCore. The design philosophy is it should remain small and simple, serving only an "identification and properties role", with almost no behavior.
The boolean properties are all designed with the most common case as false, which is the default. For example we use "isHidden" instead of "isVisible".
public NodeStd()
public void setName(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 String getName()
public void setPart(Object part)
If the part implements NodeUser then setNode(Node) will be called, using "this" node.
public Object getPart()
public void setParentNode(Node parentNode)
public Node getParentNode()
public void setCore(boolean isCore)
public 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 void setContainer(boolean isContainer)
public boolean isContainer()
A unique type of core part is a container. It holds other container or leaf parts. All other types of 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 void setCompanion(boolean isCompanion)
public boolean isCompanion()
A container may have one leaf part that's psychologically associated with the container. An example is a registry. In the visual System Tree companions are shown as with their containers instead of being a child. This helps conceptual design.
public void setInheritable(boolean isInheritable)
public 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 void setVirtual(boolean isVirtual)
public 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.
public void setHidden(boolean isHidden)
public 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 Node getRootNode()
public String toString()
All Packages Class Hierarchy This Package Previous Next Index