/*
* Abstract Unifier class to select objects from different sources.
*/

abstract class childObjectUnifier
{
    protected $currentObjectLocation;

    public function __construct()
    {
        $this->currentObjectLocation = get_class($this);
    }

    public function getData()
    {
        switch ($this->currentObjectLocation)
        {
             case 'currentServerLoginObject':
                    return $this->currentServerLoginFunction();
                    break;

             case 'remoteServerLoginObject':
                    return $this->remoteServerLoginFunction();
                    break;

             default:
                    die('Current user load not available');
        }
    }
}

/*
* Login Object which exists on the current server.
* This object could still be hit on the current server if the current user load is not high.
* Better utilizes the current server.
*/

class currentServerLoginObject extends childObjectUnifier
{
    public function currentServerLoginFunction()
    {
         return 'Some function on the current server';
    }
}

/*
* This login object could exist remotely, for e.g. a restfull/soap/xml-rpc service
* which could be hit if the current server load is climbing.
* Could possibly use a dedicated 'login' server if user load is exceedingly high on current machine.
*/

class remoteServerLoginObject extends childObjectUnifier
{
    public function remoteServerLoginFunction()
    {
        return 'Some function on the remote server';
    }
}

/*
* The game theory pattern which decides which objects to instantiate based on logical
* decisions made by solid data.
* In this example the current user load.
*/

class GameTheoryPattern
{
    public $currentObject;

    function __construct($iCurrentUserLoad)
    {
        $this->currentObject = $this->baseObjectUponStrategicData($iCurrentUserLoad);
    }

    private function baseObjectUponStrategicData($iCurrentUserLoad)
    {
         switch ($iCurrentUserLoad)
         {
             case $iCurrentUserLoad < 1000:
                    return new currentServerLoginObject();
                    break;

             case $iCurrentUserLoad >= 1000 :
                    return new remoteServerLoginObject();
                    break;

             default:
                    die('Current user load not available');
        }
    }
}

//GetCurrentUserLoad
$iCurrentUserLoad = 1000;

//Create Login Object based on the Game Theory Pattern
$oLogin = new GameTheoryPattern($iCurrentUserLoad);

//Call an function from the unifier class
echo $oLogin->currentObject->getData();

?>

It should be pretty self explanatory – due to the high level comments

feel free to add suggestions or comments – since i’m pretty sure there could be a better way, but for now, just to convey the message it should be sufficient.

as a developer, we kind of try and convince ourselves that developing for mobile and developing for a desktop browser is kind of the same thing.  but we all know that this is a stalling technique for the inevitable, since invariably it becomes a whole different field of play.

every little feature you add, every little flow created and every branch of navigational hierarchy is a challenge on its own.

enter the game theory pattern

this is was where my idea of a game theory patterns came into play.  game theory is a branch of applied mathematics, most notably used in social sciences (economics, biology, engineering etc.).  it is also used a bit in computer science, although referred to in that field as artificial intelligence.

thanks wikipedia

game theory allows someone to apply a bit of mathematics to capture data from a situation and use that data to build a strategic base, which allows you to make decisions to determine your success.

take for example morning traffic – you have 2 routes to take to work – one a bit longer than the other, but the longer route is less likely to be busy.

what do you do?  most of us will take the pro’s and con’s of both routes and use that to base our decision upon.

game theory works exactly, well almost, the same.  except you will probably use a bit of math to finalize your decision (average speed, distance etc.)

so why not use game theory in development, especially in a field like mobile, which is very limiting and very frustating at first.  but the good kind of limitation, the kind of limitation that could possibly create innovation.  the guys behind a phenomenon like twitter decided to limit people to 140 characters.  and despite this limitation, people have found innovative ways to increase the effect of that 140 character limited textual communication.

game theory would allow us to mathematically decide on feature sets, the use of algorythms, objects and could even change the flow of an application.

say on an example mobile application we have 3 major features – chat, activity, content sharing.

which one do we choose as our killer feature, and which would probably make the application more bloated and more problematic to use.  why not use the main variable in the equation to help you decide – the user.

i often secretly chuckle to myself, when a system gets developed for one purpose and all the users start using it for a totally different end result, no one really every thought of, or intended for.  you could use this to your advantage with game theory.

a simple case could be made using application flow as an example.  we have a menu with chat, activity feed and shared content.  which one is more important, which one would you make easier to access for the user.  by simply adding a click count to each feature, you could sort a menu by popularity, rather than obvious choice as this will invariably change someday.

if users decide this month, chat is the next best thing, let chat be number one on your menu – and i know some user interface expert will maintain that consistency is important, but if users consistently choose chat as their most important feature, what would the issue be?

this would change the way you develop and architecture software as well.  since you know chat is gaining in popularity according to your available data, then you should be able to utilize servers better for your chat functionality.  write scaling scripts which would use databases sharding.  and on the other hand, allow your game theory pattern to simplify things – why use a 40 slave/master instances of a database if all you need is one.  eliminate unnecessary overheads in that way – more layers makes for more complexity, makes for more overhead, and will eventually kill your application.

i’ve still got to convince a couple of people to maybe try this game theory pattern approach to development and if, by chance, martin fowler reads this article:

‘please martin, consider this pattern as a topic for a new book! ’

there is however a bit of an issue with web based mvc frameworks, and in my opinion a large freaking elephant that no one seems to talk about.  how can i call a controller from within a view and assign an action to it – and is it correct to do so?

