Does all the necessary work for setting the object to the right topic. You just have to fill the gaps for getting the leaves and node data.
Normally, it is enough if you override the members list_leaves() and get_node(). You usually don't even need to write a constructor, as the default one should be enough for your purposes. If you need extra initialization work done when "entering" a topic, use the event handler _on_set_object().
The configuration is already loaded at this point.
booleanSet this to false to indicate that you could not set this instance to the topic. NAP will abort loading this node and log the error accordingly. Return true if everything is fine.
Note, that the active leaf index set by the other parts of the component must match one leaf out of this list.
Here are some code fragments, that you usually connect through some kind of QB array:
id] = array ( MIDCOM_NAV_URL => $article->name . "/", MIDCOM_NAV_NAME => $article->title, MIDCOM_NAV_OBJECT => $article, MIDCOM_NAV_GUID => $article->guid, ) } return $leaves; ?>
ArrayNAP compliant list of leaves.
This defaults to use the topic the NAP instance has been set to directly. You can usually fall back to this behavior safely.
The default uses the extra field of the topic as NAV_NAME
ArrayNAP compliant node declaration
stringThe name of the component.
This updates the local configuration copy with the topic in question. It calls the event handler _on_set_object after initializing everything in case you need to do some custom initializations as well.
\midcom_db_topicThe topic to process.