Hi Matthias & Marijn, The new method only affects autoloading insofar as it tells the autoloader where to find the plugin. It is still up to the plugin developer to layout classes in such a way that they can be easily customized in the project directory.
We'll be reviewing these techniques at tomorrow's plugin day. Thanks, Kris On Nov 7, 2008, at 5:56 AM, "Matthias N." <[EMAIL PROTECTED] > wrote: > > On 7 Nov., 14:44, Marijn Huizendveld <[EMAIL PROTECTED]> > wrote: >> Hi Matthias, >> >> I don't know if you miss something but I agree with you on all >> points. I think it would be great if I could save my most used >> plugins in the plugins dir in sf_root_dir because currently I have >> way to many instances of for example sfDoctrine and sfDoctrineGuard. > > With the great enhancements of symfony 1.2 it is no problem anymore to > have for example a central plugin folder in development containing all > your favorite plugins and in your project only enable the plugins you > need. The new method (sfProjectConfiguration::setPluginPath()) makes > this even more flexible so I don't see any more problems with plugin > organisation. > > My concerns are only about the generel concept of where to customize > plugins: > - In the plugin -- no good idea when you want to share them between > projects > - In the project -- generally more straightforward > > This is probably a little complicated thing and also autoloading is an > important subject. For example: "only include lib/form/pluginname > folders of enabled plugins into autoloading" !? > > regards, > Matthias > > >> >> On Nov 7, 2008, at 2:40 PM, Matthias N. wrote: >> >> >> >>> Hi, >> >>> changeset 12668 [1] introduced a way >>> (sfProjectConfiguration::setPluginPath()) to be able to use one or >>> several plugin(s) being not located in the project's plugins/ >>> directory. >> >>> To me this is a great enhancement. Even though I didn't have time to >>> do some tests it seems that it also solves my ticket 4690 [2] or at >>> least I can now imagine how to solve this by some simple code >>> lines in >>> my project configuration class. >> >>> But I wondered about the doc comment from Kris which seems to >>> outline >>> a design/architectural framework problem: >> >>> "This method can be used to ease functional testing of plugins. It >>> is >>> not >>> intended to support sharing plugins between projects, as many >>> plugins >>> save project specific code (to /lib/form, for example)." >> >>> If this is the case that it is intended to customize form classes >>> (or >>> whatever classes) in the plugins, this can not be a good idea. All >>> customization of any part of a plugin should always and only >>> happen in >>> the project. >> >>> For the forms I think the "final" form classes should not be in the >>> plugins but they should be created in the project lib/form directory >>> under a directory named by the plugin name, e.g. lib/form/ >>> sfGuardPlugin >> >>> And people should place/edit their custom form classes there like I >>> know this from the sfDoctrinePlugin which provides a very useful >>> plugin organisation concept of the model classes. >> >>> Do I miss something here? >> >>> regards, >>> Matthias >> >>> [1]http://trac.symfony-project.org/changeset/12668 >>> [2]http://trac.symfony-project.org/ticket/4690 > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