and before the quiet whispers start, i’d like to note that this does not necessarily go against mvc principles.  if you think about it – the whole point of mvc is to seperate business logic, application logic and the view (presentation logic) – and i’ve confirmed this with a couple of conversations with other developers.  but on the other hand, if you feel that i have overstepped a boundary – please do let me know if there is a better, or more correct way of doing this.

now lets give a practical problem:

i have a view template, lets call it home, which consists out of a header, navigation, content and footer.  now my content is pretty much controlled by the controller and whatever the view calls to display.  but say for example something you wish to partially include a login form in the top header.

how do i actually use a controller to change the way the view behaves, without building the logic into all the controllers which i access.  now in order to overcome this – we can attach a controller, lets call it log controller, to the view.  this controller will have the business logic to decide whether or not a login or a logout form must be generated.

now the obvious would be to include a partial view, but then the issue arrives where you let your view start making logic decisions, instead of presentation. on the other hand, you can use the current controller to help you decide this, but if you ask me, that might be a bit of overkill and lots of extra and duplicate coding.

the solution:

in zend framework, i found the solution to be a bit easier than in kohana, but still fun to figure out.

zend framework:

okay, so i have my home template, which is controlled by my home controller.  on my home template in my header i have a form which would change depending on if the user is logged in or not, which i would like to be controlled by my log controller.

so, in my view i would do the following call:

<?php echo $this->action('log','generateForm') ?>

which would go to the log controller and call the method generateForm() – so in generate form i will be able to decide whether the user is logged in or not and assign the corresponding result to the view assigned to the controller, in the case above it would most likely be the generateForm view.

there you go – without having to overcomplicate things or duplicate code, you can assign controllers as part of your presentation logic with a simple call.  i have however not yet figured out how to pass variables to the action method you are calling, but as soon as i have an update i will let you know.

kohana:

in kohana the task is  a bit more complicated – luckily i found in the underbelly of the kohana forums an user with the same problem – which came up with the following solution -

<?php
class Dispatch_Core{

protected $controller;

public static function controller($controller)
{
$controller_file=strtolower($controller);

// Set controller class name
$controller = ucfirst($controller).'_Controller';

if(!class_exists($controller, FALSE))
{
// If the file doesn't exist, just return
if (($filepath = Kohana::find_file('controllers', $controller_file)) === FALSE)
return FALSE;

// Include the Controller file
require_once $filepath;
}

// Run system.pre_controller
Event::run('dispatch.pre_controller');

// Initialize the controller
$controller = new $controller;

// Run system.post_controller_constructor
Event::run('dispatch.post_controller_constructor');

return new Dispatch($controller);
}
public function __construct(Controller $controller)
{
$this->controller=$controller;

}

public function __get($key)
{
if($key=='controller')
{
return $this->$key;
}
else
{
return $this->controller->$key;
}
}

public function __set($key,$value)
{
$this->controller->$key=$value;
}

public function __toString()
{
return $this->render();
}

public function render()
{
return (string) $this->controller;
}

public function __call($name,$arguments=null)
{
if(method_exists($this->controller,$name))
{
return $this->method($name,$arguments);
}
return false;
}

public function method($method,$arguments=null)
{
if(!method_exists($this->controller,$method))
return false;

if (method_exists($this->controller,'_remap'))
{
// Make the arguments routed
$arguments = array($method, $arguments);

// The method becomes part of the arguments
array_unshift($arguments, $method);

// Set the method to _remap
$method = '_remap';
}

ob_start();

if(is_string($arguments))
{
$arguments=array($arguments);
}

switch(count($arguments))
{
case 1:
$result=$this->controller->$method($arguments[0]);
break;
case 2:
$result=$this->controller->$method($arguments[0], $arguments[1]);
break;
case 3:
$result=$this->controller->$method($arguments[0], $arguments[1], $arguments[2]);
break;
case 4:
$result=$this->controller->$method($arguments[0], $arguments[1], $arguments[2], $arguments[3]);
break;
default:
// Resort to using call_user_func_array for many segments
$result=call_user_func_array(array($this->controller, $method), $arguments);
break;
}

// Run system.post_controller
Event::run('dispatch.post_controller');

if($result!=NULL)
{
$result=ob_get_contents();

ob_end_clean();
}

return $result;
}

}

now the above you can save under your library directory in your application for ease of use as something like dispatch.php.

so to solve the problem of the login form – in my default home template i’ve added <?php echo $this->template->partial = new View('log/generateform');?>

in the generateform view i called i will use the following:

<?php
//call the log controller
$dispatch = Dispatch::Controller('log');
//call the generateForm method
$dispatch->method('generateForm');
//return the result from the template to the view
echo $dispatch->template;
?>

the above will call the  log controller and the method generateForm, in the controller, you can specify the template, for e.g. <?php public $template = 'kohana/partial/navigation';?> and then in the action / controller assign any values to be used by the template view/presentation.

oh, and one more cool thing with the above is that you can also call the method using parameters for e.g. <?php $dispatch->generateForm(array('title'='login'));?>

recap

as i said in the beginning, if anyone feels that i’ve overstepped the mvc divide, please let me know, i’m sure that with the assigning of a controller/action from within a view is totally acceptable, since only your presentation logic is affected by it really, and the controller still decides on what is available for the view to pull, without having adjust your controllers to cater for everything.

and if someone knows of a quicker method in kohana, also do let me know.