Let me guess... You're on a Windows Platform, aren't you? If so, please open a ticket about your issue, I now see where it comes from.
Cheers, Francois Le 23 nov. 2009 à 19:58, Crafty_Shadow <[email protected]> a écrit : > 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= > . > > -- 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=en.
