Zend Framework: Zend_Template Component Proposal
| Proposed Component Name | Zend_Template |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Template |
| Proposers | Ramses Paiva Sourcebits Technologies |
| Zend Liaison | TBD |
| Revision | 0.1 - 1 October 2008 (wiki revision: 16) |
Table of Contents
1. Overview
The main purpose of Zend_Template is to hold in a single place an interface to manipulate the whole view environment, using layouts or not, making the job of assigning different settings (like paths, view and layout suffixes, etc) to the view environment more easier than it already is.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
Simple API to center the whole view enviroment management like:
- Set a common directory for templates (views and layouts).
- Set a common file suffix.
- Set default template.
- Change the template in use at anytime and anywhere in the application (preferencially in controllers).
- Enable or disable layout at anytime.
- Assign different paths for layouts and views.
- Assign different suffixes for layouts and views
- Assign different access rules for the views (like ':module/:controller/:action.:suffix')
- Capacity to enable and disable it at anytime and anywhere on the application and when disabled, the default framework settings will be assumed.
4. Dependencies on Other Framework Components
- Zend_Config
- Zend_Controller_Action_Helper_ViewRenderer
- Zend_Controller_Action_HelperBroker
- Zend_Exception
- Zend_Layout
- Zend_View
5. Theory of Operation
Zend_Template is a singleton component to keep the view and layout settings in the whole application's life-cycle.
You can retrieve an instance throught its getInstance() method or through startMvc().
6. Milestones / Tasks
- Milestone 1: Acceptance of Proposal.
- Milestone 2: [DONE] Code basic interface.
- Milestone 3: Code main class.
- Milestone 4: Write unit tests.
- Milestone 5: Write documentation.
- Milestone 6: Working prototype checked into the incubator supporting all use cases.
7. Class Index
- Zend_Template
- Zend_Template_Exception
- Zend_Template_Interface
8. Use Cases
| UC-01 |
|---|
Basic usage:
In the bootstrap.php:
| UC-02 |
|---|
Basic usage using Zend_Layout:
In the bootstrap.php:
| UC-03 |
|---|
Setting some specific configuration:
In the bootstrap.php:
| UC-04 |
|---|
Using with Smarty:
In the bootstrap.php:
| UC-05 |
|---|
Using in your controllers:
9. Class Skeletons
Hi Peter,
First of all, thanks for your feedback.
Actually, I'm just implementing a Facade Pattern (http://en.wikipedia.org/wiki/Facade_pattern), encapsulating all the view environment, without affecting the subsystem functionality. If I change the Zend_Controller, I would have to change existing code and probably change existent functionality. In addition, if the Zend_Controller holds the ability to directly handle the view environment, then you would be able to handle the view environment only there or writing action plugins for this.
What I want with this proposal is to provide a simpler interface to handle the view environment anywhere (especially in the bootstrap) and keep these settings in the whole application's life-cycle.
Most of my projects, share a few Plugins that I use to set view configs (layout, paths, etc), so this proposal COULD be useful, but not sure yet. Anyway, what I don“t like at all is the name Zend_Template. Template looks like layout, and it is not. Renaming the class would help to undertand its goals.
Hi Oscar,
Thanks for your feedback.
Yes, you're right. Maybe the name is not accomplishing the exactly goal for this component. But once it's going to handle the view AND layout objects, and also its helpers, so I'm not sure which name would be better. I've choosen Template because you can use it in combination with a template engine, but, as you said, it's not a template engine, it's only a handler for this.
Any suggestions?
Hello Ramses
I don't think your requirements require another component.
I understand your first two points. If you want to use Zend_Layout and Zend_view together you have to repeat these steps twice.
- Set a common directory for templates (views and layouts).
- Set a common file suffix.
As far as the remaining requirements, they are already implemented. I think your proposal creates a lot of overhead.
- Set default template.
- Change the template in use at anytime and anywhere in the application (preferencially in controllers).
- Enable or disable layout at anytime.
- Assign different paths for layouts and views.
- Assign different suffixes for layouts and views
- Assign different access rules for the views (like ':module/:controller/:action.:suffix')
Hello Michael,
Thanks for your feedback.
Actually, it's not exactly like that.
For example, when I mean change the default template, I don't mean change the default layout (what's currently supported), but the whole view environment (client side scripts, style sheets, view scripts, layout scripts).
Again, change the default template in use at anytime is not implemented also if we consider the above.
Enable and disable layout ok, it's already implemented, but you also have the option to disable the whole rendering process, without having to remove the view renderer helper, disable the layout and so on. You simply call Zend_Template::getInstance()->disableRendering() or to simply disable the layout in use, you can disable the layout the way you want (using Zend_Template or directly using Zend_Layout, once both are singleton objects it will have the same effect).
Basically, Zend_Template would be supposed to make easier to change the view environment at runtime, without having to access more than a single object to achieve this.
For example, I have an application that has different client interfaces, one for web, one for blackberry, one for iphone and a general one for all other smart devices and each one has their own particularities and functionalities. I can change the whole view environment to each one easily accessing this single object, without having to write more than a single line of code to do that.
Also, I could have an application with lots of different skins and the skin could be choose by the user. And also these skins could be developed by third party and submitted to the application to be used by the users dynamically.
Or a simple interface, without a rich css and javascript implementation and another one with lots of css resources, flash and ajax features, etc.
I'm still thinking that a single object would make all this job much easier than it currently is.
Two new features I've added in my test version are:
Now, I can set the encoding and spread it along the application.
Now, I can set the virtual address to my static files, like images, client scripts and style sheets.
I also have a helper to manipulate the Zend_Template object now, so I can use it on my views simply using $this->template(). It's a read only based helper, so it's supposed just to retrieve information that concerns to the view to be retrieved.
ZF Home Page
Code Browser
Wiki Dashboard
Shouln't it be better to make some adjustments to Zend_Controller to accomplish this? That is a lot better than just make a separate component for this.