Dominik Deka schreef:
Could anybody answer me if this is ZendFramework-1.0.0-RC2 bug or only I have
this problem?
Before upgrade everything worked well.
Dominik Deka wrote:
After Framework upgrade to ver 1.0.0 method
$this->render('baz', null, true);
displays script ./application/views/scripts/CURRENT_CONTROLLER/baz.phtml
instead of ./application/views/scripts/baz.phtml
as described in:
http://framework.zend.com/manual/en/zend.controller.action.html ->
7.7.5.2. Rendering Views
Hi Dominik,
Here's a copy of one of Matthew's e-mails, please read it carefully:
-------- Originele bericht --------
Onderwerp: [fw-general] Zend_Controller ViewRenderer component now in core
Datum: Fri, 25 May 2007 08:31:03 -0400
Van: Matthew Weier O'Phinney <[EMAIL PROTECTED]>
Aan: [email protected], [EMAIL PROTECTED]
Greeting!
If you use the Zend Framework MVC components, please read this message
as it details a backwards compatibility change in the controller
components.
In the 0.9.x series of ZF, we introduced some rudimentary View
integration into Zend_Controller_Action with the methods initView(),
getViewScript(), and render(). With these methods, you could quickly and
easily instantiate view objects as well as render view scripts to the
response object.
In 0.9.3, we introduced Action Helpers. Similar to view helpers, these
can be loaded on-demand by action controllers to provide extra
functionality. They also have pre- and postDispatch() hooks such that
globally registered helpers can hook into dispatched actoin controllers.
Ralph Schindler felt it didn't go far enough, and created
http://framework.zend.com/issues/browse/ZF-1354, detailing an idea he
had for adding more integrated View dependency injection to
Zend_Controller_Action. After some thought and discussion with him, I
countered with a new action helper, the ViewRenderer.
The ViewRenderer's goals were:
* Eliminate the need to instantiate view objects within controllers
* Have a view object globally available to all controllers
* Automatically determine view script, helper, and filter paths based
on the current module's filesystem location
* Automatically associate the current module name as a class prefix
for view helper and filter classes
* Allow the developer to set default view rendering options for all
controllers or a single action
* Add the ability for developers to create their own path
specifications for determining the view base path and individual
view script paths
* Add the ability to autorender view scripts based on the current
action
What does this mean? Basically, it means less coding for you, the
developer, in your controller classes.
It means that instead of this:
class FooController extends Zend_Controller_Action
{
public function barAction()
{
$this->initView(); // initialize view
$this->view->baz = 'bat'; // set view variable
$this->render(); // render view
}
}
You would then do this:
class FooController extends Zend_Controller_Action
{
public function barAction()
{
$this->view->baz = 'bat'; // set view variable
}
}
In other words, you're just setting view variables; you don't need to
worry about initializing the view object, or rendering it. The
ViewRenderer automatically determines the view script path (by assuming
a conventional modular layout), and renders 'foo/bar.phtml' (the default
view script path is :controller/:action.phtml').
So, how will this affect your existing controllers?
* If you call $this->render(), $this->_forward(), or
$this->_redirect() (or use the Redirector helper) in your methods,
no changes are required.
* If you have methods that call none of the above -- i.e., you're not
redirecting, not forwarding to a new method, and/or not rendering
via the built-in render() method -- you will need to make changes.
You can disable autorendering by calling:
$this->_helper->viewRenderer->setNoRender()
If you call this in preDispatch() or init(), it will turn it off for
all actions in the controller; alternately, you can disable it for a
single action by calling it only in that action method.
If you want to turn off the ViewRenderer globally, i.e., for your
entire suite of controllers, add the following to your bootstrap,
prior to calling dispatch() on the front controller:
// Assuming $front is your front controller instance
$front->setParam('noViewRenderer', true);
If you're using a view object from the registry, or customizing your
view object, or using a different view implementation, you'll want to
inject the ViewRenderer with this object. This can be done easily at any
time.
* Prior to first instantiating a front controller instance:
// Assuming $view has already been defined
$viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
* After retrieving a front controller instance:
$viewRenderer =
Zend_Controller_Action_HelperBroker::getExistingHelper('viewRenderer');
$viewRenderer->setView($view);
There are many ways to modify the ViewRenderer, including setting a
different view script to render, specifying replacements for all
replaceable elements of a view script path (including the suffix),
choosing a response named segment to utilize, and more. If you aren't
using the conventional modular directory structure, you can even
associate different path specifications with the ViewRenderer.
Documentation is now in the repository if you want to get a jump on this
new feature. I strongly encourage you to start modifying your
controllers to make use of this helper; I did so in a site of mine while
developing this, and reduced my controller code by > 20%, and eliminated
several subclasses and plugins I'd created.
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
--
Andries Seutens
http://andries.systray.be
Gecontroleerd op virussen door de JOJO Secure Gateway.
