<?php
/*
* Content Management Administration
*
* @version 0.2.0 beta
* @author Fred Hirsch
* @copyright Dark Hart Design 2001
* @package API
*/
/**
* Initializing the Interface classes
* The first step in initialization is to load the core system function and
* setup file. The "mainfile" loads all the configuration parameters, session
* handler and database loader for the various sub-elements. Unlike other
* paths in the system, the mainfile include must be relative to the location
* where the current script is running. From the mainfile, the core include
* path is setup for all the secondary includes.
*/
$plugin = 'admin.content'; // Plugin Name
include_once("../../../function.php");
/* The next variables set the interface name and the plugin name of the
* current script. The interface name describes shared functionality within
* a specific plugin, while the plugin name is used to determine the
* location of helper scripts to the interfaces.
*/
$interface = 'admin.content';
$interface_title = 'DarkPortal - Content Manager';
$interface_cols = array();
/*-----------------------------------------------------------------------------
* Authentication Handling
* In the case that a specific interface should limit access to its functions,
* the following code sample can be used to limit access and provide the user
* with a reason for the denial. This sample could be expanded to force the
* user to be a member of specific group(s) or use a plugin config variable
* to turn on group level authentication.
*/
if (empty ($userinfo[groups][Administrator])) {
$reason = "Access to Administration Interface Denied";
include("$include_path/noaccess.php");
exit;
}
isset ($searchby) ? $operation .= ".$searchby" : '';
isset ($form__operation) ? $operation .= ".$form__operation" : '';
/*-----------------------------------------------------------------------------
* >>>>>>>>>>>>>>>>>>>>>>>>>> END OF GLOBAL CODE <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
*/
/**
* API Interface
*
* The following template provides the basic level of functionality for all
* Dark Portal plugin interfaces. It serves as a common interface or API to
* perform all display functions for Dark Portal addons and current core
* functionality. For detailed developer instructions, refer to comments in
* this file, and the developer manual included with Dark Portal.
* @version 0.2.0 beta
* @author Fred Hirsch
* @copyright Dark Hart Design 2001
* @package API
*/
class LocalInterface extends Interface {
/**
* API Interface Constructor
*
* The local interface contructor should usually only call the super class
* constructor. In some cases, it may be useful to add some parameters such
* as static theme ID (admin interfaces) and so forth.
*
* @return VOID
*/
function LocalInterface() {
$this->Interface();
}
/**
* Initialize Local Interface
*
* If special initialzation is required by the local interface, it should be
* performed here. It may be best to comment this out if no special initialization
* is required.
*
* @return VOID
*/
function initializeLocal() {
}
/**
* Main Zone Callback Method
*
* Almost all interfaces should contain a main() method. This will allow the
* system to override the parsing of main inside the template and perform the
* lookup of data which will later be needed to be placed inside the primary
* zone of the interface. It is also common to create helper and indexing
* content in other zones. These may be further aided by adding content methods
* with the same name as the zone. As an example: It is common to provide
* help features to new users in the rightblock zone of the default theme. If
* customized data is needed in these blocks, it could be done in a rightblock()
* method.
*
* @param ObjectRef $theme A reference to the template object to use for assigning template date, etc.
* @return VOID
*/
function main(&$theme) {
// $dbh is the global database connector object and allows abstract database
// access and queries. This is included in many cases.
global $dbh;
// $config contains the system global configuration array as well as any
// special configuration options for the plugin. These are stored as a
// subarray to config ==> $config[<plugin name>][<element>]
global $config;
// $userinfo contains an array from the user's session information of all
// information, access control and group ownership assigned to the user.
// Base level information is stored by associative keys, while access
// control is stored in subarrays. As an example, to test for a user
// belonging to group "Admin", the following key in the array:
// $userinfo[groups][Admin] <<== would be set true or 1.
global $userinfo;
// Note the use of references in passing the template around the interface.
// This is a crucial performance issue, and should always be used in this
// form. The template can still be modified directly. It is also important
// to note that any method which overrides the template class to display
// a specialized version of blocks must have a template object passed to it.
// otherwise, the receiving method will not have any reference to build
// data into the template.
$this->template =& $theme;
$interface = $this->interface;
// Assigning data to the template must be done whenever new data has been
// loaded, or data is removed, edited or added to the database.
$theme->assign('data', $data);
// Some blocks are more useful to be added in a repetitive manner. This is
// especially true when showing summaries of news or other article managers.
// Performing this operation on the template takes the current block data
// and applies it to the current main block definition and adds the parsed
// block to the template's already parsed information.
$addParsedBlock();
}
}
/*
* Interface Initialization
* The interface class itself is now initialized, the operation variable
* used here is always included from the user interface GET or POST request.
* The Interface constructor creates the global interface variable which
* makes it available to the other classes which are initialized by the
* Initialize method. We cannot initialize in the constructor, as the object
* is not actually instantiated yet.
*/
$gui = new LocalInterface();
/* DarkPortal institutes a common set of CGI parameters which should always
* be used when performing search or lookup operations for user data. The
* basic method to create a search pattern is handled by three basic lookup
* variables:
* - searchby ==> the search lookup table for the query.
* - searchid ==> the id to use when performing the search.
* - searchname ==> If the search needs to lookup on an alternate column,
* indicate a name for that column.
* In future releases, this API will be expanded to allow for ranged
* searching, and joins on multiple tables. Currently, the search function
* is implemented directly in the Interface class. This will be changed to
* be moved to the mainfile.
*/
$gui->search[id] = $searchid;
$gui->search[key] = $searchby;
$gui->search[name] = $searchname;
$gui->Initialize();
/*-----------------------------------------------------------------------------
* Operation Logic
* Below is a sample of operational logic, which determines what the operation
* is to be performed, and attempts to perform methods within the GUI to
* enact requests by the user. Note that the interface itself will automatically
* retrieve the appropriate user interface layout blocks from the database
* during initialization. User interface methods should never generate output,
* they should only extract or place data in the database based upon the
* user's request.
*/
if (preg_match("/^search/i", $operation)) {
$gui->search();
} elseif (preg_match("/^submit/i", $operation)) {
// It is typical to set the form data into the interface class if the operation
// is a submission of information. Form data fields typically take on the form
// of form_<dataitem>. This transposition may be modified in future releases.
isset($form_id) ? $gui->form_data[id] = $form_id : '';
$gui->form_data[name] = $form_name;
// If an operation does not require input validation, it is placed first.
if ($form__operation == 'delete') {
$gui->doDelete();
} elseif ($gui->validateForm()){
// Once the form data is placed, it can be validated.
// The validation is interface dependent.
if ($form__operation == 'edit') {
$gui->doEdit();
} elseif ($form__operation == 'add') {
$gui->doAdd();
} elseif ($form__operation == 'copy') {
$gui->doCopy();
}
} else {
if ($form__operation == 'edit') {
$gui->edit();
} elseif ($form__operation == 'add') {
$gui->add();
} elseif ($form__operation == 'copy') {
$gui->copy;
} else {
$gui->unknownError();
}
}
} elseif (preg_match("/^add/", $operation)) {
$gui->add();
} elseif (preg_match("/^edit/", $operation)) {
$gui->edit();
} elseif (preg_match("/^delete/", $operation)) {
$gui->delete();
} elseif (preg_match("/^copy/", $operation)) {
$gui->copy();
}
/*-----------------------------------------------------------------------------
* Interface Display
* Once the operations (if any) are complete, the display method is called.
* this enacts the object's theme to display its appropriate blocks.
*/
print $gui->display();
$gui->Finalize();
?>