[Solar-talk] _layout_dir

Paul M. Jones pmjones at solarphp.com
Mon Jun 26 06:52:24 PDT 2006


Hi Jeff,

> Thanks for the new release its great! even though it breaks all my
> code :-) :-)

Yeah, sorry about that.  :-(  I try not to break stuff, but things are
more in flux than I thought they would be at this point.


> Just a quick question, you have removed the code in Page.php that used to
> add the _layout_dir to the template path array, namely
>
> $view->addTemplatePath($this->_layout_dir);
>
> There does not appear to be an equivalent bit of code in new _render()
> function in Page.php, is this design or dare I say flaw, or is there a
> reason for this.

The main reason was because new _layoutInstance() gives you very fine
programmatic control over how you want to build the Solar_View object used
for layout processing; in theory, you can override that and do something
like this:

protected _layoutInstance()
{
    $layout = parent::_layoutInstance();
    $layout->addTemplatePage('/path/to/other/layouts');
    return $layout;
}

However, if you think that this is not quite enough, I can very easily put
_layout_dir back in place.

Now that you say it, I should probably add them back in anyway; I can see
where you would want to allow end-users to add to the stack themselves
(for view paths, layout paths, and helper classes).  Look for it in a
followup release, perhaps 0.20.1.


> I see that the template path array by default contains
>
> Vendor/App/AppName/Layout/
> Vendor/App/Layout/
>
> So I can just move my layouts to Vendor/App/AppName/Layout/

This is the new recommended behaviour, which I am putting in the
change-notes narrative I'm working on.  (There's just *so much* to make
note of ...)

As always, thanks for your patience with all the changes and breaks; I
know I keep saying that "this is the last set of major changes" and I
believe it every time, but then I see other things that need attention. 
:-(


-- pmj



More information about the solar-talk mailing list