sfPropelFinder is like jQuery for Propel
Are you tired of writing long Criteria definitions for simple queries? Do you sometimes wish that symfony had an ActiveRecord (even if it is not really possible in PHP5 as of now)? Do you feel that the world of Javascript has changed since jQuery came up? Do you like the way sfFinder and sfTestBrowser work?
Then take a look at this:
// With Peer and Criteria
$c = new Criteria()
$c->add(ArticlePeer::TITLE, '%world', Criteria::LIKE);
$c->add(ArticlePeer::IS_PUBLISHED, true);
$c->addAscendingOrderByColumn(ArticlePeer::CREATED_AT);
$articles = ArticlePeer::doSelect($c);
// with sfPropelFinder
$articles = sfPropelFinder::from('Article')->
whereTitle('like', '%world')->
whereIsPublished(true)->
orderByCreatedAt()->
find();
$c = new Criteria()
$c->add(ArticlePeer::TITLE, '%world', Criteria::LIKE);
$c->add(ArticlePeer::IS_PUBLISHED, true);
$c->addAscendingOrderByColumn(ArticlePeer::CREATED_AT);
$articles = ArticlePeer::doSelect($c);
// with sfPropelFinder
$articles = sfPropelFinder::from('Article')->
whereTitle('like', '%world')->
whereIsPublished(true)->
orderByCreatedAt()->
find();
This example shows the philosophy of a new symfony plugin I just commited. Check it out if you're interested.
Possibly related posts (automatically generated):
Brilliant!! great work! Thank you.
Wow amazing!! I have waited for a thing like this and like active record(coming from rails) here in symfony!! In the next versions i would implement the OR keyword between where clauses also. And of course joins
Anyway great work i will try it 
Very nice
It's only a matter of taste, although the with sfPropelFinder you write less code.
If this had existed a year ago I might not have gone through the pain of switching to Doctrine.
This syntax looks a bit like Doctrine's approach to building queries using method chaining, which I quite like. Ironically, the Doctrine folks are talking about introducing a Criteria-like object to handle the most complex of query-building problems. Maybe in a couple years the projects will be so similar they will just merge: Doctrel? Propine?
I DO love jQuery! I especially like that this approach allows you to chain the request into just one line of code. I look forward to diving into it.
Are there any major dependencies that would make it difficult to get working on sf 1.1 with Propel 1.3?
Yet another great plugin from Francois! Thanks, this makes propel painless.
Looks very great and useful, congrats. But just one thought: why didn't you submit a patch for sfPropelImpersonatorPlugin?
@NiKo: I guess the two plugins should merge, I agree, but I didn't make contact with Romain yet.
Good job François
Very exciting work. Thank you Francois.
It looks very nice, and is only a couple of hundred lines of code which wrap existing functionality in propel - so no needless bloat which is nice.
I’d like to point out that doctrine does more then just provide a nicer way of doing queries though. Inheritence for one….
This is a great step in the right direction for Propel, don’t don’t be fooled into thinking suddently doctrine is pointless
Yes, a merge with sfPropelImpersonator is a very good idea, since yesterday I also refactored relations in their own classes, so the population/relation fetching is less magic and more atomic.
I'll have a look soon on how this could be possible, the idea should remain being able to use only the components we need for a given task. As we were talking about morning, no need to use PropelImpersonator for simple selects, but sfPropelFinder could switch automatically to use it if relations are out of propel's scope.
But then, I'm starting to think again that peer classes are very badly designed. Thoose magics static i-resolve-the-three-cases-you-ll-not-often-use classes could maybe then replaced by Finder classes, ie ArticleFinder would replace Criteria and Peer class at the same time.
I will, if i find some time for it, try to benchmark ArticlePeer::doSelect(new Criteria()) vs { $peer = new sfPropelObjectPeerImpersonator('Article'); $peer->doSelect(new Criteria()); }
If the difference is not very significant, peer classes could be thrown away?
Well maybe i'm just dreaming :p
ps: btw, I don't know how Propel 1.3 makes this evolve. Is there better solutions for relations and queries yet?
and ps2: i agree pookey, sfPopi, as I like to call it, was just initially started as a hack to make propel projects optimisation less painfull. Still I'm a big fan of doctrine, and I very much hope that the recent evolution in the seriousness of feature-release relation will help doctrine to be enterprise ready very soon.
yu'r right guy !
to be continued !
Very good work Francois! Thank you for your time spent to increase the power of Symfony
Waiting for joins in your plugin
@FX: Are you kidding? I just added them this afternoon...
François, many thanks for this contribution. Needless to say you should ignore apparently ungrateful individuals such as FX - some people want everything for free and done for them yesterday
Well, when I saw the plugin page (on sf trac) - joins were in the todo.
I've already seen that you'd added them.
PS. I gorgot something... Thanks for your plugin!
simply amazing !!! thanks for the contribution
thanks for the plugin.
why do you have a method findOne when it could easily be written with find(1)
also a innerJoin/outerJoin/leftJoin/rightJoin is missing..
what about selecting records using a aggregate function, something like MAX('id')
@Markus:
Hi Francois,
you should comment the difference of find(1) and findOne() in the readme...
Thanks, Markus
Great job, it's really useful
one note: updateLatestQuery() can only work when Propel::getConnection() returns sfDebugConnection (generally in dev environment), PgSQLConnection/MySQLConnection don't have this method...
Does that work with i18n enabled?
[...] sfPropelFinder is like jQuery for Propel [...]