-
Nodes in IPS4 are a structural concept used to organize content items. They resemble a tree, with parent nodes containing child nodes, which may contain other child nodes or content items, and so on.
In IPS4, nodes serve a range of uses where a parent/child relationships are required, but the most common use is as a category hierarchy where nodes represent categories and containers for content items. This is the use that we'll focus on in this documentation.
-
The base class that your own node classes will extend is \IPS\Node\Model. This class provides a wide range of specialist methods for working with your node data. \IPS\Node\Model in turn extends \IPS\Patterns\ActiveRecord, providing standard ways for fetching and interacting with the underlying data in your database.
<?php
namespace IPS\yourApp;
class _ExampleModel extends \IPS\Node\Model
{
//...
}
Your model can then be loaded in your controllers like so (see Active Records for more
-
When creating admin controllers designed to work with a particular node model (for example, the forum manager screen in the Forums app), IPS4 provides a special node controller you can extend to get a lot of automatic functionality, instead of building it yourself manually. This controller provides an interface for viewing and managing nodes (adding, editing, reordering etc.)
\IPS\Node\Controller itself extend \IPS\Dispatcher\Controller, so all of the standard controller methods are still a
-
In most situations, nodes will allow other nodes to be children, thus forming a parent-child relationship with each other. An example of this is forums, where a forum can contain sub-forums, which can contain further sub-forums, and so on. Each forum is a node, and they exist as a tree structure, with parent and child forums.
To support parent/child relationships, your node model simply needs to define a parent property (see below). Doing so will make a number of
-
In most cases, you'll want to support Admin Restrictions in your model classes because in the IPS Community Suite, this is how site owners control access to various parts of the AdminCP among their staff.
How Admin Restrictions work
Admin Restrictions work by calling methods on your model that represent actions the administrator is taking. The method called in the model will return a boolean indicating whether th
-
Front-end permissions allow administrators to control which member groups can perform which actions (for example, being able to view the content items inside the node, creating new content items, commenting on content items, and so forth).
Your nodes can have up to 7 different permissions, customizable depending on the needs of your application.
Implementing permissions changes the behavior of a few node methods, and adds several new permission-based methods you can call.
C
-
In most situations, your Nodes will be a container for content items - this is the typical structure used by most apps. Node models and their content item models provide a number of methods for working with each other in this kind of relationship.
There are two parts to this relationship - the functionality that becomes available to the container (i.e. the node), and the functionality that becomes available to the content items within that node. This guide will deal with the first; see Cont
-
The following is a complete example of a class using \IPS\Node\Model. This is a category node in the Downloads app.
<?php
namespace IPS\downloads;
/**
* Category Node
*/
class _Category extends \IPS\Node\Model implements \IPS\Node\Permissions
{
/**
* @brief [ActiveRecord] Multiton Store
*/
protected static $multitons;
/**
* @brief [ActiveRecord] Default Values
*/
protected static $defaultValues = NULL;
/**
* @brief [ActiveRecord] Database Table
*/
public static $