Page 8 of 9
Posted: Wed May 02, 2007 12:48 pm
by Christopher
I guess there is logic to both directions, but the "action" directory itself is empty in the Zend scheme. Honestly, given how few files there usually are per module in reality and that the filenames can end with *Controller.php, *View.php and *Model.php they don't even need to be in directories. I am just looking at all the code littering the codebase to deal with this nonsense.
My hack above lets each MVC component know were it lives independent of being told by the Front Controller or Request. So it can find its dependent files below it, or reference off the application root directory for "global" Models and Views. That also frees those classes to go back to what they actually are rather than being the monsters then have become.
I have hacked together a simplified, hierarchical View, along with a simple PHP template class made from the template code pulled out of the Zend_View. When I have a demo together I will zip it up for people to looks at.
Posted: Thu May 03, 2007 8:12 pm
by Christopher
Ok ... here is a very simplified demo application that has the basic "bootstrap" layout we have discussed. I throw everything in one directory for simplicity -- sure to annoy some. It uses the standard Zend files in the bootstrap, but I have created a custom
Zps_Controller_Action,
Zps_View and
Zps_Template_Php classes. The Action and View use my self-discovery hack to find out their path rather than having to be told. The Template class just takes the template code out of Zend_View and puts it in its own class. The Zps_View supports any template class with a render() method and Value Object style properties to use as tag/values -- that could be changed to make it easier to integrate template libs.
But the main point of this exercise was to support hierarchical Views, which the Zps_View does. The example has a main view that assigns a sub-View and a content string as page elements. There are comments in the code and some debug is printed to show what's happening in rendering the Views.
You can download it from the link below. Extract it into any directory in a webserver's public folder and it should just work. The latest ZF must be installed and in the include_path -- or you will need to add a link to the ZF library directory in the "application" directory.
http://ap3.sourceforge.net/zpsdemo02.zip
I like the simplicity, but building it leaves me with more questions than answers. The entire concept/rules for rendering a tree needs to be thought out. And since my Zps_View is template-less then there should be more thought about how to create an easy way to get the current crop of template systems to work easily with it. It probably needs more automation to make it easier to create Views, sub-Views, Templates (and Models too I suppose).
Let me know if this direction makes any sense to anyone.
Posted: Tue May 08, 2007 5:13 pm
by Christopher
Well I got such an exciting response from my last post that I thought I would ... just keep going.
I created a new Response class (Zps_Controller_Response_Http) with support for Lazy Loading and rendering a default outer Template View. The goal is to simplify and focus the Views on just rendering the content area. Because the renderer is Lazy Loaded, you can also assign a replacement renderer to the Response (inside the Controller/View) and the default one is never loaded.
So between dispatch and rendering it looks like this:
Code: Select all
$Response = $Front->dispatch();
if (! $Response->hasRenderer()) {
// create a PHP template as the renderer for the response
$Response->setRenderer(new Zps_Template_Php($AppDir . '/templates/main.phtml'));
}
$Response->sendResponse();
I just used a template, but you could create a whole Main View class with some smarts in it if you wanted to.
The rest of the code is the same with hierarchical rendering of views. It uses the bootstrap.php concept so it is a very simple foundation to experiment with building ZF applications -- even it you don't want to use the Zps View and Response stuff. The code is here:
http://ap3.sourceforge.net/zpsdemo03.zip
Posted: Wed May 09, 2007 3:09 am
by Maugrim_The_Reaper
Well I got such an exciting response from my last post that I thought I would ... just keep going.
My limited forum time was going elsewhere over the weekend

. I'll try to go over it later - I think the hangover has run its course from yesterday...
Posted: Wed May 09, 2007 4:45 pm
by Christopher
Sounds like fun. The additions I have done are really pretty simple:
- Add are "renderer" object to Views and the Response so you can assign any object with a render() method as the renderer.
- Change the render methods so that if a renderer is present it assign all properties of the View/Response to the renderer object and then calls $this->_renderer->render();
- Add a hasRenderer() method to the Response so the bootstrap can Lazy Load a default main/outer View if none specified.
- I pulled out the template code from the View and made an external PHP template class.
- The Views and Actions find their current directory from reflection in a getPath() method so you don't have to mess with passing paths around or calculating them.
I want to add the caveat that the code in the example is very minimal. I only added a few core methods to show how easy it is to have hierarchical Views that can assemble any combination strings, template objects or View objects. For example, I have not added helper methods to simplify loading Models and Views -- I do it directly in the example. Direct may be simpler and more flexible, but it would be pretty easy to add helper methods that could use defaults that the ZF uses.
Likewise I did not add the ability to set headers, scripts or styles in a sub-View and have it trickle up to the Response. That would a nice thing to add and very easy to implement. Nor did not deal what happens when there is not a renderer assigned. It just sort of implodes the properties into a string.
So there is plenty that could be added to make simplify coding if this hierarchical idea is of interest -- as opposed to the prepend, insert, append style that the ZF currently implements.
Posted: Wed May 23, 2007 3:58 pm
by Christopher
I notice that Matthew at Zend is groping is way toward something just like I proposed with his viewRenderer(). I feel strongly that hierarchical views are the way to go, and proxying a plugable render() method is the way to go with hierarchical views. It simplifies the code and increases flexiblity at the same time (except when Zend does it

)
Hey Maugrim, did you ever get a chance to look at my code? I left it in a very primitive state as I was hoping for input before going forward. I was hoping you would give me some direction on the things I didn't implement, such as:
- how to make building sequentially with just strings/includes really simple and clean
- loading view, model and helper classes,
- getting at app, module and current dir paths
- where to have exceptions
- etc.
Posted: Wed May 23, 2007 4:37 pm
by Maugrim_The_Reaper
Just got caught up again between RL and side projects - I haven't abandoned the thread of anything

