Ok, so I have heard the Zend Framework KISS mantra (or "extreme simplicity" as they call it .. or is that something different?) for years. Often enough that I might even be tempted to believe it. Now that I am actually using the Zend Framework on my first project, hitting bugs/limitations in Zend_Feed and therefore looking at the code, I must say I am seeing feature duplication with internal PHP features that does not quite fit in with the KISS principle.
Most classes that can download something from the web (though not all), always use Zend_Http_Client. You can even set a default instance. I presume this is to be able to set stuff like the default timeout. Now the thing is, we can already define a stream context with PHP internal means. This would probably be just a minor annoyance to me. But as a result of the ZF unique approach to KISS, the load feed from URI method, first loads the content of the URI via the Zend_Http_Client, which then passes things to the import form string method, which uses DOMDocument::loadXML() (in static context, which is no longer allowed in current PHP, a ticket for this already exists). Bummer though, that this means that we loose all the nice magic encoding handling we would get by using DOMDocument::load(). So if our happy feed is encoded, lets say in UTF-16, then you cannot parse things with Zend_Feed.
The ezComponent guys are also working on a Feed component and things parse fine using the not yet as stable released version from subversion, because they are doing the right thing. Unfortunately they choose to reinvent the wheel by coming up with their own (not so) clever class directory structure, which I find highly confusing, but more importantly simply irritating giving that everybody else does it differently.
So what will I do now? Using a not yet released ezComponent, which will require adding code with a whole new loader logic is not exactly great. Maybe in the future I will flat out use ezComponents, but mixing yet another loader (or explicit require statements, which can probably break between releases) is just not what I want to do. I refuse to sign some CLA to contribute. A co-worker has signed the ZF CLA, so he might be willing to submit a patch. This patch could also remove the fact that Zend_Feed parses the entire XML twice!!! Let's see if they are willing to accept a patch that sidesteps their beloved Zend_Http_Client. It will also be interesting how quickly any changes will come in, considering that Zend_Feed seems to have gotten little attention in the last release in spite of some pretty basic feature/fundamental requests.
BTW if you ask why I wrote a blog post instead of submitting a ticket. Well I cannot submit tickets. For some reason I do not have the rights to do so, even though the Zend Framework sites claims that anyone can submit new tickets. I guess this is some config issue, but the telling part is that since they use Jira, I spend about 10 minutes clicking through the site scanning all the different buttons and links it offers. Jira is a prime example of what happens if you let feature junkies design a UI. It is one of the few issue trackers that can compete with bugzilla after all ;)
Here is the patch. I tried it with a handful of feeds (Atom, RSS and one RSS UTF-16 feed). I have added a new static method Zend_Feed::importRaw() and removed the double parsing. As well as the "illegal" static method calls against the DOMDocument class.
Forgot to add that I the above patch is to be considered public domain. So take and use at will, but do not hunt me down if it contains bugs :)
So I'm not the only one having problems with that ticket system...
You can very easily use the autoload with just doing this (providing ezc is in your path):
spl_autoload_register( array( 'ezcBase', 'autoload' ) );
I'm waiting for the day to see a framework, which tries to please a lot of people and is really KISS. One of the reasons, why okapi exists (and tries to be small, lean, feature-poor and basic but easily extensible in its core)
But I do not share your point about Jira being like Bugzilla :)
Hi Lukas, this is great feedback. I'm sending a link to this post to the leads on Zend_Feed and Zend_Http_Client. Can you please send me your username so I can make sure you're in the right group? I'm sorry, we used to require new users to mail us, and now we have captcha setup to make things simpler. Could it be that you signed up before we made the change, and tried to post later after the instructions for emailing were taken down?
Balu, please also mail me if I can help you with the issue tracker in any way.
@Lukas Did you still have to sign the CLA to get on the bug tracker? ;)
No, the bug tracker does not require this. Wil also now opened up my account to allow for ticket creation. Another topic of non KISS code to talk about would be the Zend_Loader.
I maintain Zend_Http_Client - I am aware that it's definitely a very complex (not complicated) way of doing simple GET requests to fetch a feed - but we needed a solution that will (a) support the more complex requests (file uploads, raw data, custom methods etc.) and (b) works everywhere regardless of URL wrappers/cURL being enabled or not.
If you have any feedback or suggestions on how to simplify / refactor Zend_Http_Client, I'd love to hear them ;)
There is nothing wrong with Zend_Http_Client. For example in this same project we will now need to go through a proxy and I fully expect Zend_Http_Client to make it much much easier for us to do this transparently. Now what I noticed is that while its possible to define default http client instances, these defaults seem to apply to only a set of zend classes and not all. I will have to see about this.
My issue is that everything is forced to go through the Zend_Http_Client. This is where you are starting to loose the KISS way. Its nice to give the additional convenience, but you must make it possible to leverage as much native functionality as possible. This is for performance reasons, but as my case illustrated its also relevant when you are missing functionality that is available natively in PHP already, that you are making inaccessible with the current approach.
While I am a big fan of the Zend Framework, I would be the first to admit that it's anything but simple. There is a definite learning curve, and a lot of functionality that is probably not useful 90% of the time.
It does provide many professional grade solutions to common development scenarios, and that's us developers use it.
But sometimes there is no other way than to 'hack' it into oblivion (and submit tickets. Zend are very responsive to those)