XOOPS Interview
A while ogo I got to ask some very technical questions of the people at XOOPS which is a PHP implimentation of roughly the same sort of thing as we are working on here.
I am posting this item as news so that you can see what was said and more importantly how they attempted to do things.
This may be a source of insperation for us.
-------------------------------
Ok thankyou.
I have lots of questions:
1. how does the system module expose it's API?
2. how does a module communicat with:
a. the system?
b. other modules?
3. How much and what for does a module rely on the system for: a. Authentication? b. database access? c. common eliments?
4. How much repition is required in the current design?
5. How does an install work? Does it use a common engine? How does it work...?
6. What sort of overhead does smarty use?
7. I'm sorry I just don't understand themes... and the other thing that go to make up the page could you explain it in terms of information flow...
8. What in general information non language specific terms does the main system provide (ie what API does it have and what do they do from a big picture and no fine-details sorta view)
9. How does the system process PHP stored in blocks? Is it like ASPs Server.Exicute?
10. How does the system store blocks? How does it tell the difference between system installed and custom blocks?
11. Is there an ERD for the data structure within the database?
...
Date 2004/11/9 20:19
Username: ackbarr
Subject: Re:Documentation Requirements
ok here goes, forgive me if this gets too much into the code, I'll try to keep it simple:
1. the system module is really just UI and business rules for mainipulating the kernel classes (choose Kernel as Package). All kernel classes are derived from a common class XoopsObject which defines mechanisms for storing / retrieving object properties. To get an instance of a XoopsObject class, you use the handler class (aptly named XoopsObjectHandler). The object handler classes define mechanisms for retrieving / storing XoopsObjects (usually in the mysql database). As a practical example, lets take working with users. The first thing needed is an instance of the XoopsObjectHandler for our class.
$user_handler = xoops_gethandler('user');
xoops_gethandler is a function defined by the core as a sort of 'factory' to create the proper class. In our above code, the xoops core creates a new instance of the class XoopsUserHandler and returns it.
The XoopsUserHandler class exposes several functions to retrieve / store users.
If we wanted to retrieve a particular user and previously knew his user id, we could use code like this:
$user = $user_handler->get(5); // 5 is the user id of our user (uid)
The classes in /kernel/ (and in a limited way /class/) make up the majority of the API.
2. In somewhat a circular definition, modules utilize the same kernel classes to interact with the XOOPS 'core'. In XOOPS 2.0 there is no real provision for interaction between modules, each module is its own island, so to speak. Modules that require this interaction are forced to create their own communication paths, which usually means that the link between two modules is fairly ridgid and prone to breakage when one of the modules in the communcation chain are updated. This shortcoming is being addressed with a hook system in XOOPS 2.1, which will allow a module to trigger events, or listen for events in other parts of the system.
3. Authentication: the XOOPS Core handles all authentication tasks, by the time xoops executes the module's code, it is already determined if the page request comes from an authenticated user or not. Database Access: the XOOPS core creates a database connection object $xoopsDB, an instance of the XoopsMySQLDatabaseSafe class Other Common Elements: the XOOPS core provides mechanisms for adding comments to a page, Email or Private-Message based notifications sent when certain events occur in a module (like a new news post, or a forum post reply), a customizable permission system based on Groups. 4. Repetition - an OO design like the on in XOOPS encourages re-use, repetition usually happens when there is a common feature not supplied by the core, like improvements made to the Media Uploader class.
5. To answer properly this will take a complete post by itself.
6. Smarty does add some overhead to the loading of a XOOPS site. Its primary benefit is the flexibility given to the site administrator to significantly customize the display of blocks or modules.
7. Themes are just smarty scripts. In terms of operational flow, I suppose it could be broken down like this:
XOOPS core determines if user requests a page within a module, retrieves the module meta data using XoopsModuleHandler Retrieves all blocks visible to the current user, in the current module Each block is processed in succession, first the PHP code for the block is executed, returning an array of variables which are combined with the defined block templates in the smarty template layer. These blocks are then sorted into their various location based groups (left, right, center, etc) Next the php code for the requested module page is executed, resulting in additional variables assigned to the smarty template layer, which combines them with the defined page template (again by the smarty template layer)
Once page processing is complete, the core takes the various rendered pieces (the blocks, the module content) and plugs them into the theme.
8. I think I answered this one in #1 & #2
9. For module defined blocks, the XOOPS core calls a function. This function is defined in /modules//xoops_version.php , which is used when a module is installed (a partial answer to #5). For admin created blocks (defined in System -> Blocks) it uses the php function eval() to execute the php code. This function is similar to Server.Execute() in ASP.
10 Blocks are stored in the _newblocks table in MySQL. With the block it stores the ID of the module that installed it. Custom blocks are installed with a module ID of 0.
11. There was at one point, but I think it has been lost. Either way it had not been kept up to date, so its usefullness would be limited.
2005-03-02 13:50:37 UTC by matt_t_hat
