Access Keys:
Skip to content (Access Key - 0)
Home (Access Key - 1)
All spaces... (Access Key - 3)
Log in (Access Key - 5)
Sign up (Access Key - 6)
Development

Mambo Manual is part of the documentation project for the Mambo open source content management system

Toggle Sidebar

Using Class Methods


This article is part Three of the series of articles about developing extensions with compatibility in mind

In the previous section, we talked about using functions to return information. We're likely to build up quite a collection of these special functions. One of the problems with using globals functions is we have to keep track of function names to make sure we don't try to define a function that already exists. Enter the static class.

The Static Class

When I say static class, what I really mean is we'll be using static calls to the class. That is, we won't be using the class as an object. We could do that if we wanted. But we're not really storing anything within the class. We're just returning information we get from the system core.

Here's an example of a utility class I might use for compatibility:

 class myCompat {
	function absolutePath() {
		return $GLOBALS['mosConfig_absolute_path'];
	}
	function liveSite() {
		return $GLOBALS['mosConfig_live_site'];
	}
	function &db() {
		return $GLOBALS['database'];
	}
	function &mainframe() {
		return $GLOBALS['mainframe'];
	}
	function getUser() {
		return $GLOBALS['my'];
	}
	function getUserName() {
		return $GLOBALS['my']->name;
	}
	function getTask() {
		return $GLOBALS['task'];
	}
	function baseSitePath() {
		return $GLOBALS['mosConfig_live_site'].'/components/com_mycomponent';
	}
	function baseSystemPath() {
		return (myUtil::fixPath($GLOBALS['mosConfig_absolute_path'].'/components/com_mycomponent'));
	}
	function jsPath() {
		return ($GLOBALS['mosConfig_live_site'].'/components/com_mycomponent/javascript');
	}
}

It's pretty simple really. I've defined some common variables, I never have to define them again, and all I have to do for compatibility is replace this one class with one that's compatible with whatever system I'm installing it on.

Some examples

My component has an extended user table. The user name is actually stored in the Mambo user table. I need to retrieve a user record from my component table and also need to display the user name. Here's how I do it:

 function myFunction($uid) {
	$database =& myCompat::db();
	$user = new myUser($database);
	$user->load($uid);
	$user->name = myCompat::getUserName();
}

 Here's how I might load a css file:

 function myFunction($uid) {
	$path = myCompat::myPath();
	$link = "<link rel=\"stylesheet\" type=\"text/css\""
		. " href=\"$path/style.css\" />";

	$mainframe =& myCompat::mainframe();
	$mainframe->addCustomHeadTag($link);
}

You might notice something missing in the above function. There are NO global variables defined. Everything is retrieved from the compatibility class. So you say, what's the big deal? Here's the deal. If you use these methods, and a core variable name changes, all you have to do is change it in one place. If a core class changes, all you have to do is extend it or write a compatible class and then reference it using your compatibility class.

And it gets even better. So you want your extension to be compatible with three different systems? Keep reading.

Putting It All Together

In the next section, we'll see how we can use all this to create a compatible extension. Click the Next Page link below to continue your journey.

Next Page: Completing the Compatible Extension

Toggle Sidebar
Space Navigation
Added by Lynne Pope on 30 Dec, 2007 03:16, last edited by Lynne Pope on 19 Sep, 2008 16:34

Adaptavist Theme Builder Powered by Atlassian Confluence
Free theme builder license