rlang Sun, 12 Feb 2012 12:25:50 +0100
Modified page: http://wiki.horde.org/Wiki/SandBox
New Revision: 2
Change log: Trying to reproduce a bug
@@ -2,5 +2,203 @@
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]
