Hi,
I just started playing with the Zend Framework, and I'm basically following the tutorial on Akra’s DevNotes.

I have my own little framework that I've developed by myself, and it works fine, but I want to take it to the next level, and juse ZF. Anyway, I use the output buffer to echo out inner templates in outer templates. Can't this be done in ZF? I really don't like the concept of headers and footers, because I want the main design to be in just one file.

And another thing that striked me. If I would want to extend some of the ZF-classes, what would be best practise for that? I mean, I shouldn't place it in the library-folder, since I want a clean separation between "real" ZF-classes, and my own extensions. But it I place them somewhere else, how would I go about including them in a clean and consistent way?

And yet another thing, do I have to have an init-method in all of my controllers? Seems like duplicating code just for initializing the view.

Thanks!

I am going to reply one by one to your questions.

Concept of header and footer i find it stupid too... So, i made my own Cntroller action

class Imagis_Controller_Action extends Zend_Controller_Action
{
public function init()
{

$this->initView();

//view pages init
$this->view->menu_top = $pages->GetTag("TOP_MENU", "'y'");
$this->view->menu_bottom = $pages->GetTag("BOTTOM_MENU", "'y'");
$this->view->menu_main = $pages->GetTag("MAIN_MENU", "'y'");

//init
$this->view->page_info = $page_info;
$this->view->routei = $routei;

}

public function render($action = null, $name = null, $noController = false)
{
$script = "global_index" . DIRECTORY_SEPARATOR . "global_index" . '.' . $this->viewSuffix;

$view = $this->initView();
$this->getResponse()->appendBody( $view->render($script), $name );
}
}

So, i am rendering an "global_index" file, and into global index this i am going to render specific views needed, depending on page...

I am still "new" on MVC over Zend maybe this is not the best approach...

__________________
Zend Framework Tutorials | Zend Framework Forums | Zend Framework IRC Channel |
| Zend Framework Resources | CoreShifter

Btw, also concept of header and footer is quite stupid. And useful only on small sites.

Complex sites have different headers and footers depending on page.

I am personally using a multi-layer approach:
1. index file (can be 1-2-3 index files per site depending on site; sample: normal site index, index for a popup which shows some informations, aso)
index is covering just some "header and footer" things
2. layouts - each index file can have multiple layouts (sample: layout for homepage, layout for simple text page, layout for products, layout for products categories); for one page is just one index and one layout;
layout is basically the layout of content files, with zones, each zone been filled with a zone file
3. zone files - each layout can have multiple zones, each zone stored in his own file; for one page is one index, one layout and one or more zones;
some zones can be used for multiple layouts. Sample: a "new products" zone can be bound to homepage, some of the content pages, aso...

So, i am using this approach, a database with pages:
- page id
- index file
- layout used
- list of zones for that layout
- also other info suitable for that page (page title, and so on)

Is a bit complicated to move to ZF this approach, i don't like quite too much MVC on ZF personally atm, exactly due to not having one "view bootstrapper"... He has just a bootstrapper, not one for view side also... So, i need to customize lot of things...

__________________
Zend Framework Tutorials | Zend Framework Forums | Zend Framework IRC Channel |
| Zend Framework Resources | CoreShifter

who says a header and footer approach is required? Zend Framework, in a sense is not an actual framework yet because it doesn't exactly force you to do something their way. So basically anything you want you can do your way.

As with the question of separating your code from zend's. Basically there are several ways to do this:
- add path in include_path in php.ini
- add path using set_include_path();
- remember to append get_include_path();

__________________
Zym Framework - A Zend Framework extension library w/ demo app

SpotSec Blog:
http://spotsec.com/blog

Ok, in fact the current approach - on default behavior - is forcing to display a view... So, to work simpler would be needed a header and footer included... Otherwise lot of custom coding and also basically views system is almost useless, also controller side is not so usefull...

__________________
Zend Framework Tutorials | Zend Framework Forums | Zend Framework IRC Channel |
| Zend Framework Resources | CoreShifter

? zend doesnt exactly force you to use a view, you can pass the html to the response object or echo it directly from the controller

simply speaking, if you wanted it done that way, then you can have different controller classes. For example, you could have one that included the header and footer automatically.
Personally I have different controller classes for handling different services (json, soap, xml, etc...)

__________________
Zym Framework - A Zend Framework extension library w/ demo app

SpotSec Blog:
http://spotsec.com/blog

Working with composite views is a common problem a lot of framework developers run into. Applying the DRY principal to view logic and trying to maintain the KISS principal can be a huge pain. The nature of markup tends to be very repetitive. Not only is it competitive often times you have several types of markup within an application (XML, XHTML, WAP). Creating markup components and dynamically injecting them into a aggregate to be rendered to the user generally meas it's a easier to manage the individual components but in many cases impossible for non developers to modify the look and feel of an application without developer interaction. This kind of kills one of the goals separations is after.

One thing I currently utilize is a series of libraries I created to compile composite views. I have a library that will recursively inject rendered view content into a single view script which can then be edited by a designer or loaded with a controller. This alleviates a few steps in the rendering process as well. The compiled view can also be decompiled to re-organize or re-factor shared components.

Ultimately whether you use some kind of view compilation or a lot of redundant view code, composite views are still the way to go for now.