MVC Improvement - The View Module - 1
Some random observations:


What does your base class database do? I hope not the stuff it sounds like. Your aim is to separate storage and view logic, not add view logic to your database.
Having both static and non-static functions in a class should make you suspicious (as this is an indicator this class has one then more objective or is inconsistently written).  
Some functions do echo, some return and some call other functions. Decide for one way ;).
invoke for parameter to function resolving? Have a look at the much cooler magic function __call.


Some suggestions:


It is probably a good idea to move the single view operations into it's own classes. This becomes more important when you add even more operations. 
Unify the way your class is accessed and the return values.
Views don't extend a database.


Easy to implement way:


Let every view operation be it's own class.
Define a common interface for all view operations (e.g. ViewOperation with one required function run()).
Create one main class View that is responsible to resolve view operations to subclasses.


Example implementation:

interface ViewOperation
{
    public function run();
}

public class ControllAdd implements ViewOperation
{
    private $_types = array('pass' =&gt; '&lt;xx_p&gt;', 'fail' =&gt; '&lt;xx_f&gt;');

    public function run()
    {
        $params = func_get_arg(1);
        if(isset($params) &amp;&amp; !empty($params) &amp;&amp; array_key_exists($this-&gt;_types, $params))
        {
            return $this-&gt;_types[$params];
        }
    }
}

public class View
{
    public function __call($name, $arguments)
    {
        // More security required here of course
        require_once './ViewOperartopns/' . $name . '.php';

        $instance = new $name;
        return $instance-&gt;run($arguments);
    }
}