The quick answer is : you already can customize all Doctrine classes - including plugin ones - as much as you want, but you have to do it in php, not in schema.yml.
Here is how symfony works with models, with the classic BlogPost sample : - First the schema.yml file is parsed and transformed the BlogPost config to an abstract BaseBlogPost.class.php class which contains model definitions methods: setTableDefinition() and setUp() - Then a BlogPost.class.php is created. BlogPost extends BaseBlogPost and this is the class that will be used to generate related form and filter classes. The trick is very simple: you just have to extend setTableDefinition() setUp() in the BlogPost class to modify everything you want. You can do everything you want : add, remove or modify options, fields and behavior, the modifications are reported to the related form. Of course it also works for plugins. If you want to customize the sfDoctrineGuardPlugin sfGuardUser class, just go in /lib/model/ doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php and extend setTableDefinition() and setUp() methods The questions is: should this feature be available through some kind of Yml file ? For me the answer is no, symfony advanced configuration operations should stay in pure Php, the same kind of choice has already be done for form customizations. But the sf documentation could maybe by improved on that point. On Sep 22, 12:08 pm, nervo <[email protected]> wrote: > Since v1.1, symfony handles a way to distantly customize a db schema. > (seehttp://www.symfony-project.org/book/1_2/17-Extending-Symfony#chapter_... > "New in symfony 1.1"). > > This offers a great way to customize plugins, such as sfGuard. > Unfortunately, this is only available for propel, and not for > doctrine. > > A ticket with a patch has been openened (http://trac.symfony- > project.org/ticket/7042). > Also, i have seen that symfony 1.3 will handle such ability, but only > by overriding schemas, and not customizing them. I also doubt this > will be usable in plugins. > (seehttp://www.symfony-project.org/tutorial/1_3/en/upgrade > "Override Doctrine Plugin Schema"). > > Anyway. > In order to obtain a real pluggable system, i feel certain such a tool > has to be implemented. > And i found an another approach to achieve it. I'd like to discuss > about it. > > First, i did'nt find any way to interact with doctrine build tasks, > and make some kind of magic to handle custom schemas before it makes > its job. There is eventually a "command.pre_command" event we could > trap, but, we can't in a plugin > (seehttp://trac.symfony-project.org/ticket/7185). > > Second, we can not use the "config/doctrine" directory to store some > files describing custom schemas in it, as doctrine build tasks will > search ALL yml files in ALL subdirectories. > So, let's use "config/doctrine_custom" directory. > > Then, we use a config handler to handle all "config/doctrine_custom/ > schema.yml" (config handlers does not supports wildcards, so although > we can put any named yaml file in "config/doctrine", we have to choose > a single name in our case). > The handler then use the doctrine import & builder classes to generate > not records php code, but template php code classes definitions. This > php code appears in the cache, named > "config_doctrine_custom_schema.yml.php", which is include in every > request. > > Last operation, we create a doctrine template named "Customizable". > Every record acting as "Customizable" try to find a > "Doctrine_Template_Custom_Schema_[componentName]" (this class sit in > "config_doctrine_custom_schema.yml.php" i you followed me :) ) and > finally acted as it. > > Let's give an example. > > In a myUserPlugin, for instance, we just declare in our schema : > > myUser: > actAs: [Customizable] #<----- Thats' the point ! > columns: > name: ... > password: .... > > Then, in any other plugin, we create a "config/doctrine_custom/ > schema.yml" wich contains : > > myUser: > actAs: [Timestampable] > columns: > age: ... > size: .... > > These customs schemas are merged, and we generate a doctrine template > based on them, standing in cache, which is automatically associated to > our main record "myUser", as it act as "Customizable". > Now, "myUser" actas "Timestampable" and got two new columns, "age", > and "size". > > 'You see the point ? > > Well, this approach takes me days, but it's works. > You can download an alpha state plugin right there > :http://tao.nervo.net/nvDoctrineCustomSchemaPlugin.tar.gz > > But before going further, i'd like to have other developpers > opinions :) > Do you like it ? Have you thought about something better ? Something > simplier ? Something more powerfull ? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
