I have a project that uses Zend Framework and Zend_Translate.
I had to alter the standard CSV Adapter to Zend_Translate slightly. Now I'm confronted with the question where to put this altered adapter.
By default, adapters are stored in
/Library/Zend/Translate/Adapter/Adaptername.php
This is where I've put the new adapter as well.
However, I wouldn't like to "pollute" the Zend library with my custom extensions: I would like to stay able to update ZF without having to worry about losing files; I want to remain able to use a centrally installed version of ZF; and the custom adapter is part of the project I'm working on, really.
Is there a Zend Framework way of dealing with this, or specifying an alternative loading location?
Language adapters are loaded using
$this->_adapter = new $adapter($data, $locale, $options);
(Where $adapter will be Zend_Translate_Adapter_Adaptername)
so standard autoloading rules apply. Is there a simple way to tell the Zend Autoloader to look in a second location?
You can add it to the lib folder
/lib
/Zend
/Translate
/Adapter
/Csv.php
/My
/Translate
/Adapter
/Csv.php
Depending on how your autoloader is setup, you have to setup the "namespace" with it:
$autoloader->registerNamespace('My_');
Or, if you dont like this, put it into your models folder. Basically, it doesnt matter where you put it, as long as it is accessible somehow by the autoloader. The Zend_Autoloader can register arbitrary autoloader callbacks, so it's really up to you.
I can't comment on Gordon's answer due to this site's rules, but he's got it right. To answer your question regarding how to load the adapter, you'll need to pass the full class name to the constructor of the translate object:
$translate = new Zend_Translate('My_Translate_Adapter_Class', ...);
The component first checks in the Zend namespace in case you've passed in a short name (like 'gettext'), but will then attempt to load the adapter name as a class directly.
At least, this is true in 1.10, and I imagine has been for a while.
Related
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.
I am pretty familiar with Zend Framework details and how most things work. One area that I still don't fully understand is the way Zend Framework loads resources from application.ini.
I understand I can create my own protected _init functions and these will be called automatically during bootstrap.
The Zend Framework documentation is lacking in certain areas.
For example: How and when does the resources.db config options get loaded? I have nothing in my bootstrap that talks about db. Does this get loaded on demand or actually during the bootstrap process?
Any links of references explaining this would be very helpful.
Your bootstrap class ultimately inherits from Zend_Application_Bootstrap_BootstrapAbstract. The bootstrap() method in this class first searches for class methods prefixed with _init, and runs these. It then looks for resource plugins, which are populated by the 'resources' part of the options array. The options array comes from the configuration passed to Zend Application, which usually comes from application.ini.
Resource plugins map to a class on the file system. So resources.db by default will create an instance of Zend_Application_Resource_Db and run it (which in turns sets up the relevant db stuff). There is a full list of the built in resources here: http://framework.zend.com/manual/en/zend.application.available-resources.html
All your application resources are run during the bootstrap process, unless you've told the bootstrap to init only specific ones.
There is a reasonably detailed overview of how it all fits together in the docs: http://framework.zend.com/manual/en/zend.application.theory-of-operation.html, but it's the kind of thing that you don't really need to know the details of unless your requirements are a little custom.
I'm starting to write a application in php with one of my friends and was wondering, if you have any advice on how to implement module support into our application.
Or is there a way how to automatically load modules written in php by a php application? Or should i just rely on __autoload function?
And we don't need plugins that are installable via a web interface, we just need some clever way to associate web pages of our project to some classes (they will render the page) so index.php can call the right class and retrieve it's generated sub-page.
And we are not using any kind of framework, for now at least.
Re your comment: Autoloading in conjunction with strict file naming would be totally enough in this case IMO.
You could define a specific namespace (not in the new PHP 5.3 namespace way, just in the sense of a common prefix to names), e.g. Module_* for module class names.
You could then organize your modules in directories with class files that contain exactly one class definition, for example:
/modules/Mail/index.php // defines class Module_Mail
/modules/Database/index.php // defines class Module_Database
/modules/Image/index.php // defines class Module_Image
Your autoloader function would then, whenever a Module_* class is requested:
$Database = new Module_Database("localhost", .....);
include the correct file from the right directory.
That's the way e.g. the Zend Framework does it, and does so pretty well.
Consider choosing a more specific namespace than Module_ to assure interoperability with other scripts and applications if that is an option in the future.
Slightly related: In a PHP project, how do you organize and access your helper objects?
It sounds like you are looking for a way to organise the different tasks that each page needs to carry out. In this case, take a look at the MVC pattern. It provides a simple way to seperate your data access (models) and how you render/present information (views).
You can map pages to functions with ease. If you store the information in an array of mapped values, and then use a function to compare the requested URL with each of the URLs in the array. Such an array could look like this:
$urls = array(
'/' => 'index',
'/aboutus/' => 'aboutUs',
);
There are several articles that discuss how to implement it in PHP in a couple of hours. This article is a very simple guide. I am not a fan of their use of the registry pattern but reading through should provide you with enough information as to how you can implement it yourself.
Regarding autoloading, you can also use spl_autoload_register, to define several (more than one) autoload functions, so each module can set up it's own implementation of autoloading.
All you need here is an MVC architecture, with one Controller class associated with each "module".
If you are not against using a framework, go for Zend MVC
It allows you to have the following principle :
An URL like this : http://yoursite.com/my-module/edit
Will more or less automatically call the editAction method in the MyModuleController class.
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.
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.