Horde_View
PHP 5 library targetted for Horde 4 that implements a view pattern.
Bugs
People
ChuckHagenbuch is the primary author of Horde_View.
Description
Notes on views and templates
Some of this may be badly outdated.
http://blog.sig9.net/2008/01/21/template-engines/
I use the Two Step View pattern. My applications render content to the
response object (just the application content, none of the site
skeleton), and then in a dispatchLoopShutdown() plugin I pull the
response content and inject it into a sitewide template, and finally
inject that rendered content back into the response object. I've
provided a sample of such a plugin in the past on either the fw-mvc or
fw-general list.
http://paul-m-jones.com/blog/?p=247
http://framework.zend.com/wiki/display/ZFMLGEN/mail/27145
http://www.ingredients.com.au/nick/2006/06/10/getting-to-know-zend\_view/
http://fosterburgess.com/kimsal/?p=237
Horde_View notes:
- http://benramsey.com/archives/zend-framework-view-notes/
- some way to automatically call views
- should I change from "script" to "template"?
To read:
rev 4332:
- Add optional ability to generate notices for undeclared variables in
templates. Use $view->strictVars(true); to turn on functionality
- Added Zend_View_Helper_DeclareVars helper. Allows developer to optionally
declare template variables and default values. When used with
strictVars(), will prevent notices by declaring unused variables in the
view object
rev 4338: Added getScriptPath($name), getHelperPath($name),
getFilterPath($name), getHelper($name), getFilter($name), and getFilters()
methods. Notes:
- getHelper() and getFilter() will instantiate the filter of $name if not
already instantiated
- getHelpers() and getFilters() only return already instantiated helpers and
filters; i.e., they won't return all helpers and filters available
- getHelperPath() and getFilterPath() will instantiate the associated helper
or filter in the process of discovering the path, if not already
instantiated
View notes:
We're using some different "views" to get a useful layout for each purpose.
We start using:
- portal-layout.php
- clean-layout.php
The first one has the header, footer, top menu, the main content and optionally the left and right menus. The clean layout only has the header and footer.
So, in our scripts we can do the following (extending the Zend_View component):
$view = new TemplateView();
$view->tplMain = 'articles/view.php';
$view->tplLeft = 'articles/leftMenu.php';
$view->tplRight = 'articles/contextual.php';
$view->articles = $oArticles->get();
$view->render('portal-layout.php');
The "portal-layout.php" is constructed this way:
$this->render('header.php');
$this->render('topMenu.php');
if(isset($this->tplLeft))
$this->render($this->tplLeft);
$this->render($this->tplMain);
if(isset($this->tplRight))
$this->render($this->tplRight);
$this->render('footer.php');
ACLs and views
I'm not quite sure how I should use ACL with Views. I have a menu where I'd like items not to be visible if users role(s) have no access to it. So I was planning on doing array of the menu items and passing that to the view or passing the whole ACL object to view.
Definitely go for the array of menu items. A simple rule to follow is give the view simple data structures only. Otherwise, should your application code switch from Zend_Acl to something else, you would need to change every view involved.
One simple approach that i user is to set up a dir like:
/app/views/public/modules/
I have view helper RenderModule:
/**
* renders a module:
* moduleDir_moduleName
*
* @param string, module
*/
public function RenderModule($module){
$view = Zend_Registry::get('view');
$config = Zend_Registry::get('config');
$path = $config->view->publicModules;
$currModule = str_replace('_','/',$module);
return $view->render('./' . $path . '/' . $currModule . '.tpl.php');
}
so for the show new news module:
dir: /app/views/public/modules/news/newNews.tpl.php
to render it (in the view):
echo $this->RenderModule('news_newNews');
Hi Padraic,
I'm currently playing with a portal-like behaviour. I implemented a number of Controller/View pairs as portlets that can be layouted in any way you want on a webpage.
I was initially not planning to mention this so early but to announce it later in this list when it is more mature, but anyway, this little add-on might be of help for you. There's a little demo on
http://www.rehno.de
which shows a simple and ugly wireframe layout (simple table layout) that are completely code-driven, i.e. you can adjust them dynamically during runtime. There are three demos on this page: a form example which shows how forms can be implemented as portlets and submitted/ evaluated independently of each other. The second example is a link example which shows how intra-portlet navigation can be implemented. The third example is a modification example which shows how one portlet might change the content of another area of the layout.
Please enable the Inplace debug output to get a better feeling about layouting and portlets within the layout cells.
If you like the demos and like to contribute or give feedback, feel free to contact me!
Regards,
Stephan
http://blog.astrumfutura.com/archives/282-Complex-Views-with-the-Zend-Framework-Part-2-View-Helper-Pattern.html
I currently use a programmatic description for the layout, it is stored into so-called containers which are built of frames which in turn might contain further (sub) containers or portlets.
It basically looks like this:
$container = new ContainerModel(ContainerModel::VERTICAL);
$container->addFrame("topmenu", "TopMenu", ContainerModel::MAXSIZE);
$subcontainer = new ContainerModel(ContainerModel::HORIZONTAL, $container);
$subcontainer->addFrame("mainspace", null, ContainerModel::MAXSIZE);
$container->addChild("contentspace", $subcontainer, ContainerModel::MAXSIZE);
As mentioned before, containers might be presented horizontally or vertically. The addFrame() command is passed the frame identifier, the portlet controller name (might be null) and the sizing.
The rendering is done using the container controller:
$controller = new ContainerController($container);
$controller->setRequestResponse($this->_request, $this->_response);
which is passed to the view. In the view.tpl.php file,
echo $this->containerController->render();
is called. Using the php DOM parser, I'm replacing all hyperlinks in the portlets' html output. That's about it :)
The implementation however is far from being complete. For example there is only a limited number of error checks implemented currently, also frame size is only supported in a limited why as I'm using tables for layouting. div sections are probably better.
Date: Thu, 19 Apr 2007 12:48:33 -0500
From: Dale McNeill <dale.mcneill@alchemysystems.com>
I use a dispatchLoopShutdown plugin. This plugin is able to deal with both AJAX responses as well as a normal HTML response. Here's the code:
class SiteTemplatePlugin extends Zend_Controller_Plugin_Abstract {
public function dispatchLoopShutdown\(\)
\{
* assume that we've already determined the request is ajax
$request = $this-\>getRequest\(\);
$response = $this-\>getResponse\(\);
$view = Zend\_Registry::get\('view'\);
if \($request-\>getParam\('isAjax'\)\) \{
* Ajax request detected
* Get any variables set in the view
$vars = get\_object\_vars\($view\);
* Merge with named path segments in response
$vars = array\_merge\($vars, $response-\>getBody\(true\)\);
* Create a header and set the response body to a JSON value
$response-\>setHeader\('Content-Type', 'text/x-json'\);
$response-\>setBody\(Zend\_Json::encode\($vars\)\);
return;
\}
* Otherwise, process as normal
$view-\>assign\($response-\>getBody\(true\)\);
$response-\>setHeader\('Content-Type', 'text/html'\);
$response-\>setBody\($view-\>render\('site.php'\)\);
\}
}
The site wide template that I use is composed of a header, 3 columns, and a footer. The header and footer are the same for each page. I assign the content for each column by appending the response object with a named section. The named sections eventually become the view variables used in the site template. Here's an example of a normal HTML response:
class IndexController extends Zend_Controller_Action {
* Normal HTML response
public function indexAction\(\)
\{
$response = $this-\>getResponse\(\);
$view = Zend\_Registry::get\('view'\);
$view-\>title = 'My Index Title';
$response-\>appendBody\($view-\>render\('index\_css.php'\), 'inline\_css'\);
$response-\>appendBody\($view-\>render\('index\_left.php'\), 'left\_content'\);
$response-\>appendBody\($view-\>render\('index\_center.php'\), 'center\_content'\);
$response-\>appendBody\($view-\>render\('index\_right.php'\), 'right\_content'\);
\}
* AJAX response
public function viewAction\(\)
\{
$request = $this-\>getRequest\(\);
$request-\>setParam\("isAjax", true\);
$view = Zend\_Registry::get\('view'\);
$view-\>status = 0;
$view-\>message = "Problem encounted";
}
}
Here's the site wide template:
W3CDTD XHTML 1.0 StrictEN" "http:*www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"\>
http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<?php echo $this->escape($this->title); ?>
\