Welcome Guest, Not a member yet? Register   Sign In
Where to store static array ?
#1

Hello ! 

I have some static arrays i actually store in MY_controller cause i need them all the time. 
But more i progress in my last project and more i have big arrays to store (for example : countries array).
So i wonder if it's really the best way to do that.

What's the best practice to store & call them ? 

thanks a lot !!!
Reply
#2

(This post was last modified: 04-26-2017, 11:54 AM by PaulD.)

You could put them in a config file and use them as required. Personally I would put them in a countries model and call them as required.

For instance, create a file called Countries_model.php in you application/models directory:
PHP Code:
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class 
Countries_model extends CI_Model {
    
    public 
$countries_list = array(
        
'England',
        
'America',
        
'France',
        
'Germany',
    );

    public function 
get_countries() { 
        
// return full list of countries
        
return $countries_list;
    }
    


Then in any controller:
PHP Code:
// load model
$this->load->model('countries_model');

// get countries list
$countries $this->countries_model->get_countries(); 

If you ever have to update your countries list you now only ever have to update it in one place. Your controllers remain clean and readable and models are easy to test too.

Or instead of a model you can do a similar thing in a library, or create your own helper. The docs are very good on all this.

Hope that helps,

Best wishes,

Paul.

PS Models are very, very cool and powerful and good usage makes your code super easy to modify and update. I often have more models than controllers :-)
Reply
#3

I would start with a library, personally. Then, if the app progresses to the point where those values need to be editable by admin, etc. you can simply modify the library to grab the values from the db through a model and return in the same format that you've been providing. Helps future proof it a bit.
Reply
#4

(04-26-2017, 12:00 PM)kilishan Wrote: I would start with a library, personally. Then, if the app progresses to the point where those values need to be editable by admin, etc. you can simply modify the library to grab the values from the db through a model and return in the same format that you've been providing. Helps future proof it a bit.

I used to use libraries extensively, but now I tend to use models rather than libraries (unless it involves 3rd party libraries, in which case I would use a CI library to integrate it).

When you say 'future proof' it, is that in reference to CI4 (that I have not used or tried properly at all yet)?

Is there any difference from a technical standpoint? For instance, does the use of libraries generally mean a lower memory usage? I had always thought (probably incorrectly) that creating a new CI object in the library was more demanding than a model, in which I can just load helpers, libraries etc as needed as if in a controller, without the additional references to CI in $this->CI->db->get() for instance.

Here I am probably revealing a real lack of true understanding of how PHP really works, but Models are just so easy to use. I did note you said 'personally', so perhaps there is no difference but is a nod towards the whole 'namespacing' thing. (Which is an entire topic I am really looking forward to learning more about when CI4 launches. I fully intend to use CI4 only for all future projects and sites when it is released, but at the moment namespacing still looks like voodoo to me).

Thanks and Best wishes,

Paul.
Reply
#5

thanks a lot for your fast replies !
I will give a try for both solution and see the one i feel the most useful !

thanks again !
Reply
#6

(04-26-2017, 12:36 PM)PaulD Wrote: I used to use libraries extensively, but now I tend to use models rather than libraries (unless it involves 3rd party libraries, in which case I would use a CI library to integrate it).

When you say 'future proof' it, is that in reference to CI4 (that I have not used or tried properly at all yet)?

Not really. I just meant future proof it against whatever changes your client or the project scope might throw at you. Here's how I think of it:

First, a "library" in CI is simply any PHP class that is not a Controller, Model, or driver. That's it, really. So, they can be whatever you want them to be. The framework (in all versions prior to CI4) just use that to provide a simple method to load and instantiate the class.

Let's say the project scope initially states that we need to have 10 different employee titles that users should be able to select from. There's nothing in the scope about the admins being able to edit those. So, it would be tempting to hard-code it into the HTML select. Instead, you could use a library as a simple class to return an array of the titles. That seems silly at this point, but here's where the future proofing comes in. You're down to the last couple of weeks of development time and the client requests the ability to edit those in the admin. You would already have the nice library that can be used to display the existing fields, but no way to edit it.

