PFS structure basics - for administrators and developers

Update (2009.03.27): PFS was renamed to Sense/Net Content Repository (SNCR) in Sense/Net 6.0

PFS - entities in a tree

As mentioned before in a PFS review entry the Portal File System is an essential repository where all kinds of entities –documents, contents, custom objects, system files, images, style sheets etc. – are stored.

For the administrator with the help of the Portal Explorer these objects can easily be administered. Editing, adding, deleting and moving these entities is incredibly simple and straightforward. At the same time for the developer the PFS is the tool that makes the definition and handling objects a real ease.

Objects within the PFS are stored in a tree which makes the backend of the portal both structured and easily administrable. It also forces developers to organize the data stored within – the PFS was not designed to store a large amount of unstructured information but instead to efficiently manage structured entities and connections between.

 

PFS for the developer – Nodes in a tree

All objects stored in the PFS inherit from the abstract Node class. Nodes support persistency related methods (Save, Load), storage related methods (Move, Copy, Delete) and fire events whenever any of these methods are called. Nodes also have reference to their parent and children, provide information on creation, modification and versioning.

The Name and Path property 

All nodes have a Name property which is a unique value within the children of one parent (so basically it uniquely identifies the leaves of a branch in a tree). Not surprisingly because of the tree structure all nodes can be addressed with the series of object names; this property is called Path and it is probably one of the most commonly used node properties. For an example the Name of the node in the following picture is "sn01.jpg", it is located within the "/Root/ImagesGallery" folder so its path is "/Root/ImageGallery/sn01.jpg". Quite straightforward. 

The Path of a node - not surprisingly - is a read-only property, only the Name property can be set. When not assigned, this property is a GUID ensuring that saving a node will always be successful even when this property not set. Of course at most times setting this property will be vital to identify the object created.

Exceptions when saving Nodes – common, Name-related errors

After setting the Name property and saving the object two scenarios are possible: either the save is successful or an exception is thrown. Exceptions in TNG are typed so identifying the cause is quite easy. Let’s take a brief look of the Name property related problems that might occur.
• If the Name of the node is not unique within the branch (that is if another node with the same Path property exists) a DataException will be thrown
• If the Name property contains invalid characters (characters not allowed are the following: \, :, *, ?, ", <, >) or the Name property is an empty string an InvalidOperationException is thrown. (Although not a Name related reason, this exception is also thrown when the Parent reference of the Node does not exist.)

The bottom line

When using the PFS either as an administrator or a developer maintaining a clean structure is vital for all applications. Building the tree with a logical hierarchy and assigning proper names for entities (nodes) is the way to do so.
 

Comments are closed

Welcome to the blog!

Sense/Net ECM is ever evolving. Community means the world to us so we want to keep you apprised on what’s happening on our side of the woods. Want to make us happy? Add a comment and tell us what you think!

Month List