Yes i know i can customize doctrine php classes :) But it's application related.
The goal is to create a kind of family of plugins, just like legos, where a new one can add functionnalities to another one. Imagine, let's say, a family of blog plugins. One plugin handle member aspects, and another one add a photo gallery component (or anything else). The member plugin should be "upgraded" to support photo galleries. And certainly not by manually moddifying the application models :) You ask "should this feature be available through some kind of Yml file ?". The answer is "yes" as symfony already support it, but only with propel :) The real question behind it, is "will symfony support it with doctrine ?" (cf. patch #7042), or do we have to think about a plugin to handle it. In this last case, is my vision of the way i made this plugin is the good one, or do you think about someting better/simplier ? On 23 sep, 11:10, Éric Rogé <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
