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.
