feed-io v2.4 : Json serialisation

In version 2.4, feed-io introduces the ability to convert feeds in valid JSON string :


$feedIo = \FeedIo\Factory::create()->getFeedIo();

$feed = $feedIo->read('http://php.net/feed.atom')->getFeed();

echo json_encode($feed);

The whole feed is exported in the JSON string, including medias, categories and additional elements.

Advertisements

FeedIoBundle was the new rss-atom-bundle

Two years ago, I announced the future replacement of rss-atom-bundle in favor of FeedIoBundle. The goal was to get a cleaner code based on feed-io and new features like an user interface to handle feeds, without causing any trouble for rss-atom-bundle’s users. The result was not what I expected : forms made FeedIoBundle much harder to maintain than rss-atom-bundle and almost nobody adopted FeedIoBundle. Besides, rss-atom-bundle’s community is still growing, with some of these people opening new issues and even sometimes submitting pull requests. As a consequence, I drop FeedIoBundle in order to focus on rss-atom-bundle and feed-io.

This isn’t a problem for me to take this kind of decision. I tried something that didn’t work and now it’s just time to put an end to it. No matter how much time I spent on programming FeedIoBundle, it was worth the effort as I grabbed some knowledge thanks to this project.

So now the package will be tagged as “abandoned” on Packagist and all users are encouraged to use feed-io or rss-atom-bundle.

Edit : I managed to remove FeedIoBundle from Packagist, you can’t require it in your project anymore.

PHP and design patterns : a smart way ?

Thanks to Jon Lemaitre’s excellent article “A Response to PHP the wrong way“, I recently discovered http://phpthewrongway.com self-exposed as the counterbalance of http://phptherightway.com. Then came the need to write an answer on the subject, my views on framework, OOP, standards and the rest but I realized I would end up with a very long article full of obvious arguments or at least statements many people already know. Boring. Seriously who wants to read another pros and cons on frameworks and OOP ? Is it really worth discussing it nowadays, knowing how many classes are offered by PHP itself and how its own syntax is object oriented ? I just think that if you don’t want to write OOP code with PHP, you’re free to use another language or to fork PHP 3.

The only subject I will cover in this post is the usage of design patterns. It could have been the wisest part of “PHP the wrong way” but the author failed to provide relevant arguments by focusing on a philosophical point of view. My goal here is to bring a more objective point of view with technical facts.

The wrong way: Looking for a pattern to solve a problem

True, this is a dogmatic approach we must stay away from. Patterns were designed to implement common needs like separation of responsibilities, open/close principle and to save some precious time finding design solutions. However, it has some drawbacks and the use of design patterns requires skills and common sense.

Continue reading