. Will review as soon as I can get enough free hours together (likely Friday). Noticed just now the ViewRenderer is going to be enabled by default.
Also I got around to blogging on Layouts which solve a slightly different problem than just hierarchical Views. That's still on the "extend Zend" front. Committed a little damage control since I neglected to unit test the posted snippet

.
Posted: Wed May 23, 2007 6:54 pm
by alex.barylski
arborint wrote:I notice that Matthew at Zend is groping is way toward something just like I proposed with his viewRenderer().
I feel strongly that hierarchical views are the way to go, and proxying a plugable render() method is the way to go with hierarchical views. It simplifies the code and increases flexiblity at the same time (except when Zend does it

)
Hey Maugrim, did you ever get a chance to look at my code? I left it in a very primitive state as I was hoping for input before going forward. I was hoping you would give me some direction on the things I didn't implement, such as:
- how to make building sequentially with just strings/includes really simple and clean
- loading view, model and helper classes,
- getting at app, module and current dir paths
- where to have exceptions
- etc.
This is something I've been considering for a while as well. Not sure if we mean the same thing though, without requring me to dig through 20 pages of demo code, etc, can you summarize what you mean exactly by hierarchial views?
Posted: Wed May 23, 2007 7:30 pm
by John Cartwright
Simply put, it is the idea of attaching views to parts of others views. For instance, you would have a master template (header, footer, etc), then another view attached to the content section all neatly tucked away in the response object.
Posted: Thu May 24, 2007 12:43 am
by Christopher
Hockey wrote:without requring me to dig through 20 pages of demo code
There is actually very little code if you make the trivial effort to look at the files mentioned in my posts above. Most of the code in the "Zps" files I posted is just copied out of the Zend versions. It's mainly just the render() methods and proxy renderer that are additional. The demo code is a complete mini-app that renders a page, so you can pretty easily follow what is going on if you are familiar with the Zend framework and of the bootstrap code that was discussed previously in this thread. The hierarchy in the example is an outer PHP template for the page layout, an View object that renders a menu and the content text is just a string. The point being that you can build a tree by mixing and matching any objects that have a render method -- views or templates.
Posted: Fri May 25, 2007 11:12 am
by sike
just wading though the whole zend view dilema and starting to think of a complete replacement the longer i stare at their code.
they made lots of questionable design decisions (at least in my eyes) which force me to code in a way i feel uncomfortable with.
so my question is if i could get rid of Zend_View_Interface altogether? is it tied to other classes or would it be enough to override initView() and render() in Zend_Controller_Action ?
aborint: studying your code at the moment. will post some thoughts when i get home.
chris
Posted: Fri May 25, 2007 2:14 pm
by Christopher
sike wrote:just wading though the whole zend view dilema and starting to think of a complete replacement the longer i stare at their code.
they made lots of questionable design decisions (at least in my eyes) which force me to code in a way i feel uncomfortable with.
Agreed.
sike wrote:so my question is if i could get rid of Zend_View_Interface altogether? is it tied to other classes or would it be enough to override initView() and render() in Zend_Controller_Action ?
The Zend_View is actually pretty easy to replace because there are no important dependencies. If you look at the code I posted I just copied the minimal parts of Zend_View that I thought might be appropriate. More could be cut or added.
Zend_Controller_Action is a very different story. They chose (over my protestations) to have the dependency be to Zend_Controller_Action_Abstract instead of a minimal interface which would have been appropriate. It was the easy way out and unfortunate. I will probably end up chucking out their Front Controller and Router as well for something much lighter, just because of that dependency.
sike wrote:aborint: studying your code at the moment. will post some thoughts when i get home.
It is very rough code, mostly from the conversation that Maugrim and I were having. If you don't like something about it, I probably don't either.

