Welcome Guest, Not a member yet? Register   Sign In
I need your help winning a major battle for Codeigniter

I just wanted to jump in here and say that the company that I work for started using zend framework a good 8 months ago or so. At first, reading about it, and the benefits, it seemed like a great idea, and I was totally on board. After using it for the last 8 months, I can honestly say I can't stand it. We've got 25 very experienced PHP guys here, and yet, the documentation for zend framework is so bad, that any time anybody has to do anything new with it, it takes 3 times as long as it should, because of digging through horrible docs. Yes, all the information is there, but to find it is all but impossible. Thank goodness that Zend framework is a use-at-will framework, and modular enough to use only the parts you want to, because we've started only using the MVC and nothing else. Everything else we try to use has too much overhead (both in terms of performance, and maintainability) to be worth the small amounts of benefit we get. Have you ever tried using zend form? Don't. It's definitely not worth the pain you need to go through if you need any kind of customized form that's more than a few text boxes. And if all you need are the few text boxes, creating all the files and crap that you need to do for a zend form is ridiculous. The only problem now is that even though we are only using the MVC part of the framework (we even had to hack the router to get the URLs that we wanted), we still have the overhead of zend framework. We're all wishing that we had used codeigniter (I've used it for past projects and it worked great. flexible, easy to use, and gives you what you need without the bloat... oh, and the documentation is usable). We're a little far in to be able to just change over at the moment though...

Just thought I'd give my 2 cents on the subject.

[quote author="usmc" date="1248206245"]Could you post an optimized sample application we could use as a starting point?
Something that doesn't use Dojo.
Can I have pickles and fries as well.

This is a great opportunity to show that I am just making sweeping accusations with little or no substance to my arguments.[/quote]

Well, I'd start by using the two most prominent applications from both camps. For CI, I downloaded:

http://codeigniter.com/downloads/ (1.7.1)

Since CI is comes as the library + an already bootstrapped and spec'd out application structure, the assumption is that by visiting index.php, its actually making a request through the CI controller.. and without any database interaction.

For ZF, this would be by downloading the ZF Quickstart Application.

http://framework.zend.com/docs/quickstart (zip or tar.gz)

To make it fair, I commented out the db ini settings in application/configs/application.ini, b/c the assumption is that since we want as close to apples to apples with raw performance and throughput without any cost of a db connection.

But, I'd like to repeat in general, that Hello World is never a good indicator for "good" or "performant" a framework since we never really ever want to just build "Hello World" as an application. When you take in the aspects I mentioned above in addition to raw performance, you start to see a balanced framework (IMO) when it comes to enterprise development needs.

Your mileage may vary of course, but I'll continue to look back at this post to see if you have any further questions in your research of both frameworks.

Ralph Schindler
Zend Framework

Our University is starting to try and push Zend Framework... but it seems like it might not be the right choice. I'm a developer and I've spent a good hour + trying to setup Zend Framework and have yet to even get Hello World.

First off, you have to modify the php.ini include_path to get it to work.
Secondly you have to compile the project from the command line.. yet when I tried it, the RecursiveFilterIterator.php file was missing..... how could this be?

/zf.sh create project quickstart

Warning: require_once(Zend/Tool/Framework/Loader/IncludePathLoader/RecursiveFilterIterator.php): failed to open stream: No such file or directory in /Users/scottamort/Projects/zf-1.9/library/Zend/Tool/Framework/Loader/IncludePathLoader.php on line 31

Fatal error: require_once(): Failed opening required 'Zend/Tool/Framework/Loader/IncludePathLoader/RecursiveFilterIterator.php' (include_path='/Users/scottamort/Projects/zf-1.9/library:.:') in /Users/scottamort/Projects/zf-1.9/library/Zend/Tool/Framework/Loader/IncludePathLoader.php on line 31
U52:bin scottamort$ ls ../library/Zend/Tool/Framework/Loader/IncludePathLoader/RecursiveFilterIterator.php
ls: ../library/Zend/Tool/Framework/Loader/IncludePathLoader/RecursiveFilterIterator.php: No such file or directory
U52:bin scottamort$ pwd
U52:bin scottamort$ cd ..
U52:zf-1.9 scottamort$ cd library/
U52:library scottamort$ ls Zend/Tool/Framework/Loader/IncludePathLoader/RecursiveFilterIterator.php
ls: Zend/Tool/Framework/Loader/IncludePathLoader/RecursiveFilterIterator.php: No such file or directory

I browsed the directory and found the file was actually called: RecursiveFilterIterator.php000064 or something with a crazy extension like that... I renamed it to .php and then the create project command worked...

Having just downloaded a framework for major production work and finding I can't even create a project because somebody over at Zend forgot to put in the right extension on the file...


CI took me no more than 5 minutes to get and running a Hello World app.. I sure can't say the same for ZF. I'm looking forward to spending lots of time with CI and this community.


Its funny that your university is pushing ZF. After spending some serious time working in it I now consider ZF to be an academic framework. On paper it looks great but in practice it is ridiculous. The reason it is ridiculous has less to do with the framework itself and more to do with its implementation.


Stop picking at it or it will bleed

It seems like every release modifies core functionality (or at least allows for yet another academic interpretation of it) without fixing the bugs that have existed for quite some time. Take Currency for example or the Zend Tool and how their latest attempt to support modules in a standard way is not supported on Zend Tool for windows. And yet they have time to change bootstrap and fork away from their initializer pattern negating much of the community documentation.

Poor documentation

