During the last years, a lot of people have been looking at the web differently, and showing the will to use more advancedntools. As such, the number of users subscribed to xoops.org have been multiplied by X. And if the XOOPS community has grown in number, it has also grown in diversity.
Last year, when wenrealized that the XOOPS project wasn’t organized to handle so many people, we also had to admit that the XOOPS core architecture wasn't able to evolve as people wanted. Not so long ago, thisnprogram was just a php portal system, not even partly Object-Oriented as it is today, and made in an almost monotheistic manner. For the users, the enhancements added to XOOPS then XOOPS 2 have beennquite positive, but for developers this legacy has been pulling us down. It has become harder and harder to contribute to the core, and to fix some problems, and it was time for a new start. Severalnother reasons were also convincing us that, if that had to happen, it had to be right now: PHP5 is already here, has great features, and one day we’ll have to decide to exploit them and forget aboutnPHP4. Considering the re-architecure we plan will require several months, it was best for us to do this switch right now. We cannot ask developers to change their methods like this every year.n
Across the years, the XOOPS core has evolved to become more than just a portal script. Hovever as of today it cannot be seen as a real Content Management Systemnneither as an applications framework, while in the meantime it is a bit of all of this. For this reason, people have become unable to define what was XOOPS, and it was the first problem we had tonsolve before trying to go anywhere.
So we first tried to design a global architecture that could be able to integrate all the required components we could already imagine. The objective herenwas not to list all these components or to detail their individual implementation, but to give an overall unrestrictive structure to our future system mainly describing how its composing parts willnrelate to each others, giving a precise place to each of them.
Once its first layers implemented, starting from the lowest ones, this global architecture will be enhanced, detailed, grow toninclude new classes and frameworks until we reach our final objective: have a platform that will allow us to run and maintain all the xoops.org web sites as we would like them to be (while they arenactually too much built around XOOPS and its limitations).
At first, the Xoosphere project is about a way more than it is about a particular program or features:
Adequate methodology should allow us to obtain a system able to satisfy as many of the various expectations actual XOOPSnusers have manifested during the last two years as possible:
Exxos will be an object instantiation and runtime configuration framework designed to help building efficient, yet configurable and flexible PHP applications. Itnwill allow every object to be switched between several “execution modes” to allow programmers to make flexible, configurable and adaptive versions of their components on one side, while providing annoptimized and more scalable version at the same time.
Exxos itself will exploit this ability, and provide a powerful runtime configuration layer that should allow people to configure everynaspect of their system. In development mode its factories will create and configure objects according to user preferences, to generate pre-configured extended classes that they will be able toninstantiate directly in production mode.
This framework will also provide standard text encoding services made available locally (text encoding being the key to higher levelninternationalization functionalities) that will minimize the differences between existing back-ends like the iconv or mbstring extensions, as well as a standardized way to implement observers (ornevent handlers).
The kernel will be our own Exxos implementation, providing a global factory responsible of the instantiation of all the objects of this system, andntaking care of the global boot and shutdown sequences. It will bring the following paradigms and features:
The last part ofnthis operational layer will consists of architectural services. This layer will contain various low-level frameworks providing standardized APIs to external services or systems. As most of the classesnit contains will be used regularly and on every page request (a lot of them being tools that will be used by higher level components), they will be designed to stay simple and optimized, and to bringnstandardization and modularization more than features.
The XoopsDb framework will benefit from the standardization PDO will finally bring to PHP 5.1. The new version of ournframework will be modeled after the PDO interfaces, ensuring this extension can be used directly if it's available (giving out of the box support for all the PDO supported platforms: Ms-SQL,nMySQL, Firebird, Oracle, PostgreSQL and SQLite), but we'll also provide a fall back MySQL driver (and would also like to provide a MySQLi driver if people are available to do it).
Thisnversion of XoopsDb will also be encoding-aware, and automatically take care of text encoding conversion (using native driver support if available, or the Exxos provided engine otherwise).n
The XoopsHttp frameworks will contain some of the Http specific components, like session handlers. An important point here is that we will ensure XOOPS 4 is build on the Httpnprotocol, not against it. Throughout our whole development process, we will ensure XOOPS stays a Web building platform that uses the most obvious standards like this protocol as adequately asnpossible. Not only will this allow us to imagine XOOPS as just a part of a bigger platform or system, it will also be the reason behind some of our architectural choices, like the fact XOOPS4 willninternally manipulate canonical, human-readable URIs, that will stay like this if possible, or get transformed to infamous xxx.php ones in the worst cases (as opposed to other programs that manipulatenscript locations later transformed using “shortURL functions”).
Smarty will be the first engine to be implemented in the XoopsTemplate framework (though differently thannit was in XOOPS2 and with the addition of custom extensions to the default engine ), but depending on the way things go, we might add our custom template engine here, implemented with a compilernsimilar to the one Smarty has (but without some its almost never used features, to keep something simple and more scalable than what Smarty has become).
The core servicesnlayer will provide primary services built above the lower level architectural components, and acting as intermediary between application level MVC-oriented components.
ThenAuthentication framework will provide two services: the authentication service (handling the whole authentication process) will be separated from the authentication driver (taking care of checkingncredentials validity), this last one becoming configurable. Several default drivers (LDAP, XoopsDb...) will be provided, but people will be able to design custom ones to extend this frameworknpossibilities.
XoopsUi will bring the base tools later used to build advanced XOOPS4 applications user interfaces. One of the key elements for this will be User Interface Filesnthat developers will be able to use to create/describe UIs (some kind of super-templates that can instantiate objects and provide several versions of an interface, made for different displayntechnologies: HTML, but also XUL, or whatever). Based on XML, user interface files will be compiled in the same manner Smarty templates are, to ensure a fast access on production sites.n
XoopsTheme will encapsulate the functions of the page building service, that wraps module output into a themed page. Page building will be enhanced will the addition of annintermediary application-level template, and the possibility will be given to objects to manipulate page-level meta data (so a widget inserted into a page can ensure its required style sheets andnscript files are fetched from the page header). More power will also be given to themes, as resources containers: people will now be able to use themes to customize any resource used to build thenoutput (whether it is a template, style sheet, script file or image). When access to a themed resource will be requested, XoopsTheme will automatically check if a custom version exists in the theme,nand modify the resource URI if it does. Access to these last features will be provided with the help of custom Smarty compiler functions, to ensure this doesn't become a scalability killer.n
We are also considering the possibility of making some of this new framework features available in the 2.1/2.2 branch.
XoopsData will be designed to address some of thenmost important areas of functionality in document-based web applications: object graph management and persistence. The classes it will provide will leverage modules developers from having to take carenof retrieving or saving objects properties from/to persistent stores, or from having to validate these properties values before they are saved to a persistent storage. Some of its key features willnbe:
The Application Services layer will contain several frameworks based on the MVC pattern, to help build document (model) oriented applications as fastnand easily as possible. The ApplicationKit will bring XoopsData-based Object controllers made to create, view or edit managed documents. The WidgetsKit will provide several default widgets that peoplencan use to build powerful user interfaces (tool bars, enhanced form controls). While we don't think XOOPS should provide a full-blown controls library, at least we will have to provide a fewndefault components as well as some standardization here, so 3rd-party developers can make their own custom XoopsUi widgets.
The modules delivered with this new platformnwill fall into several categories:
Our main objective during the development of this version,nwill be to make XOOPS a real open-source project, made highly collectively. From what I saw in recent forum posts, I guess most of the actual XOOPS users may not realize this importance of thisnchange: this has never been the case in the past, the worst consequence of this being the inability of the XOOPS2 architecture to be easily enhanced in a way that could have allowed us to continue itsndevelopment by a more collective effort.
This goal will bring a lot of changes to the traditional XOOPS development methodology. This means everybody can forget about the “code privately,nrelease when finished” way adopted by previous core development teams, and say “Hello” to early alpha core releases, or to the longly awaited technical documentations. More precisely, these are thenthings you should be able to see during the next weeks: