Welcome Guest, Not a member yet? Register   Sign In
Poll: Should something like this view_layout method be included?
You do not have permission to vote in this poll.
3 30.00%
6 60.00%
Maybe - see comments
1 10.00%
Total 10 vote(s) 100%
* You voted for this item. [Show Results]

View Layouts - Input Desired

Currently, in CI4 we can render out a view with the view() method:

echo view('welcome_message', $data);

I was toying around with a very simple idea tonight, and wanted to know if people thought it was worth including or not: view layouts. This provides a very simple way to wrap one or more views within a common layout file, making a very bare bones theme-able system that works like this:

1. A common file exists at Views/Theme/Index.php. This would include common headers, footers, maybe a sidebar, etc.
2. We call it something like this:

echo view_layout('Theme/index', $layout_data, function() use ($data) {
   echo view('welcome_message', $data);

3. The output of the closure is captured, and placed into the $layout_data variable with the name $layout_content, so the layout would need to echo that out at where it wants it to show up.

<?= $layout_content ?>

Is this useful? Too simplistic to be worth anything, too complex to use on every method? Curious what everyone thinks.

For those that want to play around with the concept, you can add this small method to the Common.php file:

function view_layout(string $layout, array $data = [], Closure $closure)
// Catch any views rendered in the closure
$buffer = ob_get_clean();

// Add them to the data
$data['layout_content'] = $buffer;

return view($layout, $data);

(This post was last modified: 07-11-2016, 06:14 AM by PaulD. Edit Reason: Added comment )


I think it is ok, but too simple to be of any real use. I have done similar on some sites, but it always becomes more of a pain than a help.

I think it would either lead to complaints of 'Why can't the CI theme layouts do this?' or 'why is the CI theme system so backward' (meaning uncomplex or simplistic).

If there was a vote, I would vote no to this option being added. [EDIT Just noticed there is a vote - sorry]

However, I do think a good argument can be made to have a current 3rd party templating system being shipped as a default, as long as it was optional to use or not. Perhaps as a library. So if someone wanted to use, say, twig, and not the default (assuming twig was not chosen), they are where they are today, free to use whatever they want. But for those newbies and for speed of implementation (and advocates of chosen system), it would be already set up and configured and ready to run out of the box.

I really would be quite open to whatever system to be included, as I am sure the CI team would come to good decision. Being only loosely coupled as a library, it could easily be changed in the future.

However, having said all that, I am quite happy without one. But I think it would aid the CI takeup for newcomers if a system was chosen that was already well documented, tried and tested, popular, supported, stable, sophisticated, and available out of the box.

Best wishes,


i don't know isn't it better to use an output manager or something like that ?
That whole "echo" thing looks a bit weird i think.

Phil Sturgeon did a pretty good job with his Template Library imho.
Did you ever consider an option like this?

I think if a Framework doesn't provide such a functionality, i'm pretty muched get forced to develop it on my own

PHP Code:
    public function overview()

$arrNavigationData['navigation'] = Navigation_Model::getNavigation();


The above example should illustrate what i mean.

(This post was last modified: 07-11-2016, 05:49 PM by prezire.)

I'm not sure if this would help but in CI3, I usually implement a helper. Something like:

PHP Code:
function render($partial)
 view('partials/' $partial);

And in either controller or view, I call it like:
PHP Code:
public function index()
//Some stuff...
vars(['users' => $users]);

Long live CodeIgniter!

I so something similar but a bit more complex to allow blocking, but in essence these are all simplistic versions of very well thought out and developed/matured template systems that others have already done. (Personally I still use my own because I can alter it easily for each sites requirements).

My point is that for a beginner, having a well documented, sophisticated, out of the box solution might be beneficial and probably quite attractive to people considering CI for the first time. I recall struggling with views, when simple views were not enough, or became cumbersome, and struggling to implement some of the existing frameworks.

The only negatives I can see is the backlash from people assuming you have to use an out of the box solution that they do not like, or the fact that questions might arise that have nothing to do with CI but about whatever the chosen templating system is. I just don't think that time spent developing anything in-house to do what has already been done very powerfully (and in all honesty is a bit of a side avenue for a framework to go down) is the best use of the core teams time.

On a side note, it would be quite cool as well to have an out of the box authentication and authorization system, even though the same arguments against can be raised, I strongly believe that an out of the box optional implementation of both authentication and templating would make CI far more attractive to newcomers. There are already great authentication libraries for CI, and templating libraries, I believe it would be good for CI if the CI team spent a minimal amount of time choosing, polishing and including some of those as part of the default download.

Just to be clear, as much as control freaks like me like to do everything myself, it seems that these two things are two things most people need and expect from their framework. Personally I see them as tools to implement on a framework, much as I do the helpers in general, and not really part of a pure framework, but I am sure CI would increase it's audience if these were included by default.

Just my two pennies on the subject, and as always, humbly yours,


I voted yes, but I meant to vote no and didn't see an option to change my vote Sad
Codeigniter is simply one of the tools you need to learn to be a successful developer. Always add more tools to your coding arsenal!

It's cool. I've seen enough votes, and have looked back on it and don't think it fits, either. So this will not be included...

I think that CI 4 needs some kind of layouting..
At CI 3 I usually do something as ..
At MY_Loader I overwrite the view with something simple as: 

PHP Code:
public $template NULL;
public function 
view($view$vars = array(), $return FALSE)
    if(empty($this->template)) {
        return $this->_ci_load(array('_ci_view' => $view'_ci_vars' => $this->_ci_object_to_array($vars), '_ci_return' => $return));
['_view_content_'] = $this->_ci_load(array('_ci_view' => $view'_ci_vars' => $this->_ci_object_to_array($vars), '_ci_return' => TRUE));
    return $this->_ci_load(array('_ci_view' => $this->template'_ci_vars' => $this->_ci_object_to_array($vars), '_ci_return' => $return));

And after that just at the layout I output the "_view_content_" ..

I think that for CI4 such regular "hacks" should be prevented.
When there is some kind of problem often mentioned it will be good if there is build in solution.
Best VPS Hosting : Digital Ocean

I also have used Phil Sturgeon's template library in a variety of applications and would love to see something very similar integrated into CI.

As soon as you put something into the framework - you have to support it which include the security concerns. Some people have said Codeigniter should support their favorite template library. "Hey everyone is using Whiz 3 template library" - but then when Whiz 4 comes out - then those same people will be screaming that Codeigniter needs to support Whiz 4. And then - even if you are able to do the upgrade to the framework - you are stuck with doing forks of the framework because of all the users of Whiz 3 who can't upgrade because of breaking changes. Then instead of spending the very limited time in improving the framework - you are spending all the time supporting multiple versions of someone else's code that you have no control over.

This is why long time codeigniter users keep insisting - no 3rd party dependencies. And nothing that smells of CMS. That means a more stripped down framework with less features out of the box - but in the long term its proven to be much more stable and maintainable and super fast.

Theme © iAndrew 2016 - Forum software by © MyBB