At this point you have 2 choices: either move it all to a model to return it all, or (and this is my preferred way) still use the library, but get the values through the model, and format them to match what you were providing before. I know, I know - now you have 2 classes to use to get a simple list of items. And, in this example it might be overkill. But it makes it simple to change the method of persistence later on. Maybe they want to move to Mongo - ditch the existing model and use some custom MongoDB model. Do they want to grab items from an API instead? Then ditch the model, and use a custom class to retrieve the items from the API instead (and caching the values!). Nothing else in the app has to change, since they're all calling the library itself.

(04-26-2017, 12:36 PM)PaulD Wrote: Is there any difference from a technical standpoint? For instance, does the use of libraries generally mean a lower memory usage? I had always thought (probably incorrectly) that creating a new CI object in the library was more demanding than a model, in which I can just load helpers, libraries etc as needed as if in a controller, without the additional references to CI in $this->CI->db->get() for instance.

There's very little difference in overhead between loading a model and loading a library. If you look at the Model class you'll see it's an almost empty class that provides access to the CI object using get_instance. So, in that respect the cost is identical. If anything, a model is slightly heavier just because it might try to auto-start the db connection.

(04-26-2017, 12:36 PM)PaulD Wrote: Here I am probably revealing a real lack of true understanding of how PHP really works, but Models are just so easy to use. I did note you said 'personally', so perhaps there is no difference but is a nod towards the whole 'namespacing' thing. (Which is an entire topic I am really looking forward to learning more about when CI4 launches. I fully intend to use CI4 only for all future projects and sites when it is released, but at the moment namespacing still looks like voodoo to me).

Namespacing is really pretty simple once you get started with it. Combined with some form of autoloader, at its most simple, it just provides a way to map the class to a location on the drive. It also makes the possibility of class name collisions much more difficult.
Reply
#7

(04-26-2017, 01:21 PM)kilishan Wrote:
(04-26-2017, 12:36 PM)PaulD Wrote: I used to use libraries extensively, but now I tend to use models rather than libraries (unless it involves 3rd party libraries, in which case I would use a CI library to integrate it).

When you say 'future proof' it, is that in reference to CI4 (that I have not used or tried properly at all yet)?

Not really. I just meant future proof it against whatever changes your client or the project scope might throw at you. Here's how I think of it:

First, a "library" in CI is simply any PHP class that is not a Controller, Model, or driver. That's it, really. So, they can be whatever you want them to be. The framework (in all versions prior to CI4) just use that to provide a simple method to load and instantiate the class.

Let's say the project scope initially states that we need to have 10 different employee titles that users should be able to select from. There's nothing in the scope about the admins being able to edit those. So, it would be tempting to hard-code it into the HTML select. Instead, you could use a library as a simple class to return an array of the titles. That seems silly at this point, but here's where the future proofing comes in. You're down to the last couple of weeks of development time and the client requests the ability to edit those in the admin. You would already have the nice library that can be used to display the existing fields, but no way to edit it.

At this point you have 2 choices: either move it all to a model to return it all, or (and this is my preferred way) still use the library, but get the values through the model, and format them to match what you were providing before. I know, I know - now you have 2 classes to use to get a simple list of items. And, in this example it might be overkill. But it makes it simple to change the method of persistence later on. Maybe they want to move to Mongo - ditch the existing model and use some custom MongoDB model. Do they want to grab items from an API instead? Then ditch the model, and use a custom class to retrieve the items from the API instead (and caching the values!). Nothing else in the app has to change, since they're all calling the library itself.

Yes i experienced this kind of "last minute changes" pretty often with clients and your solution is definitely the most flexible ! 
thanks a lot !
Reply
#8

If you will be implementing solid mvc even static data should come in the model. But it would be nicer if you can also call it statically so that you dont have to instantiate the class just to get the static data.
God Bless CI Contributors Smile
Reply




Theme © iAndrew 2016 - Forum software by © MyBB