codarba
A web application typically consists of several input masks (
views), which are used to create, modify and delete data. The application is defined by the actions executable in the individual input masks. Thereby the framework makes no difference between actions used for data handling and those used to navigate or e.g. initiate the export of data.
The definition of an action requires the following steps:
1) Definition of the action name
2) Creating the button to trigger the action
3) Customizing the configuration file
4) Implementing the action as a controller
5) Displaying data data in the view
As an example we use the action for displaying an article node in order to edit it. Let's look at the individual steps:
Definition of the action name
We name the action editArticle. This name need not to be unique in the whole application. The
ActionMapper only requires the name (and the Action Keys defined by the action) to find the next appropriate controller.
Creating the button to trigger the action
In order to display the data the application must know which article is selected. This is exactly defined by it's
ObjectIdentifier. The data transfer between the input masks is achieved by the HTTP POST mechanism, i.e. a (hidden) input field must exist, which contains the oid of the article to be displayed. Since for most applications it's often necessary to transfer an oid, the framework defines a standard field oid in each view (see file /wcmf/application/views/formheader.tpl), which can easily be set by the
JavaScript function doDisplay (/wcmf/blank/script/common.js).
The action is triggered upon submission of the input form. Another
JavaScript function (submitAction) simplifies the execution. The form data is passed to the main.php script, which delegates the further execution to the
ActionMapper. The link to execute the action could look like this:
<a href="javascript:setContext('article'); doDisplay('{$article->getOID()}');
submitAction('editArticle');">{translate text="edit"}</a>
For details on programming the views see Programming the views.
Customizing the configuration file
To determine the controller, which carries out the action, the
ActionMapper requires an appropriate entry in the configuration file (see [actionmapping]). If the controllers name is
ArticleController, the entry could look like this:
[actionmapping]
??editArticle = ArticleController
Don't forget to introduce the
ArticleController in the configuration section [classmapping].
Additionally the
ArticleController should display a view for editing the article. If we name this view article.tpl, the configuration entry would look like the following (see
views):
[views]
ArticleController?? = article.tpl
Implementing the action as a controller
The action is executed in the controller - in this example in the
ArticleController class. Since the controller should display a view with the article's data, we first must specify that the controller has a view and second the data of the article must be passed to the view.
At first however it must be assured, that the controller receives an oid. This happens in the method Controller::validate, which searches for the entry in the passed data (_data):
function validate()
{
if ($this->_data['oid'] == '')
{
$this->_errorMsg = "No 'oid' given in data.";
return false;
}
return true;
}
We declare the existence of a view in the method Controller::hasView:
function hasView()
{
return true;
}
Finally the action is executed in the method Controller::executeKernel. Here the controller loads the data and provides it to the view for display by using the method View::assign_by_ref:
function executeKernel()
{
$persistenceFacade = &PersistenceFacade::getInstance();
// load model
$article = &$persistenceFacade->load($this->_data['oid'], BUILDDEPTH_INFINITE);
// assign model to view
$this->_view->assign_by_ref('article', $article);
// stop processing chain
return false;
}
It's important that the method returns false, since this causes the
ActionMapper to end the execution and wait for user input. The display of the view is done by the framework.
Displaying data data in the view
After the controller has provided the view with the data, the view can display the data. In our case after the
ArticleController has been executed a variable article is known to the view, which matches the article node.
The programming of the views is done in HTML together with the Smarty template language. The file article.tpl could contain the following line:
article name: {$nodeUtil->getInputControl($article, "name")}
In the curly brackets you can find Smarty code, which calls the method NodeUtil::getInputControl. This method displays the input control (in our case a textfield), which corresponds to the article's name attribute, in the HTML page. In the same manner the other attributes can be handled.