I'm building an MVC framework and I was thinking that most of the classes used in the making of an application are models. So since I know that every model is inside a folder I could just use the native __autoload() function to implement a "feature" (that obliviously you can enable and disable as well) that automatically loads a model (Lazy programming).
Is it good or should I discard this idea? If the latter: why?
If you're building a PHP framework, it might be worth looking into the PSR-0 standard for autoloading. I'm afraid I don't know much about it, but I believe a number of substantial frameworks and libraries have agreed to abide by it for interoperability. I believe that would include Symfony2, Propel2 and the next major version of Zend Framework.
There is absolutely nothing wrong with relying on the __autoload() function, as long as you have a consistent naming scheme.
In fact, it's often better to use autoloading - it stops you from including classes "just in case" you use them.
Related
I'm not sure if this is possible, but let's say you want to build a CMS, but you're torn between 2 frameworks because each has some features that you like. Is it possible to create the CMS with both framewoks? Does this approach have merits or pitfalls?
Speaking strictly about the Zend Framework (ZF) I would say yes. ZF components are written to be as independent from other components as possible. I would say that it would not be very difficult (It may actually be quite common) to integrate libraries of ZF into other frameworks like Cake, Symfony, or Codeigniter.
Is it possible to create the CMS with both framewoks?
While it's possible to use components from the Zend Framework inside other Frameworks / CMSs - this may be the case with other component libraries as well, but Zend's the most modular one that I know - It's usually not a good idea to mix two full-blown Frameworks.
Many central functions like MVC structures, URL routing, the database layer, Unit testing, error management and so on are by nature unable to be served by two frameworks at once without massive friction. Also, you're likely to get problems when one of the frameworks needs to be updated.
I would recommend to pick the framework that covers most of what you need, and try and add the missing features using plug-ins or own modifications.
Your question is too abstract.
For instance Zend Framework is more to be a library of specific functionalities ready-to-be-include into Your codebase then some closed development environment like for instance Symfony framework.
Thanks to it can be ZF simply included into your codebase (and Symfony too).
Symfony Framework compared to it is closed solution depending on front server environment so you cannot use it like some other framewor's slave.
It would really depend on which things you liked about both...
Zend Frameowrk is more like a library, so you can pick and choose components from it. Symfony also has some re-usable components you can use.
Really, you can do anything... it just depends how much work you want to do, and how willing you are to modify the framework code. Note: most other PHP frameworks are not nearly as flexible as Zend Framework (next up probably being Symfony).
This sounds very messy, so I'd advise against it, unless you use it in the fashion I've described above. It's easy to pull ZF or Symfony components into other frameworks, but not the other way around.
Hope this helps.
The composability of most frameworks is such that that is most likely to give you all the disadvantages of both, while simultaneously eliminating most of the individual advantages of both.
It seems to me like one framework will for serve as the core - bootstrapping, MVC stack, routing - while the other will be used to pull in specific functionality - like classes for forms or filtering or interacting with web services, etc.
As much as I prefer Zend Framework for the core - and most everything else - its use-at-will architecture argues for making the other framework the core and pulling in ZF components where you need them.
As #Adrian notes, it's easy to pull in ZF components into a project built primarily on another framework, since ZF is designed with that flexibility in mind. Other frameworks are less accommodating in this regard.
You can do it. Most modern frameworks (Zend, symfony, flow) is capable to use parts of other frameworks. Symfony 2 uses Zend Logger, flow3 uses sfYaml... It is possible tu interchange some components.
But, imho, you should stick to one framework as a core, and use second only to relatively isolated subsystems. Adapter and Facade design patterns can help you to mix them together - some components / clases demands some wrapping before use in non-native environment.
For further reading: http://www.symfony-project.org/book/1_2/17-Extending-Symfony#chapter_17_integrating_with_other_framework_s_components
Of course it is possible and I don't see something wrong with it. For example I used CakePHP and Zend on a relatively large Project which was kind of a cms. CakePHP for the core (Routing, MVC) and Zend for some "Modules". Mainly for PDF, E-Mail (smtp), FTP and a few others that CakePHP was not that good at. With Cake it was fairly easy to use ZF components and didn't feel hacky at all.
In fact, ZF was written to be as independent as possible, so that you can use any component at any time anywhere. Yet, it would not work the other way round (Using ZF as core, and Cake components). Surely it is possible, but a real pain with no benefits. So ZF could be used propably inside of pretty much any other framework and nothing would be wrong with it, imho.
i want to convert zend php to cake php but not finding correct book and guiding to do that????
Just download Cake, install and configure it and then gradually migrate your existing code into it. There is no standard recipe how to do that. You have to do that manually, class by class, line by line. Cake's API is quite different from ZF's API so this will take a while, depending on how much coupling you got. Also, ZF does not have any ActiveRecord, while Cake is built around that, so the database part will probably take longest.
Migrating from framework to framework is a sure thing to introduce bugs into the code. If you don't have a solid unit-test base already, it's a good opportunity to add a test before migrating a class.
On a sidenote: why do you want to to do that anyway? Cake is compatible with PHP4 and has a rather messy and slow performing codebase. Migrating your application from ZF to Cake is likely a downgrade. And as others pointed out, you could have Cake and ZF coexist.
I suggest you learn how to use both frameworks and then port the code manually. There are no tools that will do this for you; there simply is no way to do this automatically, especially given then highly flexible nature of ZF.
Learn both, use your understanding to migrate the code.
From php.net:
In PHP 5, this is no longer necessary. You may define an __autoload() function which is automatically called in case you are trying to use a class/interface which hasn't been defined yet. By calling this function the scripting engine is given a last chance to load the class before PHP fails with an error.
Now I am wanting to know, is it bad practice to solely use __autoload to load the appropriate classes on a dynamic site?
The way my site is setup is to include files into the index.php file, for example http://www.site.com/index.php?p=PAGE-I-WANT-TO-LOAD
So if I am on the forums section or the blogs section of my site, I want only appropriate classes and functions to be loaded, so I use autoload but I never include a file manually, should I be using __autoload as a last resort or is what I am doing fine even on a high traffic system?
Bad? No. __autoload() is one of my favorite additions to PHP 5. It removes the responsibility (and annoyance) of manually having to include/require the class files necessary to your application. That being said, it's up to you as the developer to ensure that only the 'appropriate classes' are loaded. This is easily done with a structured naming scheme and directory structure. There are plenty examples online of how to properly use __autoload(), do a Google search and you'll find plenty of information.
Autoload is a good way to load only what classes is needed.
In PHP 5 >= 5.1.2, most of the problems with the old __autoload() dissapeared, thanks to spl_autoload_register().
Now I am wanting to know, is it bad practice to solely use __autoload to load the appropriate classes on a dynamic site?
Not at all. You can rely on autoload, all you need to do is to devise a good naming convention and implement an efficient autoloader.
There is one major issue to consider. Autoloading and Zend Guard do not play well together, because Zend Guard tends to rename things, which will mean that the naming convention you decided to use will most likely not be the same. If you will be using Zend Guard (or any other obfuscator for that matter) you will most likely be forced to include all the files by hand.
Here is a quote from the Zend Guard user guide:
Autoloading classes will not work since the filename on the disk would not
match the obfuscated class name.
The only danger to __autoload() is if you define a poor autoloading function. Generally, all you're going to get in terms of a performance hit is a few disk seeks as PHP looks for the right files that contain your classes. The upside is getting rid of all those annoying include() calls.
If you're worried about performance at this level, then you should already be using an opcode cache such as APC.
I keep seeing CakePHP and CodeIgniter referred to as full stack MVC frameworks, whereas Zend Framework is said to be non-full stack. What exactly does this mean?
Zend Framework is a use-at-will framework, which allows you to use some of its components. You could even use some of these components in an application built using some different framework. In this way, a use-at-will framework is more like a class library.*
A full-stack framework means that using any part of it depends on you using all of it. For instance, you must use the framework's data access library, MVC architecture, code-generating scaffolding, etc. and these components all rely on each other working together to form the complete framework.
Re your comment: Yes, coupling is one way of looking at it. I look at it as a balance between assumptions and flexibility. A full-stack framework assumes you're using the whole framework together, and from that assumption it can make some extra magic happen.
ZF was designed to minimize the assumptions (that is, minimize the coupling). Its components make few assumptions about whether you're using the rest of the components, reducing dependencies but increasing flexibility. But fewer assumptions means less magic.
Both styles of framework have legitimate advantages.
* One key difference between a plain class library and a framework is that a framework is intended to be extensible. You're encouraged to enhance the functionality of a framework through OO mechanisms like subclassing or polymorphism. Whereas a class library may assume you will use its API as-is, without extending its functionality.
I've been looking for a good PHP ORM tool to use, and I recently found a good ORM class in Kohana. It has a fairly good and simple ORM implementation. The problem is, the code is unreusable outside of the Kohana framework without a rewrite/refactor. It relies on the Kohana class loader and various framework loading strategies to even work in the first place. Further, the required classes aren't packaged into a single dependency directory, or even multiple directories.
When I do this rewrite, I intend to republish the code via sourceforge or something, and those guys can of course reuse it if they want. So, should I just package the fileset needed into one directory, and make the appropriate classes do a require_once on any dependant classes, and 2 should I stick with the original class names that are project dependent (like Kohana_exception) even though it is pretty much unrelated to the Kohana project as a whole?
A second option would be to write another classloader that is a simplified version of the Kohana Framework classloader, and only cares about the ORM related stuff...
If you think what you are doing will be a marked improvement to the Kohana project you should make your changes and submit a patch to be considered by the project's maintainers. You probably aren't the first person to appreciate a part of their framework and component-izing their framework into smaller bits may be something you could help encourage by submitting a patch (though that will require much more time on your part to engineer).
It sounds like you are extracting a piece of their framework for independent use so it doesn't sound like you're forking at all, though I can imagine removing all of those dependencies may sure seem like a fork.