From 06f945f27840b53e57795dadbc38e76f7e11ab1c Mon Sep 17 00:00:00 2001 From: Horus3 Date: Mon, 24 Feb 2014 16:42:14 +0100 Subject: init --- .../documentation/manual/core/en/migration.10.html | 389 +++++++++++++++++++++ 1 file changed, 389 insertions(+) create mode 100644 zend/documentation/manual/core/en/migration.10.html (limited to 'zend/documentation/manual/core/en/migration.10.html') diff --git a/zend/documentation/manual/core/en/migration.10.html b/zend/documentation/manual/core/en/migration.10.html new file mode 100644 index 0000000..007343f --- /dev/null +++ b/zend/documentation/manual/core/en/migration.10.html @@ -0,0 +1,389 @@ + + + + + Zend Framework 1.0 - Zend Framework Manual + + + + + + + + +
+ + + + + + + + +
+ Zend Framework 1.5 + +
Zend Gdata Migration Notes
+ Programmer's Reference Guide
+ 		+ +
+
+

Zend Framework 1.0

+ + +

+ When upgrading from a previous release to Zend Framework 1.0 or higher you + should note the following migration notes. +

+ +

Zend_Controller

+ + +

+ The principal changes introduced in 1.0.0RC1 are the introduction of + and default enabling of the + ErrorHandler + plugin and the ViewRenderer + action helper. Please read the documentation to each thoroughly to + see how they work and what effect they may have on your + applications. +

+ +

+ The ErrorHandler plugin runs during + postDispatch() checking for exceptions, and forwarding + to a specified error handler controller. You should include such a + controller in your application. You may disable it by setting the + front controller parameter noErrorHandler: +

+ +
  1. $front->setParam('noErrorHandler', true);
+ + +

+ The ViewRenderer action helper automates view injection + into action controllers as well as autorendering of view scripts + based on the current action. The primary issue you may encounter is + if you have actions that do not render view scripts and neither + forward or redirect, as the ViewRenderer will attempt + to render a view script based on the action name. +

+ +

+ There are several strategies you can take to update your code. In + the short term, you can globally disable the + ViewRenderer in your front controller bootstrap prior + to dispatching: +

+ +
  1. // Assuming $front is an instance of Zend_Controller_Front
    2. +
  2. $front->setParam('noViewRenderer', true);
+ + +

+ However, this is not a good long term strategy, as it means most + likely you'll be writing more code. +

+ +

+ When you're ready to start using the ViewRenderer + functionality, there are several things to look for in your + controller code. First, look at your action methods (the methods + ending in 'Action'), and determine what each is doing. If none of + the following is happening, you'll need to make changes: +

+ +
    +

  • Calls to $this->render();

    • +

  • Calls to $this->_forward();

    • +

  • Calls to $this->_redirect();

    • + +
  • +

    Calls to the Redirector action helper

    +
    • +
+ +

+ The easiest change is to disable auto-rendering for that method: +

+ +
  1. $this->_helper->viewRenderer->setNoRender();
+ + +

+ If you find that none of your action methods are rendering, + forwarding, or redirecting, you will likely want to put the above + line in your preDispatch() or init() + methods: +

+ +
  1. public function preDispatch()
    2. +
  2. {
    3. +
  3.     // disable view script autorendering
    4. +
  4.     $this->_helper->viewRenderer->setNoRender()
    5. +
  5.     // .. do other things...
    6. +
  6. }
+ + +

+ If you are calling render(), and you're using the Conventional Modular + directory structure, you'll want to change your code to + make use of autorendering: +

+ +
    +
  • +

    + If you're rendering multiple view scripts in a single + action, you don't need to change a thing. +

    +
    • + +
  • +

    + If you're simply calling render() with no + arguments, you can remove such lines. +

    +
    • + +
  • +

    + If you're calling render() with arguments, and + not doing any processing afterwards or rendering multiple + view scripts, you can change these calls to read + $this->_helper->viewRenderer();. +

    +
    • +
+ +

+ If you're not using the conventional modular directory structure, + there are a variety of methods for setting the view base path and + script path specifications so that you can make use of the + ViewRenderer. Please read the ViewRenderer + documentation for information on these methods. +

+ +

+ 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 dispatching a front controller instance: +

    + +
    1. // Assuming $view has already been defined
      2. +
    2. $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
      3. +
    3. Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
    + +
    • + +
  • +

    + Any time during the bootstrap process: +

    + +
    1. $viewRenderer =
      2. +
    2.     Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
      3. +
    3. $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. +

+ +

+ We encourage you to adapt your code to use the + ErrorHandler and ViewRenderer as they are + now core functionality. +

+
+ +

Zend_Currency

+ + +

+ Creating an object of Zend_Currency has become simpler. + You no longer have to give a script or set it to NULL. The optional + script parameter is now an option which can be set through the + setFormat() method. +

+ +
  1. $currency = new Zend_Currency($currency, $locale);
+ + +

+ The setFormat() method takes now an array of options. These + options are set permanently and override all previously set values. Also a new option + 'precision' has been added. The following options have been refactored: +

+ +
    +
  • +

    + position: + Replacement for the old 'rules' parameter. +

    +
    • + +
  • +

    + script: + Replacement for the old 'script' parameter. +

    +
    • + +
  • +

    + format: + Replacement for the old 'locale' parameter which does not + set new currencies but only the number format. +

    +
    • + +
  • +

    + display: + Replacement for the old 'rules' parameter. +

    +
    • + +
  • +

    + precision: + New parameter. +

    +
    • + +
  • +

    + name: + Replacement for the ole 'rules' parameter. Sets the full + currencies name. +

    +
    • + +
  • +

    + currency: + New parameter. +

    +
    • + +
  • +

    + symbol: + New parameter. +

    +
    • +
+ +
  1. $currency->setFormat(array $options);
+ + +

+ The toCurrency() method no longer supports the optional + 'script' and 'locale' parameters. Instead it takes an options array which + can contain the same keys as for the setFormat() method. +

+ +
  1. $currency->toCurrency($value, array $options);
+ + +

+ The methods getSymbol(), + getShortName(), getName(), + getRegionList() and + getCurrencyList() are no longer static and can be called + from within the object. They return the set values of the object if no + parameter has been set. +

+
+
+
+ + + + + + + + + +
+ Zend Framework 1.5 + +
Zend Gdata Migration Notes
+ Programmer's Reference Guide
+ 		+ +
+		 + +
+ + \ No newline at end of file -- cgit v1.2.3