On 03.01.2010, at 14:07, Lukas Kahwe Smith wrote: > > On 02.01.2010, at 20:05, Daniel Lohse <annismcken...@googlemail.com> > wrote: > >> You can handle this in the global project schema.yml as it's merged >> automatically with the plugin schemas and is the last information >> added to the mix so you can override (but not delete) and customize >> every model object defined in plugins. This is how I now add >> additional fields to the sfGuardUser model (like next_password_reset >> and the like) that is original to the project. Am I really missing >> something you said/are saying? I can only imagine that merging/ >> adding of additional behaviors wouldn't work but it works for the >> columns: key and so should work for everything else. > > not at my laptop atm but if indeed all plugin schema files are just > appended to the beginning of the global schema.yml then all that > really needs to happen is that plugin authors make extensive use of > the yaml "merge key" support (just google "yaml merge key" to find > specs but sfyaml doesnt support the full spec. maybe there are docs on > the sf components page.
i reviewed the code, but to me this is far from that i need. the code does attempt to merge things, but it first parses, applies some magic and then merges the models to then finally dump a new yam file. at this point the merge key alias are of course lost, nor would they help, since every schema file seems to be parsed independently. i tried to quickly change the code to append the files together and use merge key to handle the plugin schema files (including overwriting a plugin schema file via another plugin using merge key), but i ran into some odd issues. not sure if they are related to sfYaml or some of the magic in the doctrine base task file. another approach would be to somehow inject all the previous merge key alias's before doing the next sfYaml::load() call, but that would require some modifications to sfYaml that i have not investigated if they are feasible. as for copying the schema definition into my own schema.yml, this does work after all. but there is a bug that led me to believe that something more severe is broken (*). however it means that i need to keep things in sync manually if any of my plugin schema files change. so to me we should still work towards finding a better solution. at this point i still believe that we would probably be served better to base the entire plugin schema handling (and extending) on merge key and not on magic inside the doctrine plugin base task. regards, Lukas Kahwe Smith m...@pooteeweet.org (*) the issue is caused by the way the behaviors are defined in the sfDoctrineGuard plugin: sfGuardUser: actAs: [Timestampable] in my customized plugin i used the "proper" (aka the one that does not require magic inside the Doctrine builder), then it clashes with the "merge magic" inside the Doctrine plugin task code: sfGuardUser: actAs: Timestampable: ~ SoftDelete: ~ Blameable: <<: *Blameable I guess I will discuss with Jonathan if this bug should be fixed inside the plugin merge task or inside the Doctrine builder. -- You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-us...@googlegroups.com. To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en.