Propel

Markus Staab (@markusstaab) is now a Propel core developer. He will continue his great work on Propel 1.6, and Propel2. Welcome on board Markus! Permalink | Leave a comment  »

As announced on Twitter, Marc J. Schmidt is now a Propel core developer. He will continue his great work on Propel 1.6, and Propel2. Welcome on board Marc! Permalink | Leave a comment  »

Propel 1.6.8 is now available, and it's the fifth bug fixes only release. The release is available on GitHub under the 1.6.8 tag on GitHub, as PEAR package (runtime & generator), as archives (ZIP and TAR), and also available ... [More] through Composer: propel/propel1. As usual, the API documentation is at: http://api.propelorm.org/, and here is the huge CHANGELOG. Thanks to all contributors.   Permalink | Leave a comment  » [Less]

Last week, Propel2 got some love! Propel2 adopted PSR-3, the one that defines a Logger Interface. Also, we started to work on PEER classes thanks to Jérémie. It's the last thing to do before an alpha release. It's quite complicated, but once it ... [More] will be done, we will be able to decouple more things like the behaviours. Stay tuned! Permalink | Leave a comment  » [Less]

We wish you a happy new year and all the best for 2013! Quick news: Propel 1.6.8 will be released soon, and includes a lot of fixes and some new light-weight features. As you may noticed, the number of new versions is decreasing in order to ... [More] freeze all new developments on this project. Propel2 is not under heavy development right now, but we are close to the end, and we have new plans to make it awesome! The sfPropelORMPlugin is not actively maintained, mostly due to the symfony 1.x end of life. The Symfony2 PropelBundle is on its way, and everything seems ok. We are discussing the need for a Zend Framework 2 Module to integrate Propel in ZF. No decision has been made though. If you want to follow this discussion, subscribe to the Propel Mailing-List. Permalink | Leave a comment  » [Less]

The Propel documentation available at www.propelorm.org is down for some obscure reasons. We are working with GitHub to find a solution and to fix this major issue. In the meanwhile, the documentation is available at: http://jaugustin.github.com/. This mirror is up to date. Permalink | Leave a comment  »

Propel comes with a large set of behaviors but most of them are already well-known. However, we noticed that a lot of people didn't know about the awesome user contributions we have in the Propel community. In this series, we will introduce a new ... [More] user contributed Propel behavior each week. The GeocodableBehavior helps you build geo-aware applications by providing geocoding features to your ActiveRecord objects. It's also a wrapper for the powerful Geocoder library designed to solve geocoding problematics in PHP. The GeocodableBehavior provides new methods to both the ActiveRecord and the ActiveQuery APIs, and it works fine without Geocoder. Basically, adding this behavior to your XML schema will: add two new columns to your model: latitude and longitude; add four new methods to the ActiveRecord API: getDistanceTo(), isGeocoded(), getCoordinates(), and setCoordinates(); add two new methods to the ActiveQuery API: filterByDistanceFrom(), filterNear(). The getDistanceTo() method returns the distance between the current object and a given one. You can specify the measure unit: KILOMETERS_UNIT,MILES_UNIT, or NAUTICAL_MILES_UNIT. The filterByDistanceFrom() method adds a filter by distance on your current query and returns itself for fluid interface. This method is useful when you want to get results around a given position. The filterNear() is pretty much the same but takes a geocoded object instead of a position. 1 2 3 4 5 6 7 // Find the 5 nearest events from a given "event" (max 15 KM)$events = EventQuery::create()    ->filterByDistanceFrom($event->getLatitude(), $event->getLongitude(), 15)    ->limit(5)    ->find(); Then again, you get these methods for free, you just have to install the behavior and that's it. But this behavior is also a wrapper for the Geocoder library, so it does a lot more like automatic geocoding. There are two strategies: IP-address based, or Street-address based. The behavior guesses useful columns in your table in order to perform geocoding requests. Basically, the behavior looks for attributes called street, locality, region, postal code/zip code, and country. It tries to make a complete address with them. As usual, you can add your own list of attributes that represents a complete street address thanks to the address_columns parameter. By using Geocoder and the automatic geocoding feature, a new method will be available in the ActiveRecord API: geocode(). This method will be triggered on save or update, but you can disable the autofill on update thanks to the auto_update parameter. For more information, read the documentation about automatic geocoding and this blog post about Geocoder. This behavior is highly configurable and here is the reference configuration: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 name="geocodable">     name="auto_update" value="true" />     name="latitude_column" value="latitude" />     name="longitude_column" value="longitude" />         name="geocode_ip" value="false" />     name="ip_column" value="ip_address" />         name="geocode_address" value="false" />     name="address_columns" value="street,locality,region,postal_code,country" />         name="geocoder_provider" value="\Geocoder\Provider\YahooProvider" />     name="geocoder_adapter" value="\Geocoder\HttpAdapter\CurlHttpAdapter" />     name="geocoder_api_key" value="false" />     name="geocoder_api_key_provider" value="false" /> As you can see, you can configure Geocoder to fit your needs without any effort. This behavior is really flexible, and works with Propel 1.6.4 or higher. It is fully unit tested, and hosted on GitHub: willdurand/GeocodableBehavior. The Geocoder library is also hosted on GitHub: willdurand/Geocoder. Permalink | Leave a comment  » [Less]

