When we create a view helper, on a Zend application, will that helper be available for ALL the views or, should we somehow tell that THAT view helper is available to a specific view?
What if, on the view folder "something", we have more then one file ? Any of those files can call it?
Thanks a lot,
MEM
When you call a view helper, the framework will look within the paths defined via $view->addHelperPath(). Typically, such a call will include a pseudo-namespace as well as a path:
$view->addHelperPath('My/View/Helper', 'My_View_Helper_');
Then when you call a view helper in a layout or a view script:
<?php echo $this->someHelper() ?>
The framework will do a LIFO search, appending the prefixes (in the above case: 'My_View_Helper_') to the classname 'SomeHelper' and then attempting to load the file defined by the addHelperPath() mapping.
In the default setup, the framework pre-loads the Zend view helpers by calling:
$view->addHelperPath('Zend/View/Helper', 'Zend_View_Helper_');
which is why you can use all the Zend-provided view helpers right out of the box.
Since all this processing is independent of which view script is making the call, it will work in any view script. [There are actually some issues associated to calling view helpers defined in other modules, but that's a separate issue.]
Related
I am trying to understand the architecture of Play Framework (internally how it works). In other framework like struts we can create index.html page and place in web folder with entry in web.xml file.
In Play the start point is main.scala.html page and all other pages inherited from it by placing all the content wrapped in
#main(title =""){
}
like index.scala.html page. But I couldn't find the place where main.scala.html page is registered to Play framework (no entry in routes file or other place?) or may be I am missing some points here.
So far from the play docs I understood that every scala.html page is basically a method call which sounds right to me.
So my goal is basically create other pages like main.scala.html page which will act as container for other sub pages and arrange my code in more modular way
Sorry if I am asking a dumb question.
Thanks in Advance
According to the Play docs main.scala.html is a layout - just common view which allows to inject HTML from other views and references to it by (content: Html) . main layout just wraps code that index view injected to it. (with optional arguments)
The opposite situation is usage of include or tag so just pointing the place where another view should be placed in the current view (also with optional arguments).
You don't need use them at all - Play doesn't enforce you to do that, you can use separate view (without layout) for each action.
On the other hand if some number of views should share same set of JS and/or CSS then layout(s) are native choice to do that job.
For an example instead of using main.scala.layout you can create ie. frontend.scala.html, backend.scala.html, guest.scala.html so your FE views will use #frontend(){ code...}, BE #backend(){ code... } etc.
You are unlimited in number of layouts/views/tags and other includes ;) All belongs to you. That's Play!
I am trying to create a sidebar in my layout that has the behavior of a placeholder. I want to be able to define the contents of this placeholder once per controller. So every controller can add custom content to the sidebar but without the need to define it in any view.
I am kind of confused on how to go about that with Zend_Layout. Any help?
I have tried something similar. Here is what you can do.
Place this type of code in the layout.phtml script file. Somewhere near the top. You don't have to but this way you 'know' what placeholders you're using. Doing this in the layout is also a good idea because you can wrap html divs are whatever here and not worry about it in the views. The views can just worry about the content. After this, you can add content to the placeholders from the controllers and the views.
$this->placeholder('blah');
$this->placeholder('sidebar');
$this->placeholder('blunk');
If you don't want to create them in your layout, then you can do it in the controller like so,
$this->view->placeholder( 'sidebar');
.
Now, you can either put content into it in the controller, or in the view script. Its a better idea to add the content in the view though.
In the layout you can then just echo the placeholders like so
echo $this->placeholder->( 'sidebar' );
All the views are executed BEFORE the layout is executed so any placeholders created by the views will be available to the layout to print out.
Also, controllers don't HAVE placeholders. Only views, and by extension layout, have placeholders like this so you have to declare them somewhere. Even if you declare them in the controller they still 'belong' to the view object.
I don't know if this helps at all but good luck. Tell me what you think.
How about adding a postDispatch() call to each controller?
public function postDispatch()
{
// code to populate/activate your placeholder
$this->view->placeholder('xxx');
}
This function will be called after your action completes. For more info, see Pre- and Post-Dispatch Hooks.
i have just implemented a solution to this that should work for most uses.
I store all of my placeholder.phtml files in the following dir:
/views/scripts/_placeholder
Within the placeholder i create directories for each Controller / Action that has a placeholder (as well as ROOT stuff). I then create a file for each placeholder.
e.g. Placeholder = sidebar. Controller = user / action = view
for the above we would store a file here:
views/scripts/_placeholder/user/view/sidebar.phtml
note: within the sidebar.phtml you will need to add : $this->placeholder("sidebar")->captureStart() and captureEnd();
if the plugin sees this file it will render it. If it doesnt find one then it wont.
Additionally the plugin will also look for the following and pull that in first:
views/scripts/_placeholder/sidebar.phtml
I can post the plugin if you want.
The only issue i have is i would like to now know if a placeholder has any data in it. That way i can create some layouts that are clever and will render what needs. DOes anyone know how to do this?
I'm putting together a ZF based CMS at the moment, and am currently caching my Zend_Navigation object, as well as the html rendered by renderMenu(). So at the moment, whenever the menu changes, I have to call the following lines in the relevant action:
$cache = Zend_Registry::get("cache");
$cache->remove("menu");
$frontcache = Zend_Registry::get("frontcache");
$frontcache->remove("menuhtml");
I have a siteController to handle changes to the menu structure, and a pageController to handle add/edit/delete of individual pages, so the code is used in actions in both of these controllers.
I would obviously like to put this code in a single method I can call, but where would be the most appropriate place? An action helper? A parent class for siteController & pageController? Should I combine the controllers? Or something else?
Have you looked at using an Action Helper ( http://framework.zend.com/manual/en/zend.controller.actionhelpers.html )? This will give you a place that's independent of your controllers that each controller will still be able to call.
How about a service? Application_Service_Navigation (or whatever appnamespace you are using) stored in application/services/Navigation.php, implementing an interface representing the CRUD operations in those two CMS controllers. Then internally, these methods can use the cache as you have described. Controllers call the service methods and are unaware of the cache operations.
I have a layout which works fine. This layout contains several partials, which display adverts, a side column a slideshow, etc. All of these are likely to change depending on which page (module/controller/action) of the site you are on.
What is the best way of doing this correctly? In the past I have assigned variables to my view inside my controllers, these are then passed to the partial which then displays the correct slideshow or advert. This seems ugly and not entirely correct for an MVC application.
Does anyone have any other methods of doing this?
Partials are just another view scripts.
My advice is: newer put your logic into the view scripts. Your may store the logic in:
models (remember, that you can create your own models, extending, or not extending the basic database models, eg. data hydrators)
view helpers (with parameters)
services (dependent on models, returning models)
combination of the above
Then use view helper or pass the ready data (model) to different partials.
Tip: Dependency injection is a good thing.
Zend_Form:: When should be form created in view and not in controller?
option 1 - form created in controller and passed to view (usually used)
controller:
$form=new MyForm();
$this->view->form=$form;
view:
echo $this->form;
option 2 - form created in view directly (looks better to me because form its subpart of view)
view:
$form=new MyForm();
echo $this->form;
Thanks
In short: newer in view.
You may eventually:
create view helper for complex tasks (and call the helper in view $this->getForm()),
or use Model::getForm()
or service::getForm() when you need cross-action forms.
Further explanation:
Because in the ideal case, views contain only HTML, to separate logic from presentation (MVC).
When using TDD, you write tests for logic, never for view scripts, which are only clothes for the variables.
Displaying the form, is not only the form itself, but also checking whether it was submitted or not, checking for validation errors, setting flash messenger variables and much more.
These are too complex tasks for putting them to view scripts.
As a good exercise on separating logic and presentation, I recommend you to take a look at PHPTAL template language, which is a nice alternative to native PHP as a template language used in ZF.
If a form appears in, say, the sidebar of a layout - like a "Subscribe to our mailing list" form - it seems reasonable to allow the view to create/render it on its own, though I'd probably do it within a view helper rather than have any new My_Form() calls in a view script. Why force every controller to deal with it?
As Padraic Brady notes in his online ZF book Surviving the Deep End: "Controllers Are Not The Data Police".
I think the only first variant is correct, because Zend_Form is not presentation entity, but business logic entity. So it's wrong to try to instantiate it in the view. If you want simply display some form just mark up it directly in HTML - this will be much more easier for coder at least.
Think about your team mates, are your designers( or graphical integrators ) programmers too? that approach will break down re-usability, and tasks separation.