I'm using CodeIgniter and I have a few utils that I want each controller (that is, each controller file) to have access to.
The question is: where to put these?
I thought of helpers, but the CI documentation talks only about extending existing helpers, not making your own. I'm sure that doesn't mean I can't make my own helpers, but it does mean I don't know how they should be built (procedural? Methods of the global CI instance? etc)
I also considered hooks, but this is a poor fit I think as I'm not extending core functionality.
Or is there some other way I'm missing?
It's been a while since I've done this but I believe I used two approaches.
Creating a new, custom helper that goes into /application/helpers, following steps noted from this answer: CodeIgniter: Create new helper?
Creating a new library class into /application/libraries which I also activate in the autoload configuration found in /applications/config/autoload.php. This way it's always available to my controllers when I need it. CI has good documentation on this one (http://ellislab.com/codeigniter/user-guide/general/creating_libraries.html).
I did it simply by adding a file to the application/helpers folder (maybe I created that folder - I can't remember) and then loading them in the usual way.
Related
As the title says, I need to create a method in Laravel that works like view('name'), but includes files from another folder.
What's the best way to do this without altering Laravel's core functionality?
I was thinking maybe of extending the functionality but I do not have enough Laravel knowledge to know what's the best place to write the function in and/or the best way.
Created an external .php file that I've included in Laravel's index with the functionality that I need, and it was usable in the .blade.php files as well.
How do I use a component that I created in cakePHP inside one of my model classes? Is this possible?
If so, please let me know how I can do so
It is possible but pretty bad practice in a MVC framework. You should re-think and re-organize your code if you think you need to use the component in a model because something is cleary wrong then.
A component is thought to share code between controllers, only between controllers.
Components in CakePHP 1.3
Components in CakePHP 2.x
Components in CakePHP 3.x
To share re-usable code between models it would be a behavior. For a view it would be a helper.
If you have some really generic code it should be a lib or put it in the Utility folder / namespace or create a new namespace. Check the existing classes there to get an idea what to put in there.
No code was provided so it is not possible to give any real recommendation on how to refactor it. However the way you want to use the existing code won't work in the MVC context, so time to rethink your approach of whatever you try to do.
It is possible to use a component inside a model (but I cannot comment if this is a recommended or a best-practice).
Inspired from original source, an example to use a component called ‘Geocoder’ in a model:
App::import('Component','GeoCoder');
$gc = new GeoCoderComponent(new ComponentCollection);
Then you can use $gc to call the functions of the component.
--
P.S.: I do not want to encourage bad programming practices, but sometimes the pressure of deadlines (in real world projects) may force a developer to make such decisions.
#AD7six
// Use anywhere
AuthComponent::user('id')
// From inside a controller
$this->Auth->user('id');
From the cake PHP documentation they provide AuthComponent::user('id') so that it can be used in places other than a controller.
Maybe I need a bigger hint, but why shouldn't my model be able to access ACL information ?
What class(FrontController , Bootstrap, Dispacher....) sets up the default structure path in ZF?
There is no single instance that has all the paths. Each component has it's own defaults, e.g. the FrontController knows that the controller directory should be named controllers, but it doesn't know how to make a full path from it (Dispatcher does it) or where to find the Action Helpers. That's defined in ActionHelper Broker. Consequently, Zend_View_Abstract holds the paths for View filters, helpers and scripts, etc.
Like #Pascal mentioned in his comment, you should not modify ZF at it's core. You will lose the changes once you update to a newer version anyway. Configure the paths through the API in your bootstrap or through the application.ini instead.
Actually it's the dispatcher's job to find the requested action controller.
So you'll have to extend either Zend_Controller_Dispatcher_Abstract or Zend_Controller_Dispatcher_Standard or even create a completely new one based on Zend_Controller_Dispatcher_Interface to fit your requirements.
But be aware that you'll have to change the way Zend_Controller_Action_Helper_ViewRenderer tries to find the required view files, too.
I'd like to use Zend_Tool (ZF 1.9) with my project, but I would like to be able to customize the default output of new files. For example, all Controllers should have a specific header pre-pended to the output with phpdoc markup and licensing information to avoid me having to add this as an extra step.
Also, for this particular project (but not all other projects), I need the controllers to extend something other than the default Zend controller as I have extended that for some specific functionality.
The documentation alludes to the ability to do these things, but it does not make it very clear.
From what I can tell I can set up a ~/.zf directory (on ***nix based systems) and include custom providers there. However, this will be machine-wide as opposed to limited to single project scope. Also, while this will add new providers it does not (seemingly) allow me to customize the functionality of existing providers.
Any help here would be greatly appreciated!
Essentially what Jacob was getting at: what you're talking seems like simple class extending. There's a really simple slideshow introduction to extending Zend Framework here:
http://www.slideshare.net/PHPBelgium/extending-zend-framework-presentation
There are also lots of other resources available online for extending Zend Framework. You can create separate source trees for your different projects, and functionality common to various projects can be added to abstract classes that are in common folders. Something like this isn't common, but I've found it works in those kinds of situations:
class My_Component_HelloProvider extends My_Common_Component_HelloProvider
{
public function say()
{
echo 'Hello from my provider!';
}
// public function do() is inherited
}
class My_Common_Component_HelloProvider
implements Zend_Tool_Framework_Provider_Interface
{
public function do()
{
// do something
}
}
Let me know if this is different from what you're trying to do, but there's no reason you can't build multiple applcation extensions from a single instance of ZF.
You can naturally continue to override when you define the specific classes. You can declare them to be based on your class, rather than the ZF class.
For specific projects, you can modify your classpath to be a custom version of ZF or possibly have a custom override folder. With a custom folder then your changes are not machine wide, but neither is your zend framework. on ***nix based systems, you can leverage symbolic links to keep yourself to one copy of ZF.
Are you trying to modify your source code to include the license headers and PHPdoc? If so, what I have done in the past is have a simple build step that adds the information you need. Each file type can have the appropriate header information. You can have nice tags to tell the system to ignore files, or only run on controllers.
Good Luck,
Jacob
straight to the point :
I am using Kohana, and I am looking at another script written in plain PHP. In the script, I have a class ShoppingCart. If I am to convert the script to Kohana, where am I to put the class, its methods and its properties?
Is it in my existing default controller? Or should I put it in a separate controller? Or as noobie as it may sound, will I put it in the model?
That depends on the specifics of the class I suppose. To be honest I don't know anything about Kohana, but there's probably a place for "vendor files" somewhere. Maybe it's best to place it there and write wrapper functions for it in your controller. If the class already integrates well with Kohana you may instead choose to use it as a controller or model directly. Or you might want to take the time to rewrite it to make it work as a controller...
Only you can evaluate the best place for it, there's no hard and fast rule here.
Kohana has a folder for 3rd party libraries. The main one is under system/vendor, you can put it in you application/ as well.
Many PHP class loaders require details like your filename should be the same as the class name (at least that's what I read in the Kohana documentation) if you want the classes to be automatically loaded.
If you need to use 3rd party code in your app it's recommended that you create a folder in your app / module folder called 'vendor' and place all of that code there.
You can then include the files by calling:
include kohana::find_file('vendor', 'filename');
If needs be you can also create a wrapper for the external library, a good example of this is the email helper which uses the 3rd party Swift email library.
If you're porting your own class to kohana then you need to work out what the class will be doing and categorise it accordingly.
If the class will be fetching items from some kind of database then you should make it a model. Libraries are usually sets of code that you want reuse across controllers / models, such as authentication, calendar generation etc. Controllers are used for passing data from models to your views / libraries.
See the docs for more info
As per kohana convention, you should place custom classes in application/libraries folder. However for this, you need to know how to get the class to work after putting it there. If you can't figure that out, you can do anything like putting it in your controller or making another controller of it, etc.