Load file with variables

[eluser]Yorick Peterse[/eluser]
While rebuilding my guestbook from scratch I figured out I wanted to enable users to use custom templates. The basic idea is very simple, load a main template file from the templates directory and pass some variables to it. The problem was that loading a view didn't work, as it's bound to a views directory. Loading a file seemed to work, but again there was a problem. In this case loading a view doesn't enable users to pass variables with it.

Because I don't need a complete template library, nor doe I need a custom one, I figured out it would be best to modify the Loader library. Making a seperate library for just 3 lines of code isn't something I consider worth doing.

I made a slight modification to the function for loading files, it works as a charm :

Libraries/Loader.php

Code:

function file($path,$vars = array(), $return = FALSE)
{
return $this->_ci_load(array('_ci_path' => $path, '_ci_vars' => $this->_ci_object_to_array($vars),'_ci_return' => $return));
}

And that's it, you can now load files with variables, just as you can load views with variables. I still wonder why this isn't enabled by default.

[eluser]dcheslow[/eluser]
Excellent! I have an another application for this concept... email templates. Many of my websites generate lots of email - registration confirmations, event notices to admins, double-blind email systems, etc. I managed to get views to work in my email library, but they aren't really views in the strict sense (for example, I sometimes want administrators to be able to edit the email templates) so I'd prefer to keep them separate from views so they can have different permissions and to logically separate them. This snippet should do the trick (I might change 'file' to 'template' though). I'm going to give this a try tonight.

I'd vote YES for inclusion in a future version of CI.

=dave=

[eluser]Yorick Peterse[/eluser]
[quote author="dcheslow" date="1244597348"]Excellent! I have an another application for this concept... email templates. Many of my websites generate lots of email - registration confirmations, event notices to admins, double-blind email systems, etc. I managed to get views to work in my email library, but they aren't really views in the strict sense (for example, I sometimes want administrators to be able to edit the email templates) so I'd prefer to keep them separate from views so they can have different permissions and to logically separate them. This snippet should do the trick (I might change 'file' to 'template' though). I'm going to give this a try tonight.

I'd vote YES for inclusion in a future version of CI.

=dave=[/quote]

Yeah, I was quite surprised it wasn't in there by default

[eluser]xwero[/eluser]
A cause of bugs with this modification is that variables for view files could be overwritten because before the inclusion of the file the variable array gets merged with the array you added to the method. For Yorick's scenario there is no problem as it is a part of the output but if you combine dcheslow's scenario with Yorick's some strange things could happen.

You can change the view path if you are willing to alter the _ci_view_path class variable.

Code:

// catch value of class variable for resetting
$org_view_path = $this->load->_ci_view_path;
// set custom view path
$this->load->_ci_view_path = BASEPATH.'views/';
// output custom view
$this->load->view('template',$data);
// reset class variable as a precaution
$this->load->_ci_view_path = $org_view_path;

[eluser]dcheslow[/eluser]
Insert dave scratching head here.

If I understand you, xwero, _ci_load will merge $vars with the $vars passed into a view loaded later, possibly overwriting values?

For other reasons, that's unlikely to happen in my code. BUT your solution of changing the views path is another perfectly good option.

Thank you for it,

=dave=

[eluser]xwero[/eluser]
If you set view variables before you run the email templates there is a possibility the view variables could get overwritten. It's not a very likely situation but it's something to consider if you add the modification.

The best thing would be to have a possibility to either compartmentalize the variables or prevent the non view vars to merge. The first option will consume more memory but you could retrieve it later on in the page rendering process for other things. On the other hand how much will you need to retrieve the non view variables.