That has been a common request, among others, so I’ll probably get it into the next release.

Hi Collin,

Very nice library here, however I have 2 requests:
- I second m4rw3r in his request to be able to load views how he explained it
- Could you include the User guide as HTML into the Zip download like CI does it?

I’ve got a question.
From your user guide we can read:

Cascading Views

A core principle of the Template library is flexibility, so the write_view() method lets you suggest other View files to load if the defualt View file you passed in the first argument doesn’t exist. To suggest other View files for Template to use, pass them discretely, starting with the 5th argument:

$data['posts'] = $this->blog->get_recent(5);
$this->template->write_view('content', 'blog/front', $data, FALSE, 'blog/posts'); 

If this was a blog application, using this method lets us create a View file at views/blog/front.php to format blog posts distinctly when they appear on the front page, or opt-out and let our standard views/blog/posts.php handle the output. We could suggest more fallbacks if needed in the 6th, 7th, 8th arguments, and so on.

I am not sure I understood how to manage that interesting feature and after some tests I can’t get to something working. Can you post here a full example?

I’ll try to do it quick.

Here’s a view at application/views/basic.php:

And here’s a basic controller method:

The template just echoes the ‘content’ region:

So, when we fire up this controller method, since we have a basic.php view and not a fancy.php view, we see:

Name: John

Now, lets add a view at application/views/fancy.php

Now when we fire up the controller method, we should see:

Fancy Name: John

This type of cascade can be applied to a number of scenarios (opt-in template specialization, theme systems, etc)

Ok I got it now, thanks

We are trying to figure out how to load templates from a database instead of from the file system. Any ideas on how we could take a template and pass it in as a string to get parsed for data regions?

anyone, templates from db still getting parsed?

I guess my terminology was off a bit, what I meant was to add a region into a region from a db then have that 2nd one replaced, so a region within a region basically is what we wanna do.

A simple example of what we wanna do for now:

regions set
content
IMG_URL

so from a db we pull in the content which has multiple region of img_url to be replaced, it’s just that once we write the info to content, the region of img_url does not seem to exist even though it has been written to the template.
$IMG_URL = ‘someURL’;

Basically if we could do what write_view or parse_view do with a data string instead of a file.

On another note, I am wondering beyond calling in another parser, data appending or ‘Cascading Views’-view replacement based on $data array; what does this do that $this->load->view(‘master_template’, $data); does not already and $data array does not have to be defined in advance just exist on the template is a benefit to normal view calls?

For ad hoc miniature templates like that, newsun, str_replace or preg_replace functions will probably serve you well enough. I don’t think the overhead of running a parser or loading a faux-view is worth it.

On another note, I am wondering beyond calling in another parser, data appending or ‘Cascading Views’-view replacement based on $data array; what does this do that $this->load->view(’master_template’, $data); does not already and $data array does not have to be defined in advance just exist on the template is a benefit to normal view calls?

I tried reading that left to right and went South really fast. I think you were asking how is Template different than using vanilla views. What Template does essentially is manage that $data array in a wider context than the requested controller function, and even the controller itself.

We ended up doing a str_replace in this case as mentioned and will probably just add this method into the Template library on our end as it’s something that will get used often…I think it would be minimal overhead to have a method available as part of the install and it allows more flexibility
It could simply be: parse_string or write_string, or just a boolean trigger in the write or write_view methods

Here is basically what we added:

As to my other question, you basically answered it. What I think would beneficial would be a concise list of the additional features Template offers over built in view. I saw three main ones and that is what I listed.

Also what is the purpose of making regions manditory to be defined? Is it for speed based on the length of array which is looped through? To avoid having to search for a region in the file which might not exist, this gets done if there is a region defined anyhow, right?