There is a tremendous amount of documentation on the Zend Framework but the references never come together. Each reference for a particular piece of the ZF is a lesson in PHP OOP but it never points back to usage in the framework as a whole. This is where its strength is really its greatest weakness. Its abstract nature means every blogger with a theory can cook up a different flavor that may or may not be viable and can be dis-proven or argued against by another blogger with a different theory. As a new ZF developer since the documentation gives you no best practices you will need to research a great deal through google and then you will truly know insanity. Zend has essentially taken a stance protected by plausible deny-ability by not promoting any standard practice. They basically say you can't blame us if you interpreted this wrong since we never told you how to in the first place.

Reliance on caching

Zend Framework is a model of abstraction but also over-engineering. Zend knows that it is bloated but they always fall back to the same position "byte-code caching". Whenever there is an optimization problem they will insist that you should simply turn on their APC wrapper and everything will be fine. How sad.

I am certain that ZF will continue to spread like cancer. Most universities and businesses do not take anything seriously unless it is overly complicated.

So I guess CI lost the battle?

I don't see much for the developer/consultant to do in these cases besides make your best effort to educate the company/client about its options as calmly and rationally as possible. Once you've done that it's their money and their decision.

When the enterprise "X" sales guys get in there, notice how all roads lead to "X"?

Hang on, you may not have lost the war--big projects with big technologies fail all the time and the time may come when they need to be "rescued."

If not, you can always enjoy the billing while it lasts and let them worry about the consequences of their decisions, or just move on to greener pastures.

[quote author="wabu" date="1250210909"]So I guess CI lost the battle?

I don't see much for the developer/consultant to do in these cases besides make your best effort to educate the company/client about its options as calmly and rationally as possible. Once you've done that it's their money and their decision.

When the enterprise "X" sales guys get in there, notice how all roads lead to "X"?

Hang on, you may not have lost the war--big projects with big technologies fail all the time and the time may come when they need to be "rescued."

If not, you can always enjoy the billing while it lasts and let them worry about the consequences of their decisions, or just move on to greener pastures.[/quote]

CI lost the battle but maybe it won the war. Zend did a really good job of setting this group up to fail. They came in, set up Zend core and charged them tons of money for support. They told them that ZF would fly all around the world and deliver presents to all the good boys and girls and then left. They told the company to hire PHP developers and the company went and hired anyone who said they knew PHP with a heartbeat. Right now they have 10 hobby level PHP "programmers" who are hacking ZF to pieces. Since Zend prides itself on being flexible the devs have bent it every which way. They never set down any best practices (even though the company was billed for it). I mean I can't stop laughing when I see 10 - 12 lines of include statements in a controller action. I have tried to push new fangled web design concepts like "CSS" and graceful degradation to no avail. Right now I am staring at controllers filled with hand typed sql, html templates with in-line styling and of course <b> tags. Yeah I think it was a good thing CI is nowhere near this. I will enjoy it while it lasts.

[eluser]Rick Jolly[/eluser]
The primary aim of the Zend Framework claims to be simplicity. They have some great components, but MVC is anything but simple.

Here are some of my gripes:
Quote:1. Naming conventions

PEAR style naming conventions where class names map to directories are excellent and necessary for autoloading. ZF uses those conventions except with MVC.

Autoloading resources such as models aren't easily achieved. To address this, ZF updated their autoloader and introduced a resource autoloader. Now the code and usage is much too complex.

Controllers should be loaded automatically from any directory without having to explicitly add controller or module directories to the front controller. Remember convention over configuration? This would be possible by allowing for PEAR style naming conventions.

2. Helpers

Controller and View helpers are kept in separate files which means occasional code duplication.

To access a controller helper you have to type $this->_helper->SomeHelper. Why not a generic factory method, or more simply forget objects and use static methods directly. I know the testability argument against static classes, but those without class variables should be fine, correct?

View helpers are abstracted away such that each helper method must be in its own class. Static methods accessed directly from the view are simpler and more transparent. If these helpers must be objects, then just use a factory class.

3. Aversion to extract() and static methods

In view files we must use $this to access a variable or helper. That is a lot of unnecessary typing. The php extract() function could have been used for variables. Static methods could have been used for helpers.

4. Over engineering

If the ZF must be case study of design patterns, then at least get it right. Currently, one thing that bothers me is that the front controller contains the dispatcher, and the dispather contains the front controller. Like a "circular reference".

I hope Ralph and others are listening to the criticisms. ZF, currently at version 1.9, has a great opportunity to rethink their MVC implementation in version 2.0. Hopefully they are listening.

My first crack(or one of the first) at frameworks was ZF. I actually managed to set it up with the "First install" instructions (no script then to set up a project). Ok, all good until that.. Then to make something useful..reading the docs..everything out of context. Damn! I really felt stupid reading the docs and try to get the examples to work, but failing with 90% of them because my crystal ball was out of order and didnt know what the author have done BEFORE that particular example snippet Smile I dont know how its now but back then the MVC implementation sucked balls big time and wasnt nearly as good as in CI(or maybe I just didnt know how to implement it properly.. again bad docs Smile ).

ZF really needs some best practises and proper documentation(for us dumb people). And ZF really is a resource hog, atleast when coded improperly(and thanks to not having best practises, we dont know what is the way to code proprely). When you really need couple of the libraries at the same time, it can cost a lot in CPU & memory. We have a customer whose website(medium sized) was made taking "advantage" of ZF in many ways. This site was first installed on our shared server but we had to move it to a virtual server as it almost crippled the server on its own. ONE request took 25 megs of memory initially. After optimizing the best they could, they squeezed it to 15 Megs with some kind of caching etc. which was still quite alot as the website was nothing fancy.

Theme © iAndrew 2016 - Forum software by © MyBB