symfony developers Google Group

Re: How should one go about bundling a Propel 1.4 behavior in a plugin

vankat...@gmail.com (Crafty_Shadow) — Mon, 23 Nov 2009 18:58:33 UT

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?

Re: [symfony-devs] Re: The configuration files in symfony 1.3/1.4

fabien.potenc...@symfony-project.com (Fabien Potencier) — Mon, 23 Nov 2009 15:13:55 UT

Done

[link]

Fabien

--
Fabien Potencier
Sensio CEO - symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

fabien.potenc...@symfony-project.com (Fabien Potencier) — Mon, 23 Nov 2009 15:13:11 UT

done, thanks

Fabien

--
Fabien Potencier
Sensio CEO - symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

t...@punkave.com (Tom Boutell) — Mon, 23 Nov 2009 15:07:34 UT

Thank you Fabien I think this is what is needed. I suggest tweaking
the language a little...

"`sfCompat10Plugin` and `sfProtoculousPlugin` have been removed from
1.4. If you are explicitly disabling them in your project's
configuration class files, such as
config/ProjectConfiguration.cl ass.php, you must remove all mention of

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

fabien.potenc...@symfony-project.com (Fabien Potencier) — Mon, 23 Nov 2009 15:02:06 UT

I have updated the information:

[link]

Tell me if it's enough or not.

Fabien

--
Fabien Potencier
Sensio CEO - symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

thomas.rab...@gmail.com (Thomas Rabaix) — Mon, 23 Nov 2009 14:49:48 UT

Yes, I read too quickly your email !

--
Thomas Rabaix
[link]

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

t...@punkave.com (Tom Boutell) — Mon, 23 Nov 2009 14:48:44 UT

(I should say that following the process in that page doesn't work if
you have 1.4 installed. Maybe the right process is to upgrade to 1.3
first and then try switching to 1.4, but that page should be updated
to say so)

On Mon, Nov 23, 2009 at 7:03 AM, Kris Wallsmith

--
Tom Boutell
P'unk Avenue

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

t...@punkave.com (Tom Boutell) — Mon, 23 Nov 2009 14:48:03 UT

Kris I see your ticket has been closed as a wontfix ticket.

I understand the reasoning alas...

What's needed most of all is useful information on this page:

[link]

Right now it's just a copy of the 1.3 upgrade instructions, and
following that process doesn't work.

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

t...@punkave.com (Tom Boutell) — Mon, 23 Nov 2009 14:43:07 UT

Whoops, I meant to delete that incomplete sentence.

What I'm saying here is that devs who are following common examples of
the right way to start a 1.2 app with no 1.0 dependencies probably
shouldn't get an error when they run that under the next release,
since they are trying to follow the recommended path for forwards

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

t...@punkave.com (Tom Boutell) — Mon, 23 Nov 2009 14:41:18 UT

Thomas, I am not using it, I am *disabling* it following the usual
pattern to make sure I'm *not* using it. That's the "right" thing to
do, so it doesn't make sense for that to blow up when one upgrades to
a newer version.

But since 1.4 doesn't *have* an ugprade task I'm not s

--
Tom Boutell

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

kris.wallsm...@symfony-project.com (Kris Wallsmith) — Mon, 23 Nov 2009 12:03:02 UT

I've added this ticket:
[link]

Thanks Tom,
Kris

Kris Wallsmith | Release Manager
kris.wallsm...@symfony-project .com
Portland, Oregon USA

[link]

Re: [symfony-devs] Attempted upgrade to 1.4, notes so far

thomas.rab...@gmail.com (Thomas Rabaix) — Mon, 23 Nov 2009 11:48:48 UT

The sf1.4 branch will remove all dependencies to 1.0.X series ... so sfCompat10Plugin does not make any sense with sf1.4. You can use sf1.3 then.

Re: [symfony-devs] How should one go about bundling a Propel 1.4 behavior in a plugin

fzanino...@gmail.com (Francois Zaninotto) — Mon, 23 Nov 2009 09:13:56 UT

Hi Crafty_Shadow,

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

How should one go about bundling a Propel 1.4 behavior in a plugin

vankat...@gmail.com (Crafty_Shadow) — Mon, 23 Nov 2009 08:28:27 UT

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:

Re: The configuration files in symfony 1.3/1.4

vankat...@gmail.com (Crafty_Shadow) — Mon, 23 Nov 2009 08:08:12 UT

Yes, having 2-3 sentances describing the purpose of the particular
config file (for users new to symfony) plus a link to the reference
guide seems to be the best option.
+1