It would seem not :) I was unable to get a behavior whose class is in the project "lib" folder to work with the propel:build-model task without including it in the propel.ini. Have you tried this?
On Nov 23, 11:13 am, Francois Zaninotto <[email protected]> wrote: > Hi Crafty_Shadow, > > > However, the fact that these behaviors are now not applied in runtime > > but instead in the generation stage means that they have to be defined > > in propel's build properties (config/propel.ini for symfony). > > This is not entirely true. If your behavior class is the camelCase version > of the behavior name (e.g. 'nested_set' => 'NestedSetBehavior', and if you > are able to autoload this class during the generation stage, Propel will be > smart enough to use it. That means that you don't need to the behavior class > path to the propel.ini. > > That being said, I think it's a good practice to keep a list of the > behaviors you use in your models. > > > bundling it in a plugin becomes crumblesome > > I love the idea of mixing web development and cooking ;) > > François > > 2009/11/23 Crafty_Shadow <[email protected]> > > > With the release of Propel 1.4, behaviors were introduced. Those > > differ from the previous implementation of behaviors in symfony by the > > fact that they are executed at the generation stage, and directly > > change the OM code (as opposed to the sfMixins implementation in > > symfony 1.0-1.2 > > > For more information on Propel behaviors: > >http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4/Behaviors > > > However, the fact that these behaviors are now not applied in runtime > > but instead in the generation stage means that they have to be defined > > in propel's build properties (config/propel.ini for symfony). > > Example definition: > > propel.behavior.sf_guard_authored.class = > > lib.propel_behaviors.sfGuardProfileAuthoredBehavior > > (I wrote a propel behavior implementation of > >http://www.symfony-project.org/plugins/sfGuardPropelAuthoredBehaviorP... > > ) > > > In other words, to activate a Propel behavior one has to change > > propel.ini, thus bundling it in a plugin becomes crumblesome (not all > > users read the plugin documentation very carefully ;). Shouldn't > > symfony facilitate a way to do this with plugin:install? > > > -- > > > You received this message because you are subscribed to the Google Groups > > "symfony developers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<symfony-devs%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/symfony-devs?hl=. > > -- You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=.
