On 31.12.2009, at 01:35, Stéphane wrote:

> Check for symfony core events (about configuration loaded or such thing I 
> think -feeling), then you'll be able to modify tables definitions (retrieve 
> table object then addColumn "dynamically", not via configuration). That is 
> what Daniel was speaking about I believe.

right. i can then just as well modify the model itself, which imho is a lot 
cleaner and logical.
however i would much rather have this all done inside the projects schema.yml 
file.

for example i define a few standard behaviors inside my schema.yml file, which 
i can reuse via the merge key alias inside my schema.yml file [1]:
actAs: &actAs
  Timestampable: ~
  Blameable: &Blameable
    default: null
    blameVar: user_id
    listener: BlameableCustomListener
    columns:
      created:
        name: author_id
        length: 4
      updated:
        disabled: true
    relations:
      created:
        class: sfGuardUser
        disabled: false
        name: Author
  Versionable:
    actAs:
      Blameable:
        <<: *Blameable

now i have to duplicate this configuration into a model [2]:
        $blameable0 = new Doctrine_Template_Blameable(array(
             'default' => NULL,
             'blameVar' => 'user_id',
             'listener' => 'BlameableCustomListener',
             'columns' =>
             array(
              'created' =>
              array(
              'name' => 'author_id',
              'length' => 4,
              'options' =>
              array(
                'notnull' => false,
              )
              ),
              'updated' =>
              array(
              'disabled' => true,
              ),
             ),
             'relations' =>
             array(
              'created' =>
              array(
              'class' => 'sfGuardUser',
              'disabled' => false,
              'name' => 'Author',
              ),
             ),
             ));
        $this->actAs($blameable0);

i think we can all agree that this situation isnt ideal. at the same time there 
is a somewhat clean work around, so it also not the end of the world. well 
there i start hitting a wall however is if for example i would rather use a 
bigint (*) for the id column in sfDoctrineGuard as its currently hardcoded to 
be a normal interger [3]:

sfGuardUser:
  actAs: [Timestampable]
    columns:
      id:
        type: integer(4)
        primary: true
        autoincrement: true

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

(*) yes i know that i dont need bigints here, but i am lazy and want to keep 
the id types consistent in my application and so this means i also need to 
hardcode the id columns explicitly, since if i leave them out doctrine 
automatically adds them as a bitint

[1] 
http://code.google.com/p/uninformed/source/browse/trunk/config/doctrine/schema.yml
[2] 
http://code.google.com/p/uninformed/source/browse/trunk/lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php
[3] 
http://trac.symfony-project.org/browser/plugins/sfDoctrineGuardPlugin/branches/1.3/config/doctrine/schema.yml

--

You received this message because you are subscribed to the Google Groups 
"symfony users" group.
To post to this group, send email to symfony-us...@googlegroups.com.
To unsubscribe from this group, send email to 
symfony-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/symfony-users?hl=en.


Reply via email to