On 04.01.2010, at 11:49, Lukas Kahwe Smith wrote: > > 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.
thinking about it some more .. maybe we can go in a direction similar to the import directive in the ServiceContainer .. than again does it even make sense for me to worry about this for symfony 1.x or should I just make sure that Symfony 2.x is more sensible here and accept that I need to duplicate the schema definition in 1.x? regards, Lukas Kahwe Smith m...@pooteeweet.org -- 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.
