Legacy_Controller doesn’t use directly XoopsBlock instances as well as XoosModue instance. In the block process, Legacy_Controller uses Legacy_AbstractBlockProcedure class group. This and Legacy_AbstractModule is the same concept. If you don’t understand Legacy_AbstractModule, read this entry.
In the case where a module doesn’t declare class use, Legacy_Controlle uses Legacy_BlockProdecureAdapter as an adapter class. This class imitates XOOPS2 spec completely. Unlike Legacy_AbstractModule, Legacy_Controller doesn’t try to find block’s class without explicit declaration. Therefore, a module developer needs to define the class name of blocks in xoops_version.php, if he hopes.

How to create instance

1. Define $modversion[‘blocks’][x][‘class’] = ‘{Class}’;
2. Define {Dirname}_{Class} class as the sub-class of Legacy_BlockProcedure in the file specified by $modversion[‘blocks’][x][‘file’].
3. Implement methods.

What do developers use this for?
Because Legacy_Controller uses an adapter class correctly, module developers don’t need to use this mechanism in most cases. But, XOOPS2 JP spec is not enough for some cases. For that, this mechanism is useful.

Access to XoopsBlock
The block-show-function called by XOOPS2 JP can’t access its XoopsBlock instance, because the signature of this function doesn’t include XoopsBlock instance. Legacy_Controller calls Legacy_BlockProcedure::execute() instead of the block-show-function. Therefore, module developers can access $this->_mBlock.

Change XoopsBlock interpretation
For example, piCal accesses the global variables which common.php used, to change the title of blocks. That is great, and unorthodox approach. But, XOOPS Cube Legacy offers orthodox approach for such cases. Create your class, and override getTitle().

Hidden blocks
If you hope to use blocks as virtual cron with block cache, override isDisplay(). In the case where isDislay() returns false, Legacy tries to create cache without its block display.

Change rendering process
XOOPS2 JP blocks can’t change rendering process, because common.php renders blocks. But, in XOOPS Cube Legacy, Legacy_BlockProcedure try to render its own result. Therefore, module developers can change template file and dependency render-system.

If $modverison[‘block’][x][‘class’] is defined, the module installer ignores $modversion[‘block’][x][‘show_func’].

Actual example
See stdCache module of Beta.

This entry was posted in XOOPS Cube. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s