Hi Marco, I've checked out the ProxyManager, however it doesn't help with the initial problem, which is that doctrine doesn't support using a customized proxy generator. Committing the generated code could be avoided by using a hook or a script to generate it on the fly, it's not the problem here either :(
The problem is: users of the model shouldn't worry about maintaining the proxies, they should not know about them or worry about how they work. Imagine this, you're using a model as composer dependency, and in order to use it you need to generate proxies for it's entities and maintain them in your application. and each time you add a new model to your dependencies or update an existing one you will need to generate proxies for them (provided that you know the "Entity" directory for each model). On Sunday, April 12, 2015 at 7:04:31 PM UTC+3, Marco Pivetta wrote: > > I'd rather tell you not to commit generated code to the repository in > first place... > On Apr 12, 2015 6:02 PM, "Badr Ghatasheh" <[email protected] > <javascript:>> wrote: > >> Hi Guilherme, >> >> I don't think you got my question right, let me explain it further, but >> let me establish that I don't want developers modifying the proxy files, I >> just want them to include them in their committed models. >> >> In my use case, models are stand alone data access layers, every model is >> on it's own git repository (not side by side), and if application X needed >> to use the "User" model, it must be included as a composer dependency. >> >> The "User" model structure will look something like this: >> User/ >> |-- Entity/ >> |-- User.php >> |-- UserInfo.php >> |-- UserAddress.php >> |-- Proxy/ >> |-- User.php >> |-- UserInfo.php >> |-- UserAddress.php >> |-- Repository/ >> |-- User.php >> |-- Service/ >> |-- Login.php >> |-- AccountSettings.php >> >> >> Proxies are in red (generated). >> The reasons I need proxies to be a part of the model itself and not a >> part of the applications that uses this model are two: >> >> 1. I don't want each application to worry about bootstrapping and >> generating proxies for EVERY model it needs. >> 2. This is a one time job, during the release cycle of the model, not >> the application. >> >> So I have managed to do this by forking doctrine (and another way by >> copying the ProxyFactory.php and extending the ProxyGenerator.php and the >> EntityManager.php). >> >> All I'm saying is people are bound to have their use cases of proxies, >> why not have those classes be extendable? >> >> Thanks a lot :) >> >> On Sunday, April 12, 2015 at 6:01:33 PM UTC+3, Guilherme Blanco wrote: >>> >>> Hi, >>> >>> Doctrine core developer here. >>> While I don't believe this will ever happen, any idea needs to be >>> considered and I may be wrong if and only if you manage to provide me a >>> plausible reason of your intents which this request. All you have to do is >>> answer the following questions: >>> >>> Can you give one reason why you want the models side by side? >>> After that, can you explain my why you want developers to modify a Proxy? >>> >>> >>> Regards, >>> >>> On Sun, Apr 12, 2015 at 8:37 AM, Badr Ghatasheh <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> I'm building an SOA platform which leverages Doctrine 2.4.7 ORM to >>>> build reusable data models, which will have multiple namespaces for each >>>> model with PSR-4 autoloading mechanism, i.e. >>>> >>>> Git Repo1 has: >>>> \Model\User\Entity\User >>>> \Model\User\Entity\UserInfo >>>> >>>> Git Repo2 has: >>>> \Model\Locale\Entity\Country >>>> >>>> And so on. >>>> >>>> I'm trying to have proxies as a part of each model itself, so that the >>>> developers working on User model would include their proxies side by side >>>> with their entities. >>>> >>>> The only way I managed to do that is to fork doctrine ORM and modify >>>> the proxy generator, and create my custom proxy autoloader. >>>> While the solution works, I still want to avoid forking doctrine, is >>>> there any way I can achieve this without having to modify the framework >>>> itself? >>>> >>>> P.S. having the proxies generated and configured on each application >>>> that uses the model is not an option. >>>> Regards. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "doctrine-user" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/doctrine-user. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Guilherme Blanco >>> MSN: [email protected] >>> GTalk: guilhermeblanco >>> Toronto - ON/Canada >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "doctrine-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/doctrine-user. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