A few months ago, I gave a talk about Propel2 at Symfony Live 2012 where I announced a first release scheduled for this summer. We are almost ready, and we've refactored more code than expected, so Propel2 is getting better each day. We could ... [More] actually release a version at the end of this month. We already have early adopters on Propel2, even if I recommend to wait the first release. They gave us very positive feedback but they still miss one of the best Propel2 features: the traits. Actually, everyone misses it, and here we learnt a very interesting fact: people wants to use PHP 5.4 new features. Following the discussion on the propel-development Mailing-List, we are glad to announce a major change for Propel2. Yes, Propel2 will require PHP 5.4, and will generate PHP 5.4 code. Both the core and the generated code will use PHP 5.4 killer features. Thing is, when will we be able to release Propel2 then? I'm quite confident here. Propel 1.6 works fine, and as I use to say, we don't need to release something early to replace Propel 1.6. Propel2 is a new project, based on Propel 1.6 and we plan a release before the end of this year. We will spend this time to refactor the core with PHP 5.4 features, so that there won't be any BC breaks after a first release. Propel 1.6 works with PHP 5.2.4 as well as with PHP 5.4, we want to do the same with Propel2, and that's also why we decided to use PHP 5.4 as the minimum requirement. Permalink | Leave a comment  » [Less]

Propel comes with a large set of behaviors but most of them are already well-known. However, we noticed that a lot of people didn't know about the awesome user contributions we have in the Propel community. In this series, we will introduce a new ... [More] user contributed Propel behavior each week. Ivan Tanev wrote a wonderful behavior named EqualNestBehavior to solve a common problem: relations between instances of a same class. The best example is probably a friendship relation between users/persons in your application. In a social networking world, it's a very common feature. The behavior provides all the methods you need to manage those relations: addFriend(), removeFriend(), getFriends(), setFriends(), hasFriend(). See the complete list of ActiveRecord's methods for more details. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 $john = new Person();$jean = new Person();$john->hasFriend($jean); // false$jean->hasFriend($john); // false$john->addFriend($jean);$john->hasFriend($jean); // true$jean->hasFriend($john); // true$jean->removeFriend($john);$john->hasFriend($jean); // false$jean->hasFriend($john); // false As usual, the ActiveQuery API has useful methods, too: you can either find or count friends for a given object. Under the hood, this behavior defines a new table to store relations. It's like a Many to Many relationship, but with the same table referenced twice. Using this behavior is super easy, just add it to your XML schema as following: 1 2 3 4 5 6 7 8 9 10 name="person">   name="id" required="true" primaryKey="true" autoIncrement="true" type="INTEGER" />   name="name" type="VARCHAR" required="true" /> name="friend">   name="equal_nest">     name="parent_table" value="person" />   The table name, friend, is important. It defines the relationship name, and everything is built around this name. This behavior is really flexible, and works with Propel 1.6 all versions. It is fully unit tested, and hosted on GitHub: CraftyShadow/EqualNestBehavior. Thanks for this great behavior Ivan! Permalink | Leave a comment  » [Less]

Don't Do This At Home #6: Repeat The Same Filter For All Queries Can you spot the problem in the following snippet? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ... [More] class ArticleQuery extends BaseArticleQuery{  public function published()  {    return $this->filterByIsPublishedAt(array('max' => time()));  }  public function filterByCategory($name)  {    return $this      ->published()      ->useCategoryQuery()        ->filterByName($name)      ->endUse();  }  public function popular($minViews = 1000)  {    return $this      ->published()      ->filterByNbViews(array('min' => $minViews));  }} The published() filter appears in all other filters. Ok, that was easy, it's the title of the post! But how to do it better? Why not create a specialized query class filtering on published artivcles by default? All the frontend controllers should use this FrontendArticleQuery instead of the more generic ArticleQuery. It would look like this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 class FrontendArticleQuery extends ArticleQuery{  public static function create($modelAlias = null, $criteria = null)  {    if ($criteria instanceof FrontendArticleQuery) {      return $criteria;    }    $query = new FrontendArticleQuery();    if (null !== $modelAlias) {      $query->setModelAlias($modelAlias);    }    if ($criteria instanceof Criteria) {      $query->mergeWith($criteria);    }    // this is new!    $query->published();    return $query;  }} This method can add more default filters (for instance, to restrict to articles linked to an author, articles arleady indexed by a search engine, etc.) Now, everytime you call FrontendArticleQuery::create(), you know you only retreive published articles. No need to add this filter to other filters anymore. Permalink | Leave a comment  » [Less]