Developing New Paths

The Mojavi Project

Archive for the ‘Mojavi Project’ Category

September-17-08

Global Templating

posted by admin

Global Templating - The Decorator Pattern

* Enter Decorator
* Insert Here: Slots
* Let’s Decorate!
o Creating a Global Template
o Putting the ornaments up

Ever since Mojavi 3 was released earlier this year, people have been looking to create a flexible global templating solution. From using post filters to page controllers, people have been looking for a way to create simple and managable global templates that will allow for a great deal of flexibility without compromising the need for larges amount of duplicated code.
Enter Decorator

The Decorator design pattern, like every other pattern, is nothing more than a way to talk about a resuable concept, or pattern, that a programmer might encounter while coding applications. The Decorator pattern’s strength is it’s ability to serve as a wrapper for that particular object, while leaving objects like it in tact.

The Decorator pattern has been implemented in the View class, providing a number of new methods:

public function setSlot ($attributeName, $moduleName, $actionName)
public function setDecoratorDirectory ($directory)
public function isDecorator ()
protected function & getSlots ()
public function getDecoratorTemplate ()
public function getDecoratorDirectory ()
protected function & decorate (&$content)

Now a brief explanation of what each of these do:

* setSlot - Creates a slot entry based upon the results of a specially controlled controller->forward()
* setDecoratorTemplate - Sets the template that you’re going to use for your decorator. This method also automatically turns the decorator switch to true
* isDecorator - returns true is setDecoratorTemplate has been called, otherwise false.
* getSlots - Returns an array of the slots.
* getDecoratorTemplate - Returns the decorator template.
* getDecoratorDirectory - Returns the decorator directory.
* decorate - A method that must be implemented in derivate Views.

Note: these functions are in View, so all derivates of View (ie PHPView) have access.
Insert Here: Slots

Slots is a new name for an old concept. More or less, slots serve as placeholders that can be populated by the results of a $controller->foward($mod, $act) call. And, as you can see, the setSlot method takes three parameters:

public function setSlot ($attributeName, $moduleName, $actionName)

The first parameter, $attributeName, serves as the name of the slot. The next two parameters will be used to get the results of that Action, put it in a buffer, and place it into the internal $slots memeber variable.
Let’s Decorate!

The usage pattern of Views changes little with the implementation of the decorator pattern at the module level (though secondary View authors, ie SmartyView et al, do have a few things to play with).

Now let’s look at what you’re going to need to do implement the new, and NEW decorator features of Mojavi.
Creating a Global Template

First off, we’re going to need a great big christma..ehh..template to decorate. While I won’t get into breaking down and factoring our global template, keep in mind that this is not the only way to do this.

Example 2: The Christmas Tree (myGlobalTemplate.php)

Side note: Sometimes you’ll have issues with that <?xml [....] ?> declaration, an easy
workaround is to disable short tags in your php.ini file, or to use ini_set() to disable
it.

<?xml version=”1.0″ encoding=”iso-8859-1″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en-us”>

<head>

<title><?php echo $template['title']; ?></title>

<meta http-equiv=”Content-Type” content=”application/xhtml+xml; charset=utf-8″/>
<style type=”text/css” media=”all”>

<!–Css slot–>
<?php echo $template['css']; ?>

</style>

</head>

<body>

<!–menu slot–>
<div id=”menu”>

<?php echo $template['menu']; ?>

</div>

<!–main content slot–>
<div id=”main”>

<?php echo $template['content']; ?>

</div>

</body>
</html>

Putting the ornaments up

So now that we have our decorator template, we need to decorate it. The decorating process is fairly simple, and consists of the following simple steps:

* Setting the decorator directory using setDecoratorDirectory() (Optional)
* Setting the decorator template using setDecoratorTemplate()
* Setting slots setSlot()

For example,

Example 3: In the View (IndexSuccessView.class.php)

class IndexSuccessView extends PHPView
{

public function execute ()
{

// set our template
$this->setTemplate(’IndexSuccess.php’);

//setup our decorator template
$this->setDecoratorDirectory(MO_TEMPLATE_DIR);
$this->setDecoratorTemplate(’myGlobalTemplate.php’);

//setup our slots
//(SlotName, Module, Action)
$this->setSlot(’menu’, ‘Content’, ‘PopulateMenu’);
$this->setSlot(’css’, ‘Content’, ‘PopulateCss’);

// set the title
$this->setAttribute(’title’, ‘Default Action’);

}

}

Now you might be wondering where the content slot is being populated. Well, content is a reserved slot that is automatically populated with the output of the originally requested Action/View pair.

To be Continued….

Tags:
July-18-08

Migrating from Mojavi 2.0

posted by admin

Migrating From Mojavi 2.0

Moved To: Migrating From Mojavi 2

By Tyler Tompkins

Note: This document will be changing frequently as I add more information, and rearrange to create a more logical order and progression of the said information.

* Prerequisites
* First Things First
* The Context
* Translating your Renderer
* View
* Actions
* Configuration
* References

