-- frederic wolf <[EMAIL PROTECTED]> wrote
(on Sunday, 25 March 2007, 11:31 PM +0200):
> Matthew Weier O'Phinney a écrit :
> > -- Ralph Schindler <[EMAIL PROTECTED]> wrote
> > (on Sunday, 25 March 2007, 09:37 AM -0500):
> >
> > > I am curious how everyone implements common headers and footers
> > > within a given application. As I see it there are two methods:
> > >
> > > a) include the header and footer in each view script via the
> > > $this->render(..) routine.
> > >
> > > b) use Zend_Controller Plugins to write to the view a standard header
> > > and footer to the view body at preDispatch() postDispatch() /
> > > preRouteStartup / postRouteStartup times.
> > >
> > > Both methods have their pros and cons..
> > >
> > > In method a) you are required to handle it in every script, which can be
> > > tedious. But it allows you flexibility to not include the common header
> > > and footer blanketly on all requests when it makes sense not to include
> > > it.
> > >
> > > Method b) writes headers and footers on all requests, unless I am
> > > missing something. The benefit is that you can write specific
> > > controller/action scripts and they can be completely autonomous from the
> > > rest of the application.
> > >
> > > I like method b), but I wonder: Are there ways to inject (or callback)
> > > to write specific controller/action needed headers to the common header,
> > > for example, adding a page specific JS script to a pages <head> . Are
> > > there ways that a specific controller/action can choose not to use a
> > > header/footer dispatched previously?
> > >
> >
> > I throw a Zend_View object in the registry, and then access this from my
> > controllers and plugins. The benefit of doing this is that the
> > controllers can set values in the view that are unused in their
> > individual view, but used later in the sitewide template.
> >
> > Then, I use a dispatchLoopShutdown() plugin to inject any generated
> > content into a sitwide template:
> >
> >
> > class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract
> > {
> > public function dispatchLoopShutdown()
> > {
> > $response =
> > Zend_Controller_Front:;getInstance()->getResponse();
> > $view = Zend_Registry::get('view');
> > $view->content = $response->getBody();
> > $response->setBody($view->render('site.phtml'));
> > }
> > }
> >
> > Any other variables you've set in your template object to this point are
> > also available, not just $content. As a result, you could in your action
> > controllers specify additional values:
> >
> > public function formAction()
> > {
> > // Set the sitewide template's $pageTitle element
> > $this->view->pageTitle = 'Login Form';
> >
> > $this->render();
> > }
> >
> > By doing the sitewide template at the end, instead of doing a header in
> > the preDispatch() and footer in the postDispatch(), you can affect the
> > entire layout of the page, and also chain together several actions to
> > build the final page.
> >
> >
> Is it possible to imagine to throw a Zend_View object in the Response
> object instead of the registry. The view object would still available in
> the controllers.
> What do you think ?
> I don't even know why I would like to not throw the view object in the
> registry, :) but may be it could be easier to combine data content,
> vairaibles and templates if the view object and the response one
> are tied together.
You're free to extend the response object to do exactly this. :-)
Truly, though -- I've done this in a project once already, and there are
some definite benefits to doing so -- the response object is already
available in the action controllers as well as in the plugins (plugins
have both the request and response objects registered within them), and
you can then do some fairly easy context switching.
The reason I haven't proposed doing so for the default response object
is that it typically also adds a ton of complexity to the response
object, and tightly couples the view and response objects.
Another alternative to using the registry is to pass the view object
through as a front controller param:
$front->setParam('view', $view);
You can then access it in your action controllers:
$view = $this->_getInvokeParam('view');
or via the front controller singleton:
$view = Zend_Controller_Front::getInstance()->getParam('view');
Basically, there are a variety of mechanisms at your disposal -- choose
whatever works best for your project.
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
