Skip to end of metadata
Go to start of metadata

Zend Framework: Zend_View_Adapter_Smarty Component Proposal

Proposed Component Name Zend_View_Adapter_Smarty
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_View_Adapter_Smarty
Proposers Satoru Yoshida
Revision 0.3 - 22 Dec: Renewal all methods.
0.2 - 3 Dec 2008: Change name from Zend_View_Wrapper_Smarty to Zend_View_Adapter_Smarty.
0.1 - 22 Nov 2007: Create Proposal. (wiki revision: 13)

Table of Contents

1. Overview

Zend_View_Adapter_Smarty is a adapter of Smarty.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will provide several methods and properties to controll variables and clear cached|compiled templates.
    If you want to use full Smarty methods, you can use them via getEngine().
  • This component will be one of adapters. So I do not name this component Zend_View_Smarty, but Zend_View_Adapter_Smarty.

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_View_Interface

5. Theory of Operation

  • At First, You are ready to use this component with instantiation.
    • As necessary, You use some methods, for example, setWorkPath(), or setScriptPath().
  • At second, You can assign variables by assign().
  • At last, You get output by render() or output().

6. Milestones / Tasks

  • Milestone 1: Class development and write proposal
  • Milestone 2: Unit tests and debugging
  • Milestone 3: Documentation

7. Class Index

  • Zend_View_Adapter_Exception
  • Zend_View_Adapter_Smarty

8. Use Cases

UC-01
UC-02

9. Class Skeletons

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

15 Comments

comments.show.hide

  1. May 13, 2008

    Wil Sinclair

    Satoru, is this proposal ready for community review?

    ,Wil

    1. May 15, 2008

      Satoru Yoshida

      Hello, Wil. Yes, I believe it is ready. I announced ML about MVC in 27th Nov 2007, but I have no responces.

      1. Jun 20, 2008

        Wil Sinclair

        It should be moved to 'Ready for Review'. When you do this, I suggest you announce it to the mailing list again. People may not realize that the first draft is complete.

        ,Wil

  2. Jul 04, 2008

    Harro van der Klauw

    Nice.. how will helpers be added?
    Or will those be wrapped to so you can register_block's, register_modifiers, register_function based on the Helper?

    1. Dec 22, 2008

      Satoru Yoshida

      Hi, Harro.
      Thank you for taking interest.
      I will study for further discussion.

      (add 22th Dec 2008)
      I write how to add helper in use case 1.
      You can use register functions via getEngine() methods.
      $engine = getEngine(); $engine->register_xxxx();

  3. Sep 25, 2008

    Tobias Gies

    Is this proposal still active?

    1. Nov 20, 2008

      Satoru Yoshida

      Hi, Tobias.

      Sorry that I have been absent for a long time.
      I can take a little time now for this proposal.

  4. Oct 23, 2008

    Matthew Ratzloff

    • Are there possible integration points with ViewRenderer?
    • Will this use Zend_View helpers, Smarty helpers, or both? How will they work?
    • Zend_View_Adapter_Smarty seems more consistent with the rest of the framework.

    1. Nov 20, 2008

      Satoru Yoshida

      Hi, Matthew.
      I will feel happy if you wait my answer about first and second question .
      I agree on your pointing out about the class name.

  5. Dec 08, 2008

    Ashley Kitson

    Satoru

    I've been discussing Smarty integration with a member of the ZF team and he has pointed me in your direction with this proposal.

    On brief reading of your proposal, It may be something that I would be interested in moving forward with you on. I do see a very real need to support the Smarty system within ZF;

    1/ there is a lot of goodwill for Smarty and takeup of Smarty in thousands of websites, which in turn means that there is a potential market for conversion of those sites to the ZF framework. I've already done a few.
    2/ it offers a relatively simple interface for creative designers to implement their designs based on solid content output from programmers;

    <div class="myClass">{$someContent}</div>
    is a lot easier on the eye, and less verbose, for a creative designer than
    <div class="myClass"><?php echo $this->view->$someContent ?></div>
    and that's just a simple case!

    3/ Smarty works! I know that the way it is written does not necessarily hold true to the way in which we might write it now, but it does work.

    The issues I have faced are largely to do with getting the ZF MVC model to work nicely with Smarty. Forwarding doesn't work very well in my experience and there are other glitches. In ZF for instance the Zend_Layout class doesn't play with ViewRenderer properly in its naming conventions (Thanks MWP for that ), meaning that you have to tell the system twice that you want to see .tpl template file extensions, (important if you don't want to rename all your smarty templates from a legacy site.

    I am lead to believe also that Smarty cannot be included in a ZF distribution due to clashes in licensing models. Therefore, a Zend_View_Smarty (or in your proposal case Zend_View_Adapter_Smarty) may never be adopted as a core piece unless we treat Smarty as an effective external service, to be installed or not as decided by the client programming team. Take for example the Zend_Wildfire class. That is possible because the code can be included within ZF. Apparently the Smarty license doesn't allow distribution within ZF, (I'm not a lawyer, but I do trust Zend's if they say it cannot be done.)

    So, what is to be done?

    1/ treat Smarty as a service (and I suppose therefore to be really pedantic, rename your proposal to Zend_Service_Smarty.) This means that it is optional and requires some work by the implementer to initiate, (i.e. download Smarty - I have mine as a subversion working copy)

    2/ treat the service as an extension of Zend_View

    3/ write in the integration to Zend_Layout as part of the constructor to the service.

    4/ make Smarty behave as though it were a native rendering mechanism to ZF

    5/ build in the ability to add decorators (smarty plugins) with the same calling convention as native Zend_View. Tall order I know!

    6/ extend the service class to give developers access to the full Smarty API via method calls to the ZF Smarty service.

    For all this, I want to make his work and therefore am happy to assist in any way that I can.

    Kind Regards
    Ashley

    1. Dec 11, 2008

      Satoru Yoshida

      Hi, Ashley. Thank you for interest on this proposal.
      I think that users will download Smarty file apart from the Zend Framework.

      Satoru Yoshida.

      1. May 11, 2009

        Satoru Yoshida

        Hello,
        I will be happy if you close and archive this .

  6. Jul 29, 2009

    Benjamin RICHARD

    Hi,
    am trying your adapter, but i still have some troubles:
    i had some problems at the beginning because of cache and templates_c folders writable rights. But this point is solved now.
    In fact :
    my layout file is still called using phtml scripts (not Smarty) from folder APPLICATION_PATH.'/layout/scripts'
    my smarty views files are not called (they are in APPLICATION_PATH.'/views/smarty/templates', for controller loginController the index.tpl is here : APPLICATION_PATH.'/views/smarty/templates/login/index.tpl')

    i use your first use case on a ZF 1.6.x

    Thanks for help

    1. Jul 29, 2009

      Satoru Yoshida

      Hi, Benjamin.

      Sorry , I am inactive on this proposal now.
      I will be happy if you want to improve this.

      Thanks!

  7. Feb 06, 2011

    Dolf Schimmel (Freeaqingme)

    Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.