]> &title; &package; &firstname; &surname; Code and documentation.
&email;
2012 &firstname; &surname; <&email;> This manual page was written for the DaPortal project (and may be used by others). Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 3 as published by the Free Software Foundation. &name; §ion; &name; &purpose; DaPortal configuration The &name; file should be found within the root folder of an installation of the DaPortal project. A sample file should already be available when extracting DaPortal. File format The &name; file is organized in sections, each containing a number of variables. Section names are written on their own line, between brackets (eg "[section]"). Variables are given on their own lines too, like this:
variable=value
The &name; file may be commented, comment lines being prepended with a hash sign "#". Variables can be defined directly without specifying a particular section first; they belong then to the default section, which is simply considered to have an empty name. Important variables The &name; file typically starts with the following variables: debug: whether to log debugging information (each engine may have its own implementation for logging) prefix: the PREFIX directory where the required system files are installed, like translations (defaults to /usr/local) theme: the default theme (defaults to "DaPortal") title: the default title (defaults to "DaPortal") Important sections A number of sections are essential for proper configuration of &package;. Most map to a specific subsystem of &package;, as summarized here: defaults: a few important additional values can be set within this section. engine: the default engine can be set within this section, through the backend variable (default: auto-detected) auth: the default authentication subsystem can be set within this section, through the backend variable (default: determined by the engine) database: the database backend can be forced within this section, through the backend variable as well (default: SQLite 3) format: the default file format to use when converting pages for delivery to the user; specific backends can be forced for any given MIME type, and variables can be set per backend (defaults: specific to each engine and format backend) template: the default templating engine to use when generating pages, through the backend variable (default: basic, when not overriden by the engine). The list of variables available for each of these sections is specific to each; they are typically listed within the default configuration file. Other sections The other sections typically match a particular module or subsystem, with the name composed of two parts: the type of subsystem (eg "database", "engine", "format", "module", "template"...) followed by two colons "::"; the name of the subsystem affected. Again, the list of variables available for each of these sections is found within the default configuration file. Subsystems Auth This subsystem is responsible for proper authentication of the final user. Different authentication mechanisms are necessary or relevant depending on the current environment, and therefore provided by this subsystem. User-specific storage should also be provided by this subsystem, as it may be required by some other subsystems or modules for proper operation. Database The database subsystem is in charge of interacting with the actual database backend to be used. It must handle SQL prepared statements, and should implement transactions as well. Engine This subsystem is the most essential of all. It is in charge of defining the incoming requests, loading the respective subsystems necessary, processing the requests and determining how to render them to the final user. Format The format subsystem converts input in the &package;'s internal widget-based representation to the desired output format, which can range from a native application window to document formats, as well as plain text. The actual format backend to be used is usually determined by the engine, according to the MIME type expected; the &name; configuration file can be used to map these associations (as illustrated in ). Template The templating subsystem is optional, and may be loaded to enrich the content returned by specific requests, or determine whether and how the results of additional requests should be rendered as well. Translation The user interface of &package; can optionally be translated, regardless of the rendering engine being used. Its implementation defaults to the GNU Gettext API (as provided by PHP). A stub implementation is provided otherwise. Modules Admin The "admin" module is reserved to site administrators, and manages which modules are to be enabled. Content The "content" module is an abstract class, dedicated to content management. It is, in turn, inherited by more specialized modules (such as "news", "blog", "wiki"...) which format and authorize access to content according to their respective requirements. Search The "search" module is a generic module to look for content globally on the site. User The "user" module can be used whenever the authentication backend itself is not sufficient to identify the user properly. It is also useful to access and update account information, or list content of specific users. Sample file A sample configuration file is provided here. Bugs Issues can be listed and reported at . See also daportal 1