How funny it is ! It was my first attempt to introduce custom schemas with doctrine, using sfEvents :) I made a template, who calls events in setUp(), setTableDefinition() and __call(), exactly like jon did. Then, i packaged it in a plugin.
I quickly realized two things : - using __call() produce big issues because of the way doctrine handle it. If two plugins using the __call() system, the first one have no ways to say "oh sorry, i don't have this method, try with the next one". Doctrine just use is_callable() function who always return true if a _call() method exists in the class. It don't wait for any return value to be sure the method have been executed. So if the first one failed -> exception. - Using this system, you have to write php code in your plugin system to extend other schemas you have defined in yaml. I really don't like this spaghetti, but it's certainly only a matter with me :) Anyway, if there is a consensus around this method, i think the right choice should be to allow only templates overriding in setUp() method. Your owns templates will be able to add columns and behaviors, and if one of them introduce a __call() method, and then, an issue occure, well, it will be its problem, and not the base record problem. But there is still this "problem" with mixing yaml and php. It would be certainly "cleaner" to add core functionnality in symfony to be able to keep yaml, and, why not, php code for more advanced features. What you think ? :) On 23 sep, 16:39, Thomas Rabaix <[email protected]> wrote: > Sympal has implemented such features with the event dispatche. This could be > a native function built inside symfony 1.3. > What you think ? > > > > On Wed, Sep 23, 2009 at 4:23 PM, nervo <[email protected]> wrote: > > > 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 > > -- > Thomas Rabaixhttp://rabaix.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
