Change xPeer::getOMClass to self::getOMClass

#2 Declined
Repository
GlorpenPropelBundle
Branch
default
Author
  1. cédric LOMBARDOT
Reviewers
Description

Change xPeer::getOMClass to self::getOMClass

Comments (6)

  1. cédric LOMBARDOT author

    This change permit to override the getOMClass on a sub class to by pass sometime the event configuration. Eg i have on Profile extends FosUser and one Employee extends the fosUser. Without this change the extends always load profile models else if i do EmployeeQuery

  2. cédric LOMBARDOT author

    Yes its extends behavior not propel inhéritance.

    When we use extends behavior if i want to use another PropelObjectFormatter formatter but with another model class, it still transform to the model defined in the yaml.

    My pronlem is that i have my user Profile class wich extends the fos user and used by fos to manage the user profile. This Profile expose some vars urls... for a profile context of my api.

    And i also have an Employee class wich is a fos user elements to. And i can't use inhéritance. because i can be Profile and Employee just depend what i do in the app

    So i have created an EmployeeQuery extends user query and with a modelClass = Employee. But when i pass a formatter he populate the found users as Profile and not as Employee

  3. Arkadiusz Dzięgiel repo owner

    Yaml - if there are multiple keys with same name they will overwrite themselves;

    PropelObjectFormatter calls Peer's populate methods which in turn calls getOmClass the model class from ModelCriteria constructor is not used;

    Patch you provided changes some MyPeer::getOMClass to self::getOMClass which is essentially the same, its not static keyword (or am I missing something?).

    even if you have working mapping FosUser => (Employee, Profile) I think it could cause problems: Propel cache checks only for ID so if you populate Employee with ID:1 and then ...->find() for Profile with same ID you will end up with Employee object.

  4. cédric LOMBARDOT author

    Yaml - if there are multiple keys with same name they will overwrite themselves;

    Yes but i want to use :

    FosUser\User: MyProfile FosUser\User: MyEmployee

    If i do that only the last win

    PropelObjectFormatter calls Peer's populate methods which in turn calls getOmClass the model class from ModelCriteria constructor is not used;

    Yes of course, but i ve redefine the getOmClass of Employee

    Patch you provided changes some MyPeer::getOMClass to self::getOMClass which is essentially the same, its not static keyword (or am I missing something?).

    The User::getOmClass seems not pass in my getOmClass so wtf ! Preheaps i miss something when i test it

    Cedric