Hopefully can get a sense of the direction and have some ideas which way you think things should go.
The goal was really to:
- show the proxy renderers to make templates and views mix-and-match based on the complexity of what you need to render,
- show that you could simply build a view hierarchy with template style component/composite,
- and to have lazy rendering where you register the objects but the work does not get done the response runs so you can redirect/forward with no rendering overhead.
- implement a standard template lib interface so we could implement things like a simple Zps_Template_Smarty wrapper class that extends Smarty -- and you just use the original library as normally used. This is opposed to the round about way it is done now in ZF.
Posted: Fri May 25, 2007 2:24 pm
by sike
my current thinking is to resort to a separate composite template class and use the view only for wiring the thing (speak pathes and stuff).
here are the interfaces i am playing with right now. seems like we came to a similar decision (your Zps_Template_Php) with the difference that i don't think the view has to be a composite.
Code: Select all
interface Suv_Template_Interface
{
/**
* @return bool
*/
public function set($key, $value);
/**
* @return mixed
*/
public function get($key);
/**
* @return bool
*/
public function has($key);
/**
* @return bool
*/
public function import($item);
/**
* @return bool
*/
public function setTemplate($filename);
/**
* @return string
*/
public function render();
}
/**
* @category Suv
* @package Template.Composite
*/
interface Suv_Template_Composite_Interface extends Suv_Template_Interface
{
/**
* @return Suv_Template_Interface|false
*/
public function &getRoot();
/**
* @return Suv_Template_Interface|false
*/
public function &getParent();
/**
* @return bool
*/
public function append($element, $slot = 'default');
/**
* @return bool
*/
public function prepend($element, $slot = 'default');
/**
* @return string
*/
public function renderSlot($slot = 'default');
}
scanning the view helper code right now. my first impression is that i would like to rebuild them too

but have to read some more.
chris
Posted: Fri May 25, 2007 2:40 pm
by Christopher
sike wrote:my current thinking is to resort to a separate composite template class and use the view only for wiring the thing (speak pathes and stuff).
here are the interfaces i am playing with right now. seems like we came to a similar decision (your Zps_Template_Php) with the difference that i don't think the view has to be a composite.
Yes, very similar. My point of making the View composite also was that it then does not matter what a node in the tree is. It can be a View or just a simple Template -- depending on need. That mix-and-match is important to me because I often have a mix of complex and simple display components. I also usually implement an outer View that is lazy loaded after the Action runs (and therefore the default view is replaceable by the Action). Plus, Templates are already essentially composite.
I think if it like with database. Sometimes you just need a ResultSet, other times you need an ActiveRecord with Business Logic. But if the basic interface is the same you can easily mix complexity levels.
Posted: Fri May 25, 2007 3:05 pm
by sike
arborint wrote:sike wrote:my current thinking is to resort to a separate composite template class and use the view only for wiring the thing (speak pathes and stuff).
here are the interfaces i am playing with right now. seems like we came to a similar decision (your Zps_Template_Php) with the difference that i don't think the view has to be a composite.
Yes, very similar. My point of making the View composite also was that it then does not matter what a node in the tree is. It can be a View or just a simple Template -- depending on need. That mix-and-match is important to me because I often have a mix of complex and simple display components. I also usually implement an outer View that is lazy loaded after the Action runs (and therefore the default view is replaceable by the Action). Plus, Templates are already essentially composite.
I think if it like with database. Sometimes you just need a ResultSet, other times you need an ActiveRecord with Business Logic. But if the basic interface is the same you can easily mix complexity levels.
yeah i see what you mean. the thing is that i don't distinguish too much between views and templates. on most pages i use a component based approach - each component inherits from template (i do this to avoid juggling template vars around) and is plugged into a page object (which i see as the "view"). works out ok this far. one thing that made me think in the past was the blurry line between view and controller when working with components.
Code: Select all
/**
* @return void
*/
protected function buildContent()
{
$data = $this->getData();
$Headline = new WebsiteHeadlinePartial($this->getApplication());
$Headline['Headline'] = $data->get('Headline');
$Headline['SubHeadline'] = $data->get('SubHeadline');
$this->addElement($Headline);
$Images = new WebsiteDistributorLevel1IPartial($this->getApplication());
$Images['Images'] = $data->getImages();
$this->addElement($Images);
$Teasers = new WebsiteTeaserModulesPartial($this->getApplication());
$Teasers['Teasers'] = $data->getTeasers();
$this->addElement($Teasers);
}
what's your differentiation between a view and a template?
chris
Jcart | Please use tags instead [/color]