Admin Generator compatible with Propel and Doctrine
Just a quick note to mention a recent addition I made to the sfPropelFinderPlugin. It now features an admin generator theme, identical in functionality to the Propel and Doctrine admin generators, except… It uses DbFinder queries instead of Criteria or Doctrine_Query calls. See more in the Generator README file.
This has two implications:
- Modules based on this generator are easier to customize, especially if you need to override methods of the action class. Instead of dealing with complicated
Criterionconditions, you manipulate finder objects, with all the ease of use it implies. - Modules based on this generator are ORM agnostic, meaning they work both with Propel and Doctrine (actually, this is not entirely true, since
sfDoctrineFinderdoesn’t implement all the features required by theDbFindergenerator yet… but it will soon be true).
It makes the writing of ORM-agnostic plugins possible, especially for plugins like sfSimpleCMSPlugin or sfSimpleBlogPlugin who feature backend modules generated by symfony.
That’s decided, the next version of the plugins I maintain will use DbFinder!
Possibly related posts (automatically generated):
Great, I think this approach just needed a leader who shows it’s advantages. I dont know if it is a stupid question (i havent read about the roadmap of administration on sf1.2) so do you think this approach will work with the next administration stuff
After my graduation (mid-september) I will start implementing the sfPropelFinderPlugin in the ExtJS Theme as well!
But I hope it will be used in the new adminGenerator for 1.2 as well! So I can extend that generator for the ExtJS theme: http://www.symfony-project.org/plugins/sfExtjsThemePlugin
Sorry, but i don’t like this approach. We dont need more layers, we need less. Every additional layer increases the possibility of a bug and makes it harder to understand for a newbie. Doctrine will be the default ORM for symfony 1.2 and people will switch over time. its just the better approach to ORM and it will replace Propel, even in plugin development.
@cynova: In the past Doctrine was not supported very well. There are only a few plugins that work with Doctrine. The problem is: You need to develop and maintain two plugins just to support the two ORMs. The DbFinder allows to have one plugin working with both, Propel and Doctrine.
I don’t think that Propel will completely disappear in the symfony community. Things will probably change in that whay that Propel has similar support as it is currently the case with Doctrine. In fact I think both ORMs will have similar level in the future, but it may change as Doctrine is more feature rich and more flexible for example for a cool new admin generator…
The DbFinder plugin is something that slows down the discussions about what ORM is better to use (at least in a plugin): Simply use the DbFinder and let people choose there favorite ORM in their project.
So.. thumbs up and thanks for this very helpful plugin!
@cynova: If you speak about newbies, they don’t need to understand how the framework works in the inside (or else it would take years to use symfony), they need to understand how to use the framework. For that, all they need is a simple API, and sfPropelFinder is simpler than Propel Criteria.
And you seem to know all about the future of symfony and what the users will do. I, for one, will not switch to Doctrine as long as it’s slow, unfinished, buggy and has no plugins. Allow me to believe that they are people like me (just like you believe that all symfony developers are like you).
“(I) will not switch to Doctrine as long as it’s slow, unfinished, buggy and has no plugins”
Well, that’s a personal opinion. I’ve developed major applications with both ORMs, and I wouldn’t say Doctrine is the most buggy one.
Concerning the plugins, as Doctrine embeds most of the Propel “behaviour” plugins as default in its template system, I would say it’s an unfair comparison (and for those which are not built-in, it’s often so trivial to implement that it would be a no brainer to make a plugin out of it).
For the slowness, all my tests on similarly weighted DBs haven’t led to the same conclusion. Let’s recall to the newbies that Doctrine was built from scratch on top of PDO extension, the same that Propel turned out to use to finally manage to spare a few seconds per request in the 1.3 version.
In spite of that, I do believe your project is good news for the community, especially for plugins that rely a lot on the model layer.
Honestly I don’t like the *Finder Plugins.
I mean, one of the reasons I use something like Propel is that it gives me the opportunity to “forget” SQL and use a simplier interface. Your plugins (that by the way, I really appreciate), like doctrine, bring me back to sql like instructions. And I don’t like this!
For example, look a Active Record: in my opinion, its best feature is its ease of use. Even a low level programmer can understand it and simply use it.
Propel still lacks something (for example the boring thing about Criteria), but it is more developer friendly that Doctrine, o your Plugins.
By the way I think every good programmer MUST know SQL..:)
@Cedric: I don’t want to say “this ORM is the best”. My personal favorite is Propel, and for a lot of reasons. My point is: use the ORM you prefer, and if you want to publish a plugin, I advise you to make it ORM agnostic so that you don’t get only half of the possible user base. And if you want your plugin to be ORM agnostic, then sfPropelFinderPlugin is a reasonnably good solution.
@lloyd27: You are being contradictory. You don’t like Criteria but you think that sfPropelFinder is less developer friendly? You prefer ActiveRecord, and sfPropelFinder is the closest thing to ActiveRecord in PHP? Did you actually take a look at the plugin before voicing your opinion?
Yes, I did..:)
Let me explain my thoughts (and let me apology for my poor english..:D)
Personally, I don’t like neither Propel nor Doctrine. I use them only because they save me time of doing a normal SQL query. And that’s the point. I HATE SQL..:) I know it quite good but I really don’t like it!
Maybe it’s just a PHP lackness, but there is something in Doctrine and your Plugins that reminds me too much SQL.. I mean, even Propel could be so much better than it is, I think everybody used a Criteria (or worst, a Criterion) at least once deeply hates it..:)
Things like addAscendingOrderByColumn are simply ridicolous, no doubt.. But in some way it abstracts better from standard SQL syntax.
Now check this:
$articles = sfPropelFinder::from('Article')-> where('Title', 'like', '%world')-> where('IsPublished', true)-> orderBy('CreatedAt')-> with('Category')-> find();If you substitute the word sfPropelFinder with “select *” in an instruction, you’ll notice that it simply looks like an SQL query.
I know Active Record receive benefits from fluent Ruby syntax, but there isn’t the possibility to implement its short and simply interface in some PHP ORM?
Maybe it’s just a PHP fault..:)
@lloyd27: Try to google ‘Late Static Binding PHP’ and you will understand why a true ActiveRecord implementation is not possible in PHP.
It should become possible in PHP 5.3, though.
Yes I heard about it, but I actually don’t know how active record really works, so i just asked..:)