[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