XCube_ActionFilter (2)

How to define ActionFilter

Two member functions of XCube_ActionFilter are virtual function. So you have to define a sub class of XCube_ActionFilter and implement these member functions by override for your purpose.

But, if Legacy_Controller doesn’t load your ActionFilter and set it, your definition for your ActionFilter is worthless debris. You need to use Preload feature as the mechanism which loads your file and sets your class.

Legacy_Controller creates an instance of your sub class of XCube_ActionFilter systematically. Site Preload and Module Preload have different rule each other. At the start, learn the rule of Site Preload.

  1. Create {filename}.class.php in /preload
  2. Define {filename} class as a sub class of XCube_ActionFilter

Create a sample filter which stop the process at preBlockFilter(). At first, create ‘KillBill.class.php’ in /preload. Next, define ‘KillBill’ class as below:

class KillBill extends XCube_ActionFilter
{
function
preBlockFilter()
{
die(
“Kill Bill!”);
}
}

By that, you become unable to access your running XOOPS Cube by ‘KillBill’ message which hampers you. To know whether this rule is how much important, let’s try to change a class name.

class KissBall extends XCube_ActionFilter

And, you become able to access your running XOOPS Cube. Nothing hampers you. Legacy_Controller loads this file and defines this class, but he doesn’t push it to his chain because it acts against. You may use this property of Preload to load your class library.

Advertisements
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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s