Accessing models from custom library

[eluser]stef25[/eluser]
In my controllers I've got a bunch of functions that perform common tasks. These aren't methods that correspond to a URL segment. I moved these functions to a custom library to make my controllers less crowded.

These functions commonly call functions that are located in my Models. I'm getting errors now that say "Undefined property: MyLib::$Client_model".

First, is a custom Library a good place to put these functions? Second, How can I make my models available in this Library?

Thanks,
Stef

[eluser]jedd[/eluser]
Give examples of the kinds of things that these functions do.

You may be better moving the functionality into models - either extant ones, or creating new models specific to the intent of the function(s).

[eluser]stef25[/eluser]
Various things: flatten a multidimensional array, checking if a user has a certain role, etc. Basically they are functionalities that were originally in a Client method but could be put in their own function so the original method has less code and so easier to follow. Some of these functions are shared by several Client methods. Alot are custom validation functions.

My models contain only queries (no processing) so I'm reluctant to put them there.

[eluser]jedd[/eluser]
[quote author="stef25" date="1255209727"]
Various things: flatten a multidimensional array,
[/quote]

Doesn't need database access, so that's an easy one.

... checking if a user has a certain role,

Possibly needs DB access, but might be better handled by sticking that information into the session at authorisation time. If you're committed to doing DB lookups for this, every time, then do it in a model.

Basically they are functionalities that were originally in a Client method but could be put in their own function so the original method has less code and so easier to follow. Some of these functions are shared by several Client methods. Alot are custom validation functions.

By Client do you mean Controller?

While I understand the urge to tidy things, relocating blocks of code into other files doesn't seem tidier to my mind - any more than sweeping the floor and leaving the resultant mess in the corner.

My models contain only queries (no processing) so I'm reluctant to put them there.

Your models can manipulate data to suit what you need back in your controller / view, and still be 'in spec' for MVC.

[eluser]Colin Williams[/eluser]
Right. Models are the very place you want to do data processing and manipulation. Models should use Libraries to help, not quite the other way around

[eluser]stef25[/eluser]
Thanks for the replies.

Yes, Client = Controller. My controller is called "Client", hence the mistake .

The reason I want to tidy things up is that client.php has about 2000 lines of code (and I have several files like this) and I find myself getting lost in the code always scrolling up and down. Yes I have an outline view in my IDE, I can put bookmarks etc. I just find it easier to flip between files instead of 1000 lines up or down. I could have set things up differently (and will in the future), I just didn't realise the file would get this big and don't want to change all my url's now.

So ... could anyone suggest where these functions should go: helper, library? I'm fine with a library file but would just like to know how to resolve the error in my OP.

Thanks

[eluser]jedd[/eluser]
I'm not sure if this helps - as I'm not entirely sure what your intent is, outside of reducing the line count in one of your controllers.

As an intermediary stage, you could move common functionality into private functions within the controller. I tend to shuffle all my private functions down to the bottom of my controllers, nicely sectioned off and labelled of course. This works for me because they tend to be verbose - often large arrays being set up, or rearrangements of arrays - while at the same time not requiring much subsequent re-visiting. Once you pull stuff out into functions, it becomes easier to work out whether those functions are better relocated to a helper, a library, or back into one of your models. In the short term it definitely reduces the size of the part of the file that you tend to be active in.

If you're doing this purely because your IDE doesn't lend itself to navigating a large file (though I concede 2,000 lines is pretty fat for a controller - what's the code:comment ratio in there anyway?) then I'd suggest this isn't the best rationale for doing a re-design - it'd be easier just to get a better IDE.

If the problem of changing some URL's is too daunting, then your design may have other problems (changing URL's should be fairly straightforward, particularly if you're considering this from a 'split the controller into two or three smaller controllers' perspective).

If you really want the answer to your OP, and you have already tried reading the CI Manual and doing what it suggests on the [url="http://ellislab.com/codeigniter/user-guide/general/creating_libraries.html"]Creating Libraries[/url] page - viz. the ol' $CI =& get_instance(); trick - and found that it doesn't work, then that's a whole new problem.

So -- did it work?

[eluser]stef25[/eluser]
Thanks for your comments!

As an intermediary stage, you could move common functionality into private functions within the controller

That's exactly what my current setup is with the same functionalities as yours (array stuff): private functions all the way at the bottom of my file. I would just like them in a separate file for easier navigation.

My IDE is Aptana which with an Outline in the sidebar and can just jump to functions from there. I'm not always sure what the function is I'm looking for though, so that's why I prefer to have a file with say 500 lines I can quickly scroll through.

I could change the URL's. Right now i have example.com/client/product/update. Client is the file with 2000 lines and I would have been better of just having a controller called Product (and the same for factory, user and all the other 2nd segments). Problem is I don't really have the courage to start changing URL's with deadlines and all, even though it probably would be quite painless.

So—did it work?

No, but I'll give another shot and get back to you. Yes I did check the manual and tried $CI =& get_instance();

[eluser]jedd[/eluser]
[quote author="stef25" date="1255284647"]
I'm not always sure what the function is I'm looking for though, so that's why I prefer to have a file with say 500 lines I can quickly scroll through.
[/quote]

PHPdocumentor or Doxygen might be worth having a look at, then - makes life easier while developing, as well as being an easy way of providing decent maintenance docs, but might not be as fast as scanning through a controller.

I could change the URL's. Right now i have example.com/client/product/update. Client is the file with 2000 lines and I would have been better of just having a controller called Product (and the same for factory, user and all the other 2nd segments). Problem is I don't really have the courage to start changing URL's with deadlines and all, even though it probably would be quite painless.

$ git branch controller_split
... then pick one component to split up, relocate your views into a new sub-directory that matches the new controller .. maybe an hour or two to determine how much work would be involved in doing a few. You're right, though, that deadline-pending moments are not the best to experiment.

No, but I'll give another shot and get back to you. Yes I did check the manual and tried $CI =& get_instance();

Oh, do you remember what kind of errors you were getting? Most of the time it's people subsequently using $this-> rather than $CI-> , or creating something weird like $this->CI and then getting confused when they look at references in the CI manual.

[eluser]stef25[/eluser]
The error I ended up with was “Undefined property: MyLib::$Client_model” but I'm not sure what code I was using to get this. Will check again since I'm pretty sure I was not using $CI->

I hadn't thought of using GIT to create a branch. Have yet to find out how to set that up on my MAMP localhost.