Prerequisites

You should have a decent grasp of Mojavi2 and PHP5 before trying to upgrade to Mojavi3.

If you want a quick crash course of Mojavi 3, see Creating Your First Module 2.
First Things First

Before you begin transferring your applications over from Mojavi2, make sure whatever host you’re using supports PHP5. You can figure out if your host supports PHP5 by running

phpinfo();

Furthermore, you need to download and install the Mojavi3 package, which can be attained by going to this location.
The Context

Probably the most important new and powerful aspect of Mojavi3 is the Context object. Once I figured out what this thing did, I fell in love with it. Basically, it is a sort of catalyst/storage object that allows you to access:

* The $request object via getRequest()
* The $controller object via getController()
* The $user object via getUser()
* The Current Action/Module names via getModuleName() and getActionName()
* And finally the Current module’s directory

More or less, most classes that are exposed to the user/developer (you) are going to have a getContext() function, which will allow you to access this object. And with the recent addition of cascading calls, you can perform operations that you were unable to in php4, for example:

The Old Way:

$obj =& $request->getAttribute(’myobj’);
$anotherobj =& $obj->doSomethingSpecial();
$anotherobj -> execute();

The New Way:

$this->getContext()->getRequest()->getAttribute(’myobj’)->doSomethingSpecial()->execute();

Okay, so maybe that wasn’t the best example, as it is rather lengthy, but you get my point, 1 line vs 3 lines, and no possible mistakes when dealing with large objects like copying them over without references, etc.

This subsection is to be continued….
Translating your Renderer

Mojavi2 used ‘renderers’ to translate the API of one templating system into a generic API that would easily allow a developer to switch out one templating system for another. For example, the Smarty templating engine uses $smarty->assign() to allow you to set a variable, while patTemplate, another templating system, uses $pat->addVar(). In Mojavi 2, you would then write or use an existing renderer, which you would then invoke to display your output.

Note: This was done typically through a filter, which would create the renderer object, then assign it to your $request via

$request->setAttribute(’MyRenderer’,$rendererObj))

Mojavi3 uses largely the same methodology, but instead of getting the renderer directly from the $request object within each of your views, it simply extends the View class.

For example:

abstract class SmartyView extends View
{
…..

function __construct()
{
$this->engine = $this->getContext()->getRequest()->getAttribute(’MySmartyObj’);
}

public function setAttribute($name, $value)
{
$this->engine->assign($name, $value);
}

…..
}

Note: the use of

$this->engine = $this->getContext()->getRequest()->getAttribute(’MySmartyObj’);

was simply the best solution I could come up with for getting any object from within the view, you could also have done the following just as easily:

$this->engine = new Smarty();

View

The Mojavi3 View is mostly an abstract class, which provides a skeleton of functions to work with, thus providing the unified API as was achieved in Mojavi2 (It’s unified because you are forced to comply with the naming conventions implemented by the abstract class View.)

Now, instead of intitializing your Renderer object (as you would in Mojavi2) you simply extend View, and initialize that. Like shown above:

abstract class SmartyView extends View
{

is what our new View would look like. To put this new View type into action, we extend it when declaring views for our modules. For example:

class DoSomeActionSuccessView extends SmartyView
{

}

As you can see, this is much more fluid than pulling the renderer out of $request with every new View, it’s also a lot less code that you have to copy and paste, and thus less code to maintain. You may also have noticed that the naming scheme is different for the Views, instead of naming the file DoSomeActionView_success.class.php you would now name it DoSomeActionSuccessView.class.php, and name the class likewise(In Mojavi2 we just named our view classes DoSomeActionView, in Mojavi3 it’s DoSomeActionSuccessView replacing ‘Success’ with your application’s state).

This subsection is to be continued….
Actions

Actions in Mojavi3 are fairly similiar to those of Mojavi2, with a few enhancement and semantic tweaks here and there. Listed Below:

* When returning a VIEW_SUCCESS in Mojavi2, now return the View class constant corresponding to your application state, ie: View::Success, or View::Error
* When checking for view types supporting execution (getRequestMethods) instead of returning REQ_POST etc, return Request::Post etc.
* There is a new return type for getRequestMethods(), Request::All, which serves all request methods.
* The root Action class which all your actions extend now has a getContext() method, which allows you access to the context object.

Configuration

Mojavi3 configurations are done, by default, using .ini files. This simple and straightforward configuration makes configuring mojavi very easy. The base syntax of these ini files is as follows:

[SECTION]

; a comment…..
ConfigKey = “%MO_APP_DIR%/my/config/value”

Because some people might not like ini files, Mojavi3 was created in such a way that you could write your own configuration handlers. For example, if you wanted to use xml files to configure your mojavi, you could write a configuration handler, plug it in, and start using your custom configuration styles.

This subsection is to be continued….
References

To find out more about PHP5 in general go here: Where can I go to learn more?

Technology Blogs - BlogCatalog Blog Directory