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.


Reply via email to