rlang Sun, 12 Feb 2012 12:26:31 +0100
Modified page: http://wiki.horde.org/Wiki/SandBox
New Revision: 3
Change log: ok, proofed. Moving this to a ticket
@@ -2,203 +2,5 @@
For reference, you might want to visit ((Wiki/Usage)),
((Wiki/TextFormat)) or ((Wiki/AddingPages)).
----
-[[toc]]
-+ 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:
-[ZF 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
-
-[ZF 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:
-<code>
- /**
- * 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');
- }
-</code>
-
-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 <[email protected]>
-
-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
__
commits mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
