Replaces symfony's core Propel plugin by the latest version of Propel, in branch 1.6.
Add the require to your composer.json. It's oddly named but like this Composer's symfony1 installer camelcases it correctly. Composer will install it into your project's plugins directory automatically, and add the requirements.
{
"config": {
"vendor-dir": "lib/vendor"
},
"require": {
"propel/sf-propel-o-r-m-plugin": "dev-master"
}
}
Of course, don't forget to add Composer's autoloader to your ProjectConfiguration:
// config/ProjectConfiguration.class.php
require __DIR__ .'/../lib/vendor/autoload.php';
require_once dirname(__FILE__) .'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
$this->enablePlugins(array(
'sfPropelORMPlugin',
...
));
// mandatory because of the Composer vendor directory naming scheme
sfConfig::set('sf_phing_path', sfConfig::get('sf_lib_dir') .'/vendor/phing/phing');
sfConfig::set('sf_propel_path', sfConfig::get('sf_lib_dir') .'/vendor/propel/propel1');
}
}Clone the plugin from Github:
git clone https://github.com/propelorm/sfPropelORMPlugin.git plugins/sfPropelORMPlugin
cd plugins/sfPropelORMPlugin
git submodule update --init
If you use Git as a VCS for your project, it should be better to add the plugin as a submodule:
git submodule add https://github.com/propelorm/sfPropelORMPlugin.git plugins/sfPropelORMPlugin
git submodule update --init --recursive
As both Phing and Propel libraries are bundled with the plugin, you have to initialize submodules for the plugin.
Install the plugin via the subversion repository:
svn checkout https://github.com/propelorm/sfPropelORMPlugin/trunk plugins/sfPropelORMPlugin
Install Phing and Propel:
svn checkout http://phing.mirror.svn.symfony-project.com/tags/2.3.3/classes/phing lib/vendor/phing
svn checkout https://github.com/propelorm/Propel/tags/1.6.5 lib/vendor/propel
Disable the core Propel plugin and enable the sfPropelORMPlugin instead. Also, change the location for
the Propel and Phing libs.
// config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
//setup the location for our phing and propel libs
sfConfig::set('sf_phing_path', sfConfig::get('sf_root_dir').'/plugins/sfPropelORMPlugin/lib/vendor/phing/');
sfConfig::set('sf_propel_path', sfConfig::get('sf_root_dir').'/plugins/sfPropelORMPlugin/lib/vendor/propel/');
sfConfig::set('sf_propel_generator_path', sfConfig::get('sf_root_dir').'/plugins/sfPropelORMPlugin/lib/vendor/propel/generator/lib/');
$this->enablePlugins('sfPropelORMPlugin');
}
}Optional: update references to the propel and phing folders in the test project.
// plugins/sfPropelORMPlugin/test/functional/fixtures/config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
$this->enablePlugins(array('sfPropelORMPlugin'));
$this->setPluginPath('sfPropelORMPlugin', realpath(dirname(__FILE__) . '/../../../..'));
// SVN way
//sfConfig::set('sf_propel_path', SF_DIR.'/../lib/vendor/propel');
//sfConfig::set('sf_phing_path', SF_DIR.'/../lib/vendor/phing');
// Git way
sfConfig::set('sf_propel_path', realpath(dirname(__FILE__) . '/../../../../lib/vendor/propel'));
sfConfig::set('sf_phing_path', realpath(dirname(__FILE__) . '/../../../../lib/vendor/phing'));
}Right after the installation of the plugin, you should update plugin assets:
php symfony plugin:publish-assets
Change the path of the symfony behaviors in the config/propel.ini file of your project:
// config/propel.ini
propel.behavior.symfony.class = plugins.sfPropelORMPlugin.lib.behavior.SfPropelBehaviorSymfony
propel.behavior.symfony_i18n.class = plugins.sfPropelORMPlugin.lib.behavior.SfPropelBehaviorI18n
propel.behavior.symfony_i18n_translation.class = plugins.sfPropelORMPlugin.lib.behavior.SfPropelBehaviorI18nTranslation
propel.behavior.symfony_behaviors.class = plugins.sfPropelORMPlugin.lib.behavior.SfPropelBehaviorSymfonyBehaviors
propel.behavior.symfony_timestampable.class = plugins.sfPropelORMPlugin.lib.behavior.SfPropelBehaviorTimestampable(Re)Build the model:
php symfony propel:build --all-classes
Propel 1.6 is a backwards compatible evolution of Propel 1.4 (the version bundled with symfony 1.3 and 1.4), which adds some very interesting features. Among these features, you will find the new Propel Query API, which is essentially a Criteria on steroids:
// find the 10 latest books published by authror 'Leo'
$books = BookQuery::create()
->useAuthorQuery()
->filterByFirstName('Leo')
->endUse()
->orderByPublishedAt('desc')
->limit(10)
->find($con);Propel 1.6 also supports many-to-many relationships, collections, on-demand hydration, new core behaviors (see below), better Oracle support, and is now licensed under the MIT license.
Propel 1.6 bundles most common behaviors in a new, robust buildtime implementation. These core behaviors provide faster runtime execution and the ability to modify the data model:
- timestampable
- sluggable
- soft_delete
- nested_set
- sortable
- concrete_inheritance
- query_cache
- alternative_coding_standards
- auto_add_pk
sfPropelORMPlugin allows you to register core propel behaviors right from your schema.yml. For instance, to create a tree structure from a Section model:
propel:
section:
_attributes: { phpName: Section }
_propel_behaviors:
- nested_set
id: ~
title: { type: varchar(100), required: true primaryString: true }Tip: Check the doc/schema.md file in this plugin source code for a complete reference of the YAML schema format.
You can also register a behavior for all your models right in the propel.ini configuration file. sfPropelORMPlugin already enables the symfony and symfony_i18n behaviors to support symfony's behavior system and model localization features, but you can easily add your owns:
propel.behavior.default = symfony,symfony_i18n,alternative_coding_standards,auto_add_pkThe plugin comes bundled with a new admin generator theme named 'admin15'. This theme is backwards compatible with sfPropelPlugin's admin generator theme, and provides additional features based on the new Propel 1.6 query objects:
- Easy related objects hydration: You don't need to write custom
doSelectJoinXXX()methods to hydrate related objects. Thewithsetting is much more poxwerful that the previouspeer_methodandpeer_count_methodsettings, and much easier to use. - Custom query methods: You can refine the query executed to display the list view by by setting the
query_methodsparameter. This allows to hydrate an additional column wit hno additional query, or to pre-filter the list to hide rows that the user shouldn't see. - All columns are sortable: Virtual columns and foreign key columns are now sortable in the list view. You'll need to set the sort method to use for that, but it's a one-liner. No more lists with column headers that can't be clicked for sorting!
- Easy links to filtered lists: A link to a fitlered list view is very easy to write with the new theme. Just add GET parameter, the same way you used to do with the admin generator in symfony 1.2, and it works
- Links to another admin module: To make a foreign key column link to the edit view of the related object in another module, you no longer need to create a partial. Just define the
link_modulesetting in the foreign key field configuration, and you're good to go: - Easy custom filters: Adding custom filters becomes very easy once you can take advantage of the generated Propel query classes. This allows your, for instance, to setup a full-text search input in two minutes, replacing many text filters by a single one for better usability.
- Automatic sortable links: If a module is generated on a model with sortable behavior, actions for moving records up and down are automatically added.
- YAML widget customization: The
generator.ymlformat was extended to allow widget and validator customization directly in YAML, without the need to edit a form object. You can also safely omit a field from adisplaylist in a form definition, without any risk to loose data. - Plain text field: If you want to display some data in a form without allowing the user to edit it, use the
type: plainattribute, just like in the old days of symfony 1.2. This is very useful for columns managed by the model, likecreated_atandupdated_atcolumns.
The new options for the admin15 generator theme are fully documented, and illustrated by real life examples, in the doc/admin_generator.md file in this plugin source code.
- Updated
sfWidgetFormPropelChoicewidget: The widget now uses the new Query API. You can customize the list of choices more easily by executing custom query methods, using the newquery_methodsoption. - Updated Propel validators: Both the
sfValidatorPropelChoiceand thesfValidatorPropelUniquewere updated to use the new PropelQuery objects, and to accept aquery_methodsoption similar to the one ofsfWidgetFormPropelChoice. - Plain text widget and validator: This new widget allows a field to be displayed in a form, without letting the use change it.
- Easy Relation Embed: Editing related objects together with the main objects (e.g., editing
Commentsin aPostform) is a piece of cake. The newsfFormPropel::embedRelation()method does all the work to fetch related objects, build the forms for each of them, and embed the related object forms into the main form. Embdeded relation forms allow to edit, add, and delete a related objects with no additional code.
class ArticleForm extends BaseArticleForm
{
public function configure()
{
$this->embedRelation('Book');
}
}The Propel widgets, validators, and form classes are fully documented in the doc/form.md file in this plugin source code.
You now can merge or embed filters into filters, it works out of the box.
class ArticleFilter extends BaseArticleFilter
{
public function configure()
{
$this->mergeForm(new AuthorFilter());
}
}The plugin offer two new routing classes, sfPropelORMRoute and sfPropelORMRouteCollection. These classes are used by default in the models build with the propel admin generator. They behave just like the previous sfPropelRoute class - except they don't use the methods option anymore. Instead, use the query_methods option to execute a list of arbitrary query methods when calling getObject() and getObjects().
author:
class: sfPropelORMRouteCollection
options:
model: author
module: author
prefix_path: /author
column: id
query_methods:
object: [filterByIsPublished]
list: [filterByIsPublished, orderByLastName]
with_wildcard_routes: trueArray of additional parameters are also possible for query_methods:
author:
class: sfPropelORMRouteCollection
options:
model: author
module: author
prefix_path: /author
column: id
query_methods:
object:
filterByIsPublished: [false]
list:
filterByIsPublished: []
orderBy: [LastName]
with_wildcard_routes: truesfPropelORMRoute also makes your code a little easier to read in the action. Instead of calling getObject(), you can actually call a getter using the class name of the object's route:
public function executeShow(sfWebRequest $request)
{
// using sfPropelORMRoute with 'Author' as model
$this->author = $this->getRoute()->getAuthor();
}A new option has been added to both sfPropelORMRoute and sfPropelORMRouteCollection, the connection option allows to set a specific Propel connection to use.
Examples:
author_show:
url: /author/:id
class: sfPropelORMRoute
param: { module: myModule, action: show }
options: { model: Author, type: object, connection: my_connection }author:
class: sfPropelORMRouteCollection
options:
model: Author
module: author
prefix_path: /author
column: id
connection: my_connection
with_wildcard_routes: true
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent