Metadata Interface

(1067x640, 21.155 Bytes)

The new MidCOM Metadata interface provides an unified access to the Metadata of all content objects supported by MidCOM. At this time a number of basic metadata keys are defined at this time. Extensibility will come at a later date, but is very easy to achive then.

Accessing and manipulating Metadata

MidCOMs Metadata is built on a combination of custom code and the Datamanager, giving you two ways of accessing the Metadata: Directly and via the Datamanager. The former is recommended for programmative operations, as they are easy to do but still safe enough when it comes down to data integrity. Any user interaction should be done with the Datamanger interface.

The main work is done by the class midcom_helper_metadata, which is already documented in CVS HEAD. This class must not be instantinated directly, instead the factory method midcom_helper_metadata::retrieve() is to be used instead. It retrieves a Metadata instance bound to a specific Midgard Object. Note, that the object is returned by reference to improve performance through metadata caching.

Manipulating Metadata using the Datamanager

The current CVS AIS does already incorporate a Metadata interface which is linked to the NAP information. This means, that usually you should have no need for an additional interface, unless you have additional content objects that are not present in AIS. The image above shows the default AIS metadata toolbar.

An instance to the datamanager can be obtained by calling the method midcom_helper_metadata::get_datamanager(), which returns a Datamanager instance again by reference. Anytime the Datamanager completed successfully, you have to call the midcom_helper_metadata::on_update() event handler. this is neccessary to correctly keep all legacy compatiblity fields correctly populated.

It is not possible to manipulate approval information from within the Datamanager. This would require a special type and widget as approval is spread over two distinct keys (time of approval and the approving user's GUID). You must call the approve and unapprove methods of midcom_helper_metadata to execute the respective operations.

Manipulating Metadata directly

The Metadata object also provides you with a direct interface to get or set any Metadata key using the corresponding methods. In this case you of course need to ensure that you deliver the correct datatype, as there is no input checking for performance reasons at this time.

The on_update event handler must not be called explicitly when manipulating the metadata directly.

All configuration keys currently in use by the core are documented in the class documentation for midcom_helper_metadata. You should refer to that page for further details.

Integration notes

NAP does now automatically integrate with the Metadata interface for all relevant informations. Components do no longer need to pass them explicitly to the NAP layer. This will (but does not right now) include the edit* and create* metadata properties.

Components in AIS do no longer need to present any leaf or node metadata controls, as this is handeled automatically now. This does include visibility settings within the Navigation. The only case where the components NAP interface can influence the metadata is the hiding of NAP objects without actually making them inaccessible (check metadata keys nav_noentry and hide for details).

Source code examples

The code below shows the debug code I'm using right now to dump most of the currently available metadata at the bottom of a page. As it is my primary testing place, a few other things around NAP, like the toolbars, are also displayed. This will give you a quick overview on the possibilities of the system.

Further code examples can be found in the documentation of midcom_helper_metadata.

Code

<hr>
<?
  $nap
= new midcom_helper_nav();
  
$baseurl = 'https://atlantis.nehmer.net/admin/';
  echo
$nap->get_breadcrumb_line();
  
$node = $nap->get_node($nap->get_current_node());
  echo
"<p>\n";
  echo
"  Component for this node:"
    
. "{$node[MIDCOM_NAV_COMPONENT]}<br>\n";
  echo
"</p>\n<p>\n";
  echo
"  FullURL for this node: "
    
. "<a href='{$node[MIDCOM_NAV_FULLURL]}'>"
    
. "{$node[MIDCOM_NAV_FULLURL]}</a><br>\n";
  echo
"  GUID for this node: "
    
. "{$node[MIDCOM_NAV_GUID]}<br>\n";
  echo
"  Permalink for this node "
    
. "<a href='{$node[MIDCOM_NAV_PERMALINK]}'>"
    
. "{$node[MIDCOM_NAV_PERMALINK]}</a><br>\n";
  
$leafid = $nap->get_current_leaf();
  if (
$leafid !== false)
  {
    echo
"</p>\n<p>\n";
    
$leaf = $nap->get_leaf($leafid);
    echo
"  FullURL for this leaf: "
      
. "<a href='{$leaf[MIDCOM_NAV_FULLURL]}'>"
      
. "{$leaf[MIDCOM_NAV_FULLURL]}</a><br>\n";
    echo
"  GUID for this leaf: "
      
. "{$leaf[MIDCOM_NAV_GUID]}<br>\n";
    echo
"  Permalink for this leaf: "
      
. "<a href='{$leaf[MIDCOM_NAV_PERMALINK]}'>"
      
. "{$leaf[MIDCOM_NAV_PERMALINK]}</a><br>\n";
  }
  echo
"</p>\n";
?>
<hr>
<h3>Node Toolbar</h3>
<?
  
echo $nap->render_node_toolbar($baseurl);
?>

<h3>Leaf Toolbar</h3>
<?
  $toolbar
= $nap->render_leaf_toolbar($baseurl);
  if (
is_null($toolbar)) {
?>
<p>NO CURRENT LEAF SET</p>
<?
  
} else {
    echo
$toolbar;
  }
?>

<h3>Combined Toolbar</h3>
<?
  
echo $nap->render_combined_toolbar($baseurl);
?>

<h3>Combined Toolbar w/o style</h3>
<?
  $toolbar
= $nap->get_combined_toolbar($baseurl);
  
$toolbar->class_style = null;
  echo
$toolbar->render();
?>
<hr>
<pre>
NODE METADATA

<?

$meta
=& midcom_helper_metadata::retrieve($node[MIDCOM_NAV_GUID]);
$meta_dm =& $meta->get_datamanager();
print_r($meta_dm->data);

  echo
"Visible : " . $meta->is_visible() . "\n";
  echo
"Approved : " . $meta->is_approved() . "\n";

if (
$leafid !== false)
{
?>


LEAF METADATA

<?

  $meta
=& midcom_helper_metadata::retrieve($leaf[MIDCOM_NAV_GUID]);
  
$meta_dm =& $meta->get_datamanager();
  
print_r($meta_dm->data);

  echo
"Visible : " . $meta->is_visible() . "\n";
  echo
"Approved : " . $meta->is_approved() . "\n";

}
?>

CURRENT MIDCOM CONFIGURATION:

<? print_r($GLOBALS['midcom_config']); ?>

</pre>