Poor ViewInterface::render

I think \Phalcon\Mvc\View::render method is vendor-locked now. Look: ```php public function render($controllerName, $actionName, $params=null){ } ``` View component should not know about controllers and actions. View component should only render template with data. Dispatcher should perform some magic and bind controllers with views.

I think method render should looks like ```php public function render($name, $params=null){} ```

Where $name is logical name (it maybe a filepath, or a cache key, or smth else - depends on engine realization). Side effect of current realization - It's impossible to render custom file in standalone mode, because you should provide at least 2 arguments to render function. And you can't even do smth like ```php $view->getEngine('twig')->render(); ``` because View hasn't getter's for engines. Also I don't understand how to render picked view now ```php $view->pick('path/to/file'); $view->render('', ''); //only this call works, but I think it's silly ```

Look at Symfony2 Templating component. It has really cool architecture: https://github.com/symfony/Templating

Hi Sirian Phalcon view can be used as standalone mode. Look at the http://docs.phalconphp.com/en/latest/reference/models.html#stand-alone-component. For stand alone mode, you shold assign the $controllerName with the folder containing your template and the $actionName is the file name of the template.
I use the view engine for my Elements class, a ui elements that is used by many controllers. Here is the example of elements class that render using view engine.

/**
 * Elements
 *
 * Helps to build UI elements for the application
 */
class Elements extends \Phalcon\Mvc\User\Component
{
    protected function tmplRender($tmpl){
        $this->view->start();
        //render $tmpl.volt stored in /views/elements/$tmpl.vol 
        $this->view->render('elements',$tmpl);
        $this->view->finish();
        return $this->view->getContent();     
    }

    public function getSearchBar(){
        $this->view->setVar('categories',\Models\Categories::find());
        //render searchbar.volt
        return $this->tmplRender('searchbar'); 
    }
}


954

You can render this way if you has filestructure like 'viewsrootdir/subfolder/file.volt`' But try to render: 'viewsrootdir/file.volt'



954

and what if i want to render 'viewsrootdir/sub1/sub2/file.volt'? ```php $view->render('sub1/sub2', 'file') or $view->render('sub1', 'sub2/file') ```

I think render function now is ambiguous



81.8k

You could add a method 'render' to your base controller and implement a similar behavior to the one you're expecting:

<?php

class ControllerBase extends Phalcon\Mvc\Controller
{

    public function render($path, $variables=null)
    {
        $this->view->disable();       
        echo $this->twig->render($path, $variables);              
    }

}

Render views in your controller:

<?php

class RobotsController extends ControllerBase
{
    public function showAction()
    {
        $this->render('sub-dir/sub-dir/template.twig');
    }
}

Register the Twig service this way:

$di['twig'] = function(){
    $loader = new \Twig_Loader_Filesystem('../app/views/');
    $twig = new \Twig_Environment($loader);
    return $twig;    
};


954

Yes, now i use this approach. But what if I want to use multiple engines simultaneously? Of course I can implement own DelegationEngine, or use Symfony Templating component. But in this case I will loose performance and don't understand why should I use phalcon? only for DI and dispatching?



81.8k

Phalcon\Mvc\View uses a different strategy, which is more related to convention rather than explicitness, it uses a hierarchical view model where views are included in a hierarchy according to the controller and view that was executed, very different from what you mention where inheritance between views is explicitly defined by the developer in each request.

You could force Phalcon\Mvc\View to work in the way you're expecting, but keeping in mind that it's designed to work with a different approach.



954

So maybe you should create a delegation layer between engines and current View?



81.8k

I do not know what exactly idea you have in mind, if you want you can add that functionality to the incubator and then we can port it somewhat similar way to C