You need to inject the EntityManager into the constructor of your form type
class.
// in controller
$em = $this->get('doctrine')->getEntityManager();
$form = $this->get('form.factory')->create(new MyFormType($em));
// form type class
class MyFormType extends AbstractType
{
private $em;
Salut,
Par défaut, Doctrine attribue le champ "id" comme clé primaire, mais
rien ne t'empêche de définir explicitement un autre champ comme clé
primaire de ta table. Toutes les informations nécessaires se trouvent
dans la documentation de Doctrine sur le site officiel :
http://www.doctrine-projec
I use Propel 1.3 rev701 standalone in an none symfony project and i
like it so much better than 1.2.
However, the nested set support has still some bugs, but the rest
works very fine.
I decided against doctrine because of the lack of stability.
I didn't tested Propel 1.3 with symfony, but i w
The only problem I've experienced with Propel 1.3 and MySQL is the
DateTime object used for Time/Date/Datetime fields. It doesn't work
right now, but you can write your own workaround for that fields.
All over all, Propel 1.3 seems very stable to me. Nothing to rewrite
but the nested set things (
Pierre wrote:
> Yeah, Doctrine is THE upcoming KILLER ORM, and I would switch to it
> every time ... if it would be stable like Propel (Doctrine and
> sfDoctrinePlugin).
>
> Until that, I use the sfPropel13Plugin. It is ways faster than the
> Creole/Propel 1.2 combination and I benefit of some opt
Yeah, Doctrine is THE upcoming KILLER ORM, and I would switch to it
every time ... if it would be stable like Propel (Doctrine and
sfDoctrinePlugin).
Until that, I use the sfPropel13Plugin. It is ways faster than the
Creole/Propel 1.2 combination and I benefit of some optimazations,
e.g. the Nest
As most od the people in this thread states, Doctrine is
more advanced and flexible than Propel, but i don't recomend
switching to Doctrine yet, especialy on large projects.
I had some serious issues with Doctrine on a large projects with
realy big databases, specialy with relations between table
Eno schrieb:
> On Oct 2, 10:14 am, Matthias Nothhaft <[EMAIL PROTECTED]> wrote:
>
>> Furthermore Doctrine is able to hydrate arrays instead of objects. This
>> saves memory and speeds up your application.
>
> Ive been writing model methods to emulate stuff like this so this
> sounds very cool.
>
On Oct 2, 10:14 am, Matthias Nothhaft <[EMAIL PROTECTED]> wrote:
> Furthermore Doctrine is able to hydrate arrays instead of objects. This
> saves memory and speeds up your application.
Ive been writing model methods to emulate stuff like this so this
sounds very cool.
Would you describe Doctri
Charley Tiggs wrote:
> Thanks Matthias. Much appreciated. Last question: How difficult is it
> to move existing code from Propel to Doctrine?
You can't directly move from one to the other.
So, it depends how much code you have :)
You could argue that most time is spent working out the logic
Charley Tiggs schrieb:
> Matthias Nothhaft wrote:
>> Charley Tiggs schrieb:
>>> What I'm trying to do is justify to my team members the need to switch
>>> to Doctrine and spend the extra development time (read client's money)
>>> towards Doctrine.
>> Doctrine offers additional features you will
Matthias Nothhaft wrote:
> Charley Tiggs schrieb:
>> What I'm trying to do is justify to my team members the need to switch
>> to Doctrine and spend the extra development time (read client's money)
>> towards Doctrine.
>
> Doctrine offers additional features you will not (maybe never) find in
>
Charley Tiggs schrieb:
> Ian P. Christian wrote:
>> Charley Tiggs wrote:
>>> Ian P. Christian wrote:
> 2) When using Propel now will there be a way to update to Doctrine in
> the future when it has become more stable?
Very unlikely, they use different concepts. Propel is focuses aro
Ian P. Christian wrote:
> Charley Tiggs wrote:
>>
>> Ian P. Christian wrote:
2) When using Propel now will there be a way to update to Doctrine in
the future when it has become more stable?
>>> Very unlikely, they use different concepts. Propel is focuses around a
>>> Criteria object f
Charley Tiggs wrote:
>
>
> Ian P. Christian wrote:
>>> 2) When using Propel now will there be a way to update to Doctrine in
>>> the future when it has become more stable?
>> Very unlikely, they use different concepts. Propel is focuses around a
>> Criteria object for selecting, doctrine is no
Charley Tiggs wrote:
> Can you expand on this a little bit? Can you expand on why you use
> sfDoctrine instead of sfPropel?
>
> So far, I've found little data that objectively compares the two. As a
> new user, I'm just trying to figure out if sfDoctrine is better for my
> current project o
Ian P. Christian wrote:
>> 2) When using Propel now will there be a way to update to Doctrine in
>> the future when it has become more stable?
>
> Very unlikely, they use different concepts. Propel is focuses around a
> Criteria object for selecting, doctrine is not.
Ian,
Can you expand on
Bjorn Wijers wrote:
> 1) Which ORM system should I use when I want to have a fully functional
> system in production within the next three months?
Very much a personal preference. Personally, I've used both, and use
doctrine. I advise you try both (as I know you are doing).
sfDoctrinePlugin
18 matches
Mail list logo
