Getting data from view file itself

[eluser]mattalexx[/eluser]
I need some MVC advice: I have a model called Text_Image_model that deals with overlaying text on an image using ImageMagick, caching an image files then delivering the cache information.

I have a view file called header.php that needs to access this data every time it loads. The data that this view needs isn't specific to any controller. Would it be "MVC complaint" to stick a model call in my view (It seems like this logic is layout-specific anyway and wouldn't exactly be out of place, but I also know that I should keep my views relatively stupid)? If not, what would be the best way to accomplish this?

[eluser]sikkle[/eluser]
To keep your view clear, create a helper, and call the helper in your view.

Keep in mind your helper can access any model and whatever it need in one unique method.

Other way will be the use of Modular Extension (HMVC) from ignited code section of this forum and wiki.

Good luck !

[eluser]mattalexx[/eluser]
Thanks, sikkle.

[eluser]charlie spider[/eluser]

I have a model called Text_Image_model that deals with overlaying text on an image using ImageMagick, caching an image files then delivering the cache information.

it sounds to me like your model is doing more than it should.

Why don't you put all of that logic into a controller and then you can call whichever controller function you need from either another controller, or even from your view.

if i have a site that has uploaded image files, i md5 all of the filenames and store them in the db, then when i need to display an image anywhere, i use a separate controller to pull the md5 filename from the db (through a model call), then send the headers and file contents to the browser.

much like your situation, this controller isn't specific to any other controller, plus i can reference it's functions from anywhere, including views, without having extra code where it doesn't need to be. as well, when i start work on my next project that needs image uploads, i just reuse that controller.

keep your model for calls to and from the database and nothing more

[eluser]mattalexx[/eluser]
[quote author="charlie spider" date="1214781007"]keep your model for calls to and from the database and nothing more[/quote]
Huh. I thought that models were for gathering data in general, not just from the database. Interesting.

[eluser]xwero[/eluser]
Models are dummy classes, only by setting the third parameter in the load->model call it becomes tied in with the database. You can use models for any data related functionality. For instance i use them to put the validation in thus separating it from the data fetching/manipulating model and the controller.

To get back on topic, you could autoload a model with method(s) that are needed for all pages. Change the codeigniter/CodeIgniter.php file to add the methods to the views using the load->get_vars method. How you can change it you can read here.

[eluser]charlie spider[/eluser]
i guess i tend to take a more strict approach to the MVC idea which i believe can help you in the long run.

from project to project, your database tables and therefore any code accessing them, are pretty much guaranteed to change, but the methods for manipulating data may not. if you keep your model to strictly be nothing more than the interaction between your database and the rest of your code, and keep all of your business logic in your controllers ( or helpers, or libraries ), then it is easier to reuse code for another project.

Using your example of overlaying text on an image using ImageMagick, you could write a controller ( or helper, or library ) that receives any variables and data it requires, does all of the work, and spits out the finished product, without having it chained to any particular database or view ( or controller ). When you finish this project and move onto the next, Hey !!! you can reuse that module of code with no extra work.

Separating your code into reusable chunks will save you time and money in the long run.

Entrenching your business logic in with other project (database) specific code will keep it forever entangled with that particular project.

so i guess i second sikkle.

create a helper

but i would call it from your controller if possible

[eluser]xwero[/eluser]
It's been a look time rule of mine that libraries should not contain any framework code. Making a library with framework code makes them less reusable by default. This rules out a library.

A helper is framework bound because some use them and others don't. But i don't like helper functions to connect to a database because then the line between models and helpers fades. You could create a model that gets called in the helper but then you need to load two files instead of one.

So you end up creating a reusable model, because it's framework bound and connects to the data storage.

The dark side of a markup returning method/function is that the markup can change, which makes you add markup changing parameters to the method/function. This isn't good because then designers have no full control of all markup as some of it is hidden in php code. To give designers full control of the markup you should use a view file.

Now the practice, the model method would look like this

Code:

function overlay($table,$field,$where,$view)
{
    $this->db->select($field); // split up sql building methods for php4 compatibility
    $query = $this->db->get_where($table,$where);
    $row = $this->db->row();
    $data['overlay'] = $row->$field;
    return $this->load->view($view,$data,TRUE);
}

The helper code would look like this

Code:

function overlay($table,$field,$where,$view)
{
    $CI = & get_instance();
    $CI->load->model('overlaymodel','',TRUE);
    $data['overlay'] = $CI->overlaymodel->get_text($table,$field,$where);
    return $CI->load->view($view,$data,TRUE);
}

Lets say at some point the query needs to be changed but the original query still need to work too. In the model you can just add another method as for the helper function you have to create another model method and another helper function.

To summarize, if you create reusable methods/functions you should make the code as lean as possible. If it's a one time shot do what you find the easiest.