OpenEats review


This time we’ve decided to review open-source Open Eats Project “an open source recipe/meal planner that can be accessed by anyone across the Internet much like other commercial sites”:

This is not only web-site though but also symfony 1.0.x driven project available for downloading.
Does not look like project is actively evolving, last posts in blog is dated by this summer (there was mentioned that 2nd version is planning which would work with symfony 1.2). But even though it’s pretty much ready for using. So basically it’s great source for self-learning. The project is sharing as bundled with whole symfony framework and there is detailed instruction about installation. Of course installation itself is not user-friendly (and comments at the bottom just proves that. It’s not symfony problem but pretty major problem of developing some kind of 3rd party tool which would simplify running of symfony driven projects for end-users. We already wrote about this problem some time ago).

But at this project we see in first time some kind of “install” tool for symfony project – it’s located in /web/setup folder – non-symfony script which asks for db/app settings and write them into symfony conf files.

Another interesting thing in Open Eats Project – it uses Zend Lucene for search feature.

Code is pretty well formatted and accurately written so anyone interested can easily understand in which modules what to look for.

A few plugins are using there which we never used, e.g. sfEventCalendarPlugin, sfPagerNavigationPlugin so was interesting to look on them (for symfony 1.0.x though).

We did not like that all database stuff is located in big config/schema.xml file. As for us, it’s preferably to keep db logic in separate plugins which would give this project extra value as those plugins could be re-used in another projects (e.g. user management related stuff), etc.

Another note it’s not actually community (main page of site states “Website community to shares recipes”). It’s rather “multiuser recipes management tool” 🙂

But even though if you are symfony 1.0.x beginner (is there still any who start learning symfony with 1.0.x ? :-)) – it’s worth to look into this.

6 replies on “OpenEats review”

Hello, I am the only developer of OE and thank you for your comments. 2.0 is something that will get done one day, but being the sole developer, and having a full time job, along with a house to take care of, and a wife to spend time with, I just don’t have a lot of spare time right now to work on OpenEats 2.0. During the planning stages of 2.0 I had two other people that had signed up to help, one for coding, and one for design/graphic, but how things are in the world of Open Source, they have disappeared.

As far as keeping the db logic in separate plugins, OpenEats was my first real PHP project and I used it to learn the craft so some things may not be done as a pro would of done. I evolved through out the year of coding OE and learned better ways of doing things. Symfony 1.0 didn’t have the best plugin mechanism either.

Another reason for the delay is the learning curve of symfony 1.2, along with the fact I don’t really like all the things they have changed, such as the “form” framework and using Doctorine ad the ORM.

Hi Quenten,

Thanks a lot for your quick response on this post! We totally understand your point about “changing things” in symfony 1.2 – that’s what keep us in hanging state as well.

Good luck!

And now 1.3 is out but is only supported for a few months, then 1.4 will be out with a year’s support. Seems to me the frame work is growing faster then the community can support it. Even today the plugins for 1.2 are lacking compared to 1.0. At this point when I do have time again to get back to OE, I am not sure the direction I want to take.
1. Stick with symfony and the painful form frame work
2. Use on parts of symfony now that it is un-couppled
3. Switch to Zend or CakePHP (when it hits 2.0)
4. I am teaching myself python, so I could go that route as well, however it looks to be even more painful of an install for an end-user.

It’s interesting discussing (and I guess there cant be always simple answer). But I’d add one more option here:

5. Stick with symfony 1.0.x – it’s the most stable / supported version

It’s a great find actually. I’m about to embark on a ‘recipe’ project (Symfony based) for a client.

I’ve been using 1.0.x so far for all my projects as it’s been fairly rock solid for me.

And Quenten is right, the plugin support is one reason I stick with the older releases.

Quenten, I think they’ve improved the form framework stuff in later releases, and I suspect the biggest move will be from the current 1.0.x upwards. Moving between the newer versions will be less of a hassle. So, even if you do it for 1.3, I suspect 1.4 will not be a huge task in itself.

Also, being open source, I’m sure someone (like me!) could step in and help!

Leave a Reply

Your email address will not be published. Required fields are marked *