Is there any way to create a function that works for all controllers in Codeigniter at init?
In Zend there is a application/Bootstrap.php, i need some solution like that.
You could extend the native CI_Controller class and create a MY_Controller class that all of your application's controllers would extend. Methods in the MY_Controller class would then be available to every controller that extends it. You could also put code in the MY_Controller constructor that would be executed each time a child controller was constructed.
I don't remember exactly how the Bootstrap file works in Zend, but if this sounds like a viable solution the Creating Core System Classes section of the documentation explains how to extend the native controller.
You can extend your New_controller to CI_Controller. In New_controller you can write common function which you want. For use about new extended controller you can see this link:
The subject of extending core controllers is discussed briefly in a few places in the manual - specifically in the Core Classes and Creating Libraries pages.
The intent of extending the core Controller is to provide methods and attributes to all your normal Controllers. There are other ways of providing this kind of pervasive functionality - including Hooks, Libraries and Helpers. You should familiarise yourself with the methods and benefits of those alternatives before assuming the following is the answer to your question.
Finally, it’s assumed that you have an application that does something - it doesn’t matter what, merely that you have an existing Controller that we can work with here.
-extend_the_CI_Controller
Related
If you read the documentation for CakePHP on creating PlugIns. It clearly states that the PluginAppModel and PluginAppController base classes extend from the AppModel and AppController classes. Which are implemented in the application using the plugin.
This seems very risky to me.
A plugin doesn't have control over what callbacks, components, helpers, etc.. that an application may have configured in those base classes.
Is there any problems in having your PluginAppModel/PluginAppController extend just the base classes from the CakePHP lib. Like Model and Controller?
Can someone explain the logic in why a plugin should extend these application specific classes?
Not matter what you do, exclude the App* classes from the inheritage chain or if you include them. There will be always points of possible failure because it is not predictable what people do in these classes.
The less likely scenario is that things break in your plugin if you extend the App* base classes than when you would not extend them.
Auth and Session Component are in the case of a Controller a good reason why you should extend the App* classes. Behaviours in an AppModel another one.
If your plugin depends on a certain - unchanged - state of a property of the Controller or Model class you did something wrong while building that plugin in my opinion. It is better to keep your plugin flexible by providing configuration options or check the states of inherited properties and attached components and behaviours.
If there is really a pitfall in your plugin - I still think it's done wrong then - you should document it so that it can be integrated properly by people who read the documentation.
I need to access some functions in multiple controllers in a CodeIgniter application. At the moments the functions are really basic and a few, For example:
generate_random_key() //just a random string
is_logged() //check if user is logged or not
logged_user_only() //if unlogged, redirect
unlogged_user_only() //if logged, redirect
As these functions are related to login, I can either put them in a helper file and place in Application/helpers/login_helper.php
OR
i can extend the CI_Controller, by creating MY_Controller.php and put it in Application/Core/MY_Controller.php
Both of the methods work, but I am wondering which one fits better for this kind of task. I think there should be some rules, when the Controller should be extended or when the helper should be used?
If you're using these functions in your other controllers (and only in your other controllers) I would suggest refactoring them into MY_Controller.
This would also give you direct access to the $CI instance (instead of calling get_instance())
On the other hand, you could create an Authentication library. This might be more suitable..
EDIT::
I would recommend having a MY_Controller as a base, that contains auth wrapper functions, which invoke functionality from a Library that manages this type of thing.
IMO, login functionality has nothing to do with a Controller. That's the reason I would probably put the functions you mention into a helper or a library.
The solution I m thinking:
If you want to follow design pattern, use hook(works like a filter from Java perspective).
Alternate should be extending your My_Controller
I created an class extension of Zend_Controller_Action and added some user defined methods, which will be accessed from any controller so forth.
Every thing is working fine, until I use Zend Tool to create a new Action, as this time The Zend tool will not find out my extended class.
Error Message:
Fatal error: Class 'CMS_Zend_Controller_Action' not found in....
That is the class which extends Zend_Controller_Action and the one extended by other controllers like indexController.
How to make the class discoverable. Do I have to include each and every folders, like my classes are? Does zend does that? I dont think so. How does it do it?
Simple. :-p If it can find your core controllers, then you just need to include the path to your extended controllers.
http://php.net/manual/en/function.set-include-path.php
set_include_path(path_to_your_extended_classes) in your index.php, aka routes file.
I think what you are trying here is not what Zend_Tool is about.
As much as I understand your question and setup you have created a class in your library. Of course, you can extend Zend_Controller_Action with lots of your own classes in your own library/libraries (I do that, too). Adding an action to such a class is maybe unusual but a problem for Zend_Tool for one specific reason.
Zend_Tool I believe is only about the well known structures like /application and same for what is inside /modules. If you create a Controller Class Zend_Tool will do some work for you like adding required folder structure to your /application or /modules folder. Same with action method which require view files. Having a Controller Class in your library does not (should not) need all that and hence is not build into Zend_Tool. I think whatever class you create in your library is not supported in Zend_Tool.
I have a structure that is
application
application/modules
application/modules/default
application/modules/default/models
application/modules/admin
application/modules/admin/models
When calling controllers in admin I understand they must be named like Admin_TestController. This works fine, but my models in my admin module don't seem to be able to load. I have tried naming them and the files in all kinds of ways but it just doesn't seem to want to be able to load them. How should I name the file and model class in a module to be able to use it? I use autoloading.
What do your bootstrap files look like? That is the most import part of problem.
It is very important (in order for the namespaces to autoload) that you you have a bootstrap in each module (located # application/modules/admin/bootstrap.php) that should contain, at the very least:
class Reports_Bootstrap extends Zend_Application_Module_Bootstrap
Notice that it extends Zend_Application_Module_Bootstrap. This does the heavy lifting of registering the namespaces for the MVC of the module.
As Fatmuemoo states the bootstrap for the module should extend Zend_Application_Module_Bootstrap also you should include
resources.modules[] =
In your config. This is in the docs for Zend_Application_Resource_Modules
It seems you need to include a bootstrap class that extends Zend_Application_Module_Bootstrap for the modules you want to use. Check this forum post about a similar issue to see if it helps point you in the right way. Seems you may need more than one to load separate modules.
Suppose you are building a web application that is going to be a packaged product one day, one that users will want to be able to extend and customize.
It comes with a core library consisting of PHP files containing classes:
/library/
/library/frontend.class.php
/library/filesystem.class.php
/library/backend.class.php
Now, suppose you want to keep a clean core that users can't patch. Still, you want the user to be able to customize every nut and bolt if need be.
My current idea is to create an autoloading mechanism that, when a class is instantiated, first loads the core include:
/library/frontend.class.php
then, it switches to the user directory and looks whether there is an include of the same name:
/user/library/frontend.class.php
if one exists, it includes that as well.
Obviously, the user include must contain a class definition that extends the definition in the core include.
Now my question is, how would I instantiate such a class? After all, I can always be sure there is a definition of:
class frontend_core
but I can not be sure there is a
class frontend_user extends frontend_core
However, I would like to be able to rely on, and instantiate, one class name, regardless of whether there was a custom extension to the class or not.
Is there a clever way, idea, or pattern how to achieve this?
Of course, I could write a simple factory helper function that looks for the user class first and then for the core class and returns an initialized object, but I would really like to keep this as clean and simple as possible, because as I said, it is going to be a packaged product.
I am looking for a smart trick or pattern that uses as little code, and introduces as little new functionality, as possible.
Why don't you follow the approach as used by Propel? You generate your base classes and already provide an empty User class (extending the base class) where your users can put their overrides/specific implementation details, and in your code you always refer to the User classes. So basically you just use the inverse of the logic you described.
If the explanation above isn't clear, check out http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4/QuickStart#a6.UsingtheGeneratedSQLandOMFiles and generate code for a small database. The base classes are in the om folder, the (by default empty) user classes are in the root folder.
I would implement hooks in the core, so users dont have to hack the core, but are still able to extend the core using hooks
I'd go with using the constructor of the core class to determine the user class to load, and then implement a factory method in the core class to generate instances of the user class. By making the constructor of the user class protected, and having the user class extend the core class you can be sure that code elsewhere cannot instantiate the user class.
C.
I think it's more complicated with a single filename when you want to use inheritance as well. Basically class user_frontend extends core_frontend has to know where to find both classes. Both must be included.
If you just want to do new Frontend you could use PHP5.3's class_alias to point Frontend to the main class to use. Below 5.3. you could use a ServiceFinder, that knows how to map Service Names to Classes and then get the Frontend with $service->get('frontend') or use a Dependency Injection framework.
Edit I removed the Loader code given before, because it was suffering from exactly this problem.
You could have a loader class that will decide which class to instance:
Loader::instance()->load('Frontend')