Doctrine simple inheritance give ability to "extend" a base doctrine record. The base doctrine record will get the additionnal columns of its childs, that's a good point. But all the potential additionnal behaviors will be kept by the childs. In my blog exemple, if i have to "extend" the member class, with a photo gallery, a rating system, a shop cart, ..., i will have to deal with a Member object to deal with login/logout stuff, a MemberPhotoGallery object for galleries stuffes, a MemberShop cart for shop cart, ...... All of these object being related to the same db entry. What a mess :) And (as i can see, but i maybe wrong) you can't easily get an object by another one.
Now, that's true, i don't know what about propel and "behaviors" defined by custom schema. Does anybody knows ? On 23 sep, 14:47, Tom Boutell <[email protected]> wrote: > When I asked about a related subject, it was pointed out to me that > you can use Doctrine simple inheritance to achieve this. The added > columns will also be visible in the parent class, so you are > effectively adding more features to the parent class. Check out simple > inheritance in the Doctrine manual. > > That will let you add more columns via another plugin. It doesn't let > you add more methods to the sfGuardUser class though (apart from the > magic ones that let you access the new columns). But the .yml thing > for Propel doesn't either, right? > > > > On Wed, Sep 23, 2009 at 8:05 AM, nervo <[email protected]> wrote: > > > 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 ? > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
