XOOPS: XOOPSDEM Brussels 2005 - Rowd's Report

Posted by: rowdieOn 2005/3/2 17:59:08 9447 reads

The New Frontier: Next generation XOOPS (Skalpa)
A very tired Skalpa gave an excellent presentation on the next generation of XOOPS, which has been built from scratch and is simply awesome.

When Skalpa started designing this new system, which as yet has no version number, he went right back to basics and looked at XOOPS in the context of its environment. This meant that XOOPS:
1. has to be HTTP aware
2. has to become fully standards compliant, not just with existing commonly supported standards, but also with standards that are presently only proposals
3. must become more integrated with its environment, and make use of the resources of the environment when available. i.e. if native pdf file generation is available on a server, then use it. If not, then provide an alternative. Don't ignore native solutions because they might not be available on all systems, just provide an alternative as a fallback.
4. must have backward compatibility for XOOPS 2.0.x modules and themes.

The next XOOPS has a component-based architecture and will provide services to modules, something like the way an OS works. For example, the authentication layer can be changed to your prefered type of authentication, by simply configuring which component to use when XOOPS authenticates a user.

Implementation example...
$inst = $xoops->create('xoops.db');

Which database to use depends on the site configuration - you don't need to know exactly which class it uses, you are only interested in creating a database object.

The structure of XOOPS will be 3 tier:
- OS layer
- Application layer
- Portal System

OS layer
There are two modes - a "Developer" mode and "Production" mode. In developer mode all config settings and theme/templates are read on each page request, so it will always load your latest changes. This mode is reactive, which makes developing your site easier, but is slow. Production mode only reads the config settings it needs, and from a compiled version (something like the Smarty compile solution), therefore doesn't always need database queries. This makes it very fast, though less reactive to changes. A site in production rarely needs config changes, which is the reasoning behind the production mode.

The new XOOPS architecture has more modular code, which basically means that there are a limitless amount of features/components that could be made available. The core team have yet to decide where to stop.

A few components that will definitely be included are:
XoopsAuth
- LDAP is the default
- Project Liberty will also be an option. This is an open source solution for a syndicated site i.e. log in on one site means the person will be automatically authenticated for all sites - something like a M$ passport idea.

XoopsDB
- MySQLi (released with PHP5)
- MySQL, the default database used
- postgre

Application layer
Basically everything related to CMS (this XOOPS will be a true CMS!) - utility classes, controllers, creating objects, managing tables in DB...

Stores Manager
Able to determine where the content is taken from. It can be stored on different servers, have different prefixes, the users could also be stored in a different location... all this can be organised here and delivered to one site, or shared between subsites. It could also be useful for presenting content in several languages.

There is also a versioning layer. This means content has a temporal dimension, so you are able to follow the evolution of a document.

Output
The separation that currently exists between themes and templates is gone! A theme now becomes a generic resources container, so any resources (images, flash file, module templates, etc) used for theme-related output should be included in the theme folder.

The theme system uses the principle of inheritance.

If you want to change one template of one module, you only need to put that new template in a sub-directory of your theme for it to be used. Not more cloning template sets, and generating files for all templates just to make one small change.
e.g.
xoops-root/theme/example_theme/
xoops-root/theme/example_theme/modules/module_index.html

This will use the main templates for everything, except your new module_index.html will be used instead of the one that came with the module.

In developer mode the theme directory is checked each time a page loads to see if it contains any sub-directories with new templates/resources. Production mode works with a generated listing of the resources, which is much less resource-intensive and therefore quicker.

XOOPS will come with a html theme as default. There will also be an xhtml theme (still to be made). But the future of the web, and therefore also XOOPS, is with XML (and XSL). So although simply using xhtml is possible, you can also create templates which could include something like this:
<table xoops:sortable="true">
  <tr>
    <td xoops:sort_type="state">content</td>
  </tr>
</table>


The transformation logic of XML will be contained in an XSL file.