I call an action helper in one of my views using the following code
echo $this->action('foo', 'bar');
The fooAction in the barController does its thing and outputs a list of pages. However, the list has the layout in the output again, which is mightily irritating. If I disable the layout in the fooAction, this causes layout to be completely disabled on the live side, as well.
I'm vexed. I could just create a view helper, and there are many ways around this, but out of curiousity I was wondering if anyone had a solution to this.
From the ZF Reference Guide on Action ViewHelper
The API for the Action view helper follows that of most MVC components that invoke controller actions: action($action, $controller, $module = null, array $params = array()). $action and $controller are required; if no module is specified, the default module is assumed.
Modify your controller to accept a param that controls whether the action should disable the layout. When using the action helper, pass this control flag.
On a sidenote: using the Action ViewHelper is considered bad practise as it will go through the entire dispatch process again and this will slow down your app. If possible, try to access the model directly.
Related
I am working on a newly created Phalcon project, and I don't really know how to actually use multiples views.
What is the entry point? I don't really know when each method in the controller is called, under which conditions, etc.
Where is the control flow defined? is it based in the name of the view? or is there a place where you can register them?
Phalcon is a bit different than other well-known PHP frameworks, in that not much is pre-configured or pre-built by default. It's quite loosely-coupled. So you have to decide where and how your control flow will work. This means that you will need to dig deeper in the documentation and also that there could be different way to achieve the same thing.
I'm going to walk you through a simple example and provide references, so you can understand it more.
1) You would start by defining a bootstrap file (or files) that will define the routes, or entry points, and will setup and create the application. This bootstrap file could be called by an index.php file that is the default file served by the web server. Here is an example of how such bootstrap file will define the routes or entry points (note: these are just fragments and do not represent all the things that a bootstrap file should do):
use Phalcon\Di\FactoryDefault;
// initializes the dependency injector of Phalcon framework
$injector = new FactoryDefault();
// defines the routes
$injector->setShared('router', function () {
return require_once('some/path/routes.php');
});
Then it the routes.php file:
use Phalcon\Mvc\Router;
use Phalcon\Mvc\Router\Group as RouterGroup;
// instantiates the router
$router = new Router(false);
// defines routes for the 'users' controller
$user_routes = new RouterGroup(['controller' => 'users']);
$user_routes->setPrefix('/users');
$user_routes->addGet('/show/{id:[0-9]{1,9}}', ['action' => 'show']);
$router->mount($user_routes);
return $router;
Im defining routes in an alternate way, by defining routes groups. I find it to be more easy to organize routes by resource or controller.
2) When you enter the url example.com/users/show/123, the routes above will match this to the controller users and action show. This is specified by the chunks of code ['controller' => 'users'], setPrefix('/users') and '/show/{id:[0-9]{1,9}}', ['action' => 'show']
3) So now you create the controller. You create a file in, let's say, controllers/UsersController.php. And then you create its action; note the name that you used in the route (show) and the suffix of Action:
public function showAction(int $id) {
// ... do all you need to do...
// fetch data
$user = UserModel::findFirst(blah blah);
// pass data to view
$this->view->setVar('user', $user);
// Phalcon automatically calls the view; from the manual:
/*
Phalcon automatically passes the execution to the view component as soon as a particular
controller has completed its cycle. The view component will look in the views folder for
a folder named as the same name of the last controller executed and then for a file named
as the last action executed.
*/
// but in case you would need to specify a different one
$this->view->render('users', 'another_view');
}
There is much more stuff related to views; consult the manual.
Note that you will need to register such controller in the bootstrap file like (Im also including examples on how to register other things):
use Phalcon\Loader;
// registers namespaces and other classes
$loader = new Loader();
$loader->registerNamespaces([
'MyNameSpace\Controllers' => 'path/controllers/',
'MyNameSpace\Models' => 'path/models/',
'MyNameSpace\Views' => 'path/views/'
]);
$loader->register();
4) You will also need to register a few things for the views. In the bootstrap file
use Phalcon\Mvc\View;
$injector->setShared('view', function () {
$view = new View();
$view->setViewsDir('path/views/');
return $view;
});
And this, together with other things you will need to do, particularly in the bootstrap process, will get you started in sending requests to the controller and action/view defined in the routes.
Those were basic examples. There is much more that you will need to learn, because I only gave you a few pieces to get you started. So here are some links that can explain more. Remember, there are several different ways to achieve the same thing in Phalcon.
Bootstrapping:
https://docs.phalconphp.com/en/3.2/di
https://docs.phalconphp.com/en/3.2/loader
https://docs.phalconphp.com/en/3.2/dispatcher
Routing: https://docs.phalconphp.com/en/3.2/routing
Controllers: https://docs.phalconphp.com/en/3.2/controllers
More on Views (from registering to passing data to them, to templating and more): https://docs.phalconphp.com/en/3.2/views
And a simple tutorial to teach you some basic things: https://docs.phalconphp.com/en/3.2/tutorial-rest
The application begins with the routing stage. From there you grab the controller and action from the router, and feed it to the dispatcher. You set the view then call the execute the dispatcher so it access your controller's action. From there you create a new response object and set its contents equal to the view requests, and finally send the response to the client's browser -- both the content and the headers. It's a good idea to do this through Phalcon rather than echoing directly or using PHP's header(), so it's only done at the moment you call $response->send(); This is best practice because it allows you to create tests, such as in phpunit, so you can test for the existence of headers, or content, while moving off to the next response and header without actually sending anything so you can test stuff. Same idea with exit; in code, is best to avoid so you can write tests and move on to the next test without your tests aborting on the first test due to the existence of exit.
As far as how the Phalcon application works, and in what steps, it's much easier to follow the flow by looking at manual bootstrapping:
https://docs.phalconphp.com/en/3.2/application#manual-bootstrapping
At the heart of Phalcon is the DI, the Dependency Injection container. This allows you to create services, and store them on the DI so services can access each other. You can create your own services and store them under your own name on the DI, there's nothing special about the names used. However depending on the areas of Phalcon you used, certain services on the DI are assumed like "db" for interacting with your database. Note services can be set as either shared or not shared on the DI. Shared means it implements singleton and keeps the object alive for all calls afterwards. If you use getShared, it does a similar thing even if it wasn't initially a shared service. The getShared method is considered bad practice and the Phalcon team is talking about removing the method in future Phalcon versions. Please rely on setShared instead.
Regarding multiple views, you can start with $this->view->disable(); from within the controller. This allows you to disable a view so you don't get any content generated to begin with from within a controller so you can follow how views work from within controllers.
Phalcon assumes every controller has a matching view under /someController/someView followed by whatever extension you registered on the view, which defaults to .volt but can also be set to use .phtml or .php.
These two correspond to:
Phalcon\Mvc\View\Engine\Php and Phalcon\Mvc\View\Engine\Volt
Note that you DON'T specify the extension when looking for a template to render, Phalcon adds this for you
Phalcon also uses a root view template index.volt, if it exists, for all interactions with the view so you can use things like the same doctype for all responses, making your life easier.
Phalcon also offers you partials, so from within a view you can render a partial like breadcrumbs, or a header or footer which you'd otherwise be copy-pasting into each template. This allows you to manage all pages from the same template so you're not repeating yourself.
As far as which view class you use within Phalcon, there's two main choices:
Phalcon\Mvc\View and Phalcon\Mvc\View\Simple
While similar, Phalcon\Mvc\View gives you a multiple level hierarchy as described before with a main template, and a controller-action based template as well as some other fancy features. As far as Phalcon\Mvc\View\Simple, it's much more lightweight and is a single level.
You should be familiar with hierarchical rendering:
https://docs.phalconphp.com/en/3.2/views#hierarchical-rendering
The idea is with Phalcon\Mvc\View that you have a Main Layout (if this template exists) usually stored in /views/index.volt, which is used on every page so you can toss in your doctypes, the title (which you would set with a variable the view passed in), etc. You'd have a Controller Layout, which would be stored under /views/layouts.myController.volt and used for every action within a controller (if this template exists), finally you'd have the Action Layout which is used for the specific action of the controller in /views/myController/myAction.volt.
There are all types of ways you can break from Phalcon's default behavior. You can do the earlier stated $this->view->disable(); so you can do everything manually yourself so Phalcon doesn't assume anything about the view template. You can also use ->pick to pick which template to use if it's going to be different than the controller and action it's ran in.
You can also return a response object from within a controller and Phalcon will not try to render the templates and use the response object instead.
For example you might want to do:
return $this->response->redirect('index/index');
This would redirect the user's browser to said page. You could also do a forward instead which would be used internally within Phalcon to access a different controller and/or action.
You can config the directory the views are stored with setViewsDir. You can also do this from within the controller itself, or even within the view as late as you want, if you have some exceptions due to a goofy directory structure.
You can do things like use $this->view->setTemplateBefore('common') or $this->view->setTemplateAfter('common'); so you can have intermediate templates.
At the heart of the view hierarchy is <?php echo $this->getContent(); ?> or {{ content() }} if you're using Volt. Even if you're using Volt, it gets parsed by Phalcon and generates the PHP version with $this->getContent(), storing it in your /cache/ directory, before it is executed.
The idea with "template before" is that it's optional if you need another layer of hierarchy between your main template and your controller template. Same idea with "template after" etc. I would advise against using template before and after as they are confusing and partials are better suited for the task.
It all depends on how you want to organize your application structure.
Note you can also swap between your main template to another main template if you need to swap anything major. You could also just toss in an "if" statement into your main template to decide what to do based on some condition, etc.
With all that said, you should be able to read the documentation and make better sense of how to utilize it:
https://docs.phalconphp.com/en/3.2/api/Phalcon_Mvc_View
I've got a partial that I'm using in a Symfony 1.4 admin generated module but I have some logic that I would prefer to keep in my action. Is there anyway to access action vars in the partial? In a regular template (ie: non admin generated), I could simply declare my var in my action as $this->myVar and then access it from within my template as $myVar, but is there any way to do this in an admin partial?
I've tried declaring it in my preExecute() method but the var is undefined in my partial template.
Am I doing something wrong, or is my only choice to use a component instead of a partial?
Partials and components don't have automatic access to action variables. They only see variables which are explicitly passed to them. In an admin generator module they usually get some useful parameters (e.g. the current object, helper object, configuration, form) but it depends on the current place of invocation (you can see the generated templates in the cache directory to find out which parameters they get). Partials also have access some global objects (e.g. request, user, response,...) which are available in every template file. You can use e.g. request attributes or slots:
// in an action
$this->getResponse()->setSlot('my_slot', $myVariable);
// in a partial
<?php include_slot('my_slot'); ?>
// or
<?php $my_variable = get_slot('my_slot'); ?>
But I think using a component is a better idea.
When you call this partial try to put the variable as a second parameter (or array of parameters) in the include_partial().
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between redirect and forward in Zend framework
I'm new to zend framework, when i try to use foward, redirect, setViewRender in controller, what are their diffences?
As the official docs say:
_forward($action, $controller = null, $module = null, array $params = null): perform another action. If called in preDispatch(), the
currently requested action will be skipped in favor of the new one.
Otherwise, after the current action is processed, the action
requested in _forward() will be executed.
_redirect($url, array $options = array()): redirect to another location. This method takes a URL and an optional set of options. By
default, it performs an HTTP 302 redirect.
Read more to understand it better.
i'm pretty sure that a redirect redirects you to a particular page/ controller therefore going through all of the pre view processes including if you can view the page, setViewRender will just output the view you have selected and disregard all of the stuff the controller etc handles. (i haven't used zend for a while however)
_redirect creates a completely new http request, where as _forward simply forwards the request. I realized this when setting a variable in zend_registry, well this might sound a little off the track but when you use _request all the request variables and headers and registry variables are completely reset where as in case of _forward it simply forwards all those things. This is like you can have previously provided information along with some more information in case of _forward.
Well for setViewRenderer I really like this idea, I mean this is something like dependency injection. You dont really need to have a default view, you could provide a new view for the given action. I think you would get the best answer if you look into this.
_forward is an internal redirect. Where as _redirect sends a header that tells the client's browser to go to some other URL, _forward tells the Dispatcher to internally redirect the request somewhere else.
If you consider the normal dispatch order of:
preDispatch()
someAction()
anotherAction()
postDispatch()
Calling _forward at any point in that progression will cause the following steps to not be executed. So if you call _forward in preDispatch(), someAction() will not be called and so on. If you _forward() in someAction() and you are using the viewRenderer action helper to render your views (you are letting the framework choose what view script to render), then no view script will be rendered in someAction().
When the request is forwarded to the new Controller / Module the entire dispatch process will be repeated there.
Note:
If you forward inside someAction() to anotherAction() you must do it like this
return $this->_forward('another');
You should add a return to $this->_forward() or your current Action will continue to execute before forwarding to the other Action.
Also note that the view that will be rendered will be another.phtml
While when doing a redirect, ZF would instruct the browser to load http://example.com/controller-name/action-name as _redirect() sends a header, meaning you create a new HTTP Request and go through the entire dispatch process with it.
Last to render a certain view inside an action use the viewRenderer Action helper:
// Bar controller class, foo module:
class Foo_BarController extends Zend_Controller_Action
{
public function addAction()
{
// Render 'bar/form.phtml' instead of 'bar/add.phtml'
$this->_helper->viewRenderer('form');
}
public function editAction()
{
// Render 'bar/form.phtml' instead of 'bar/edit.phtml'
$this->_helper->viewRenderer->setScriptAction('form');
}
public function processAction()
{
// do some validation...
if (!$valid) {
// Render 'bar/form.phtml' instead of 'bar/process.phtml'
$this->_helper->viewRenderer->setRender('form');
return;
}
// otherwise continue processing...
}
}
I'm using Zend Framework to build a website and I'm having some trouble with the dispatch loop.
Normally, Zend Framework URLs are built this way: http://www.domain.com/module/controller/action.
On my website, I'm using customized dynamic URLs which are parsed on the dispatch loop by a custom method. So, each one of these URLs, after being parsed, will execute a specific action of a specific controller and module.
I need to perform some tasks which depend on the module, controller and action that were parsed. The problem is that I'm only being able to know the parsed module, controller and action when dispatchLoopShutdown occurs. The tasks that I need to execute will set some cookies which will make changes on the output that will be sent to the browser.
But, at this point, the view has already been rendered, and the cookies that were set when dispatchLoopShutdown occurs won't change the output accordingly.
So, my question is... is there a way to force the view to be rendered again? Or a way to know what module, controller and action will be executed, before the dispatchLoopShutdown? I've also tried to accomplish this on the postDispatch but the results are the same!
Hope I could explain my problem right.
Thank you for your help.
Here is a good schema about the Zend Framework sequence.
You can know the module, controller and action before the dispatch by using a controller plugin:
<?php
class Custom_Controller_Plugin_CheckRoute extends Zend_Controller_Plugin_Abstract
{
public function preDispatch($request)
{
//Get Request
$controller = $request->controller;
$action = $request->action;
$module = $request->module;
//=> perform actions before dispatch
//Update the Request
$request->setModuleName('default')
->setControllerName('index')
->setActionName('action2');
}
}
?>
I had the same problem. It was solved by Zend_Controller_Plugin_ActionStack. I added some action where implemented logic from dispatchLoopShutdown. This link can be useful http://framework.zend.com/manual/1.12/en/zend.controller.plugins.html#zend.controller.plugins.standard.actionstack
I have a controller that is called with AJAX (sends JSON data), so I don't use a view.
I need to use a personnal view helper to format my data, but in my controller.
Is that possible ?
Or maybe I am doing it wrong (maybe I should have a view, but how with JSON) ?
You can access any ViewHelper from the Controller by
$this->view->helpername(/*params*/);
// or
$helper = $this->view->getHelper('helpername');
// or
$broker = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$broker->getView()->helpername(/*params*/);
See Zend: How to use a custom function from a view helper in the controller?
However, you might be right that you are doing it wrong (funny pic btw), but I cannot really tell from your question. Please refine it as to why you need to call the view helper and what it is supposed to format.
Zend_Controller_Front::getInstance()->getParam('bootstrap')->getResource('view');
Just be sure that the returned view is the view you want. Because down the line, the view may get overwritten and on the controller you have a spank new view.
And all those values you setup on the view on the action helper and the like... before the controller is kicked in? All gone with the wind!
So test before assuming that if you get a view resource. it is really the same view resource you expect, and that all your vars are still there.
You may be surprised as i was!
You can create an instance of a Helper .. this will work in Controllers, Models and everywhere you need the Helper.
eg.
// create Instance
$serverUrl_helper = new Zend_View_Helper_ServerUrl();
// get the ServerUrl
$serverUrl = $serverUrl_helper->serverUrl();
Another approach is to use the ContextSwitch or AjaxContext action-helpers. This allows you to use a view-script from which you can then call your view-helper in the standard manner.
Just use action helpers, many of view helpers are available as action helpers too.
Or directly by using Zend_Date or sprintf.