Finishing touches

The previous chapters demonstrated the general structure of a own module for Kajona.
Many of the steps needed to be performed are done by the framework, in many cases transparently in the background. That's the reason to have a look at some details not mentioned before.

Quickhelp

The backend supports the user by providing some kind of “quickhelp”. In general, those are the same-named buttons, located at the upper right when browsing the backend (at least in the default skins). And even if those buttons have never been enabled explicitly, they even appear in the module votings. The source of those buttons can be found in the language-files of the module:


$lang["quickhelp_list"] = "All votings created are listed in this view.";
$lang["quickhelp_listAnswers"] = "All answers belonging to to a voting are listed here.";
$lang["quickhelp_newVoting"] = "A voting can be created or modified right here. The start- and end-date are optional.";


The framework searches for entries named something like quickhelp_actionName.
As soon as there's a matching entry, the text is loaded and assigned to the quickhelp-button.

Module-title

The module is administrated using the title “Votings”, but again this was never set explicitly. And again the reason can be found in the language-files:


$lang["modul_titel"] = "Votings";


By default, the entry named “modul_titel” is used to name the current module. This default-behavior can be changed by overwriting the method „getOutputModuleTitle()“.


See in addition http://apidocs.kajona.de/v3.3.0/modul_system/class_admin.html#getOutputModuleTitle

Automatic text-resolving

In some portal-templates, the entries with the syntax %%lang_keyword%% may attract attention:


<input type="submit" value="%%lang_voting_submit%%" class="button" />


Those placeholders are created nowhere in the portal-class, but they are populated in the generated output.
But again, a similar entry can be found in the language-file:


$lang["voting_submit"] = "Vote!";


The only obvious difference is the missing prefix lang_. As soon as a placeholder starting with lang_ is found in the template, the framework tries to resolve this key with an entry from a language-file. A manual loading of the language-entry and providing the placeholder is not necessary.
The only premise is to compile the template by calling


$this->fillTemplate($arrTemplate, $strTemplateID);


Only when using the current objects' context ($this) the framework is able to search in the matching language-files.
See in addition

Include? Require?

Even when using external classes like class_cookie, the using class misses to include or require the sources. Nevertheless, the code is executed successfully.
Responsible for loading classes is the Kajona-internal class-loader. The class-loader is triggered every time there's a request for a class not known by PHP. Compared to loading a class multiple-times by an include / require, the class-loaders' performance is way better.
See in addition http://apidocs.kajona.de/v3.3.0/modul_system/_system---includes.php.html#function__autoload

ToDos

Even if the requirements of the module have been fulfilled, the module can be extended and improved. A few possible points for a future development can be:

  • Updating the module and the elements to a new version
  • Integration of the module with the portal-editor
  • Integration into the search
  • Integration with the samplecontent
Write a comment