Well, i naively thought this thread could be related to symfony developpment :) Sorry fo that, i will copy my orignal post to users list. Do you know a way to copy others posts ?
On 23 sep, 15:46, "[MA]Pascal" <[email protected]> wrote: > Hi guys, > > Interesting discussion but could you please keep this mailing list > focused on symfony development. > > symfony-users or ORM dedicated mailing-list will probably give you > best answers. > > Thank you for you understanding. > > [MA]Pascal > > On Sep 23, 1:35 pm, nervo <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
