Jonathan,

can you describe a bit that Sympal plugin that I'm curious about  ? Is
it like some kind of framework implementing menus/permissions/etc...
like drupal does ?

One can hope .. :)




On Mar 5, 3:03 pm, Jonathan Wage <[email protected]> wrote:
> I think I am fine with that.
>
>     $sympalPluginPath = dirname(__FILE__).'/../../../..';
>     $this->setPluginPath('sfSympalPlugin', $sympalPluginPath);
>
>     $embeddedPluginPath = $sympalPluginPath.'/lib/plugins';
>     $embeddedPlugins =
> sfFinder::type('dir')->relative()->maxdepth(0)->in($embeddedPluginPath);
>     foreach ($embeddedPlugins as $plugin)
>     {
>      $this->setPluginPath($plugin, $embeddedPluginPath.'/'.$plugin);
>     }
>
> This is the test project in sfSympalPlugin and that works fine.
>
> Thanks for the help.
>
> - Jon
>
> On Mon, Mar 2, 2009 at 4:57 PM, Matthias N. <
>
>
>
> [email protected]> wrote:
>
> > On 2 Mrz., 21:41, Jonathan Wage <[email protected]> wrote:
> > > On Mon, Mar 2, 2009 at 12:15 PM, Matthias N. <
>
> > > [email protected]> wrote:
>
> > > > On 1 Mrz., 23:22, Jonathan Wage <[email protected]> wrote:
> > > > > In that case it would load the one in the project plugins folder, and
> > > > > sfSympalPlugin wouldn't load the bundled plugin if it has already
> > been
> > > > > loaded.
>
> > > > I think to solve this, two things must be changed in the
> > > > sfProjectConfiguration class:
>
> > > > - additionally search for plugins in plugins/*/plugins
> > > > - allow to lazy load (enable) plugins
>
> > > > Then, in your plugin configuration class you can enable plugins/
> > > > sfSympalPlugin/plugins/sfDoctrineGuardPlugin when a
> > > > "sfDoctrineGuardPlugin" was not enabled before.
>
> > > This is exactly what I did to allow this. I was able to accomplish it a
> > few
> > > different ways, but not without modifying core.
>
> > Hm.. if you don't need "lazy loading" it would be enough to change the
> > project configuration to automatically enable all plugins found in
> > enabled plugins/*/plugins folders. And this should not require too
> > much changes in sfProjectConfiguration.
>
> > But you are right: I don't see a way for you to get this work without
> > a change in the core.
>
> > For sf 1.2 you could provide code to manually enable these embedded
> > plugins by a similar hack like this in ProjectConfiguration->setup():
>
> > <code>
> > $embeddedPluginPath = dirname(__FILE__').'/../plugins/sfSympalPlugin/
> > plugins';
> > $embeddedPlugins = sfFinder::type('dir')->relative()->maxdepth(0)->in
> > ($embeddedPluginPath);
> > foreach ($embeddedPlugins as $plugin)
> > {
> >  $this->setPluginPath($plugin, $embeddedPluginPath.'/'.$plugin);
> > }
>
> > $this->enablePlugins($embeddedPlugins);
> > </cody>
>
> > But it requires the user to do this manually.
>
> > > > It should not make a difference no matter where a plugin is loaded
> > > > from.
>
> > > > But I wonder why you really need this?
>
> > > I need/want this because sfSympalPlugin is more like an extension of
> > symfony
> > > and to make things more maintainable I split the core in to multiple
> > > plugins. This just makes things in to smaller more maintainable pieces.
> > The
> > > other reason is since all these plugins are truely a part of the core, I
> > > don't want to have separate svn repositories and "plugin page" for them.
>
> > > > Using dependencies with the pear installer should do it. ;-)
>
> > > Of course I can accomplish the installing with dependencies in the
> > package
> > > xml but that is not really the reason for me wanting to do what I am
> > doing.
> > > I also want all the code in these "core" plugins to be in onehttp://
> > svn.symfony-project.com/plugins/*repository and have one page onhttp://
> >www.symfony-project.com/plugins/*
>
> > I understand you and I could also imagine situations where I would
> > need "embedded plugins". ;-)
>
> > regards,
> > Matthias
>
> > > > regards,
> > > > Matthias
>
> > > > > On Sun, Mar 1, 2009 at 9:40 AM, naholyr <[email protected]> wrote:
>
> > > > > > And what if you have "plugins/sfSympalPlugin/subPlugins/
> > > > > > sfDoctrineGuardPlugin" AND "plugins/sfDoctrineGuardPlugin" ? Which
> > one
> > > > > > will be the good plugin to load ?
> > > > > > We'd have to deal with very architecture-specific issues like "in
> > what
> > > > > > order my plugins are loaded ?", and I hate this idea which reminds
> > me
> > > > > > bad days passed on things like Typo3 :P
>
> > > > > > On 1 mar, 00:08, Bernhard Schussek <[email protected]> wrote:
> > > > > > > Hi Jon,
>
> > > > > > > I already thought about that matter as well, but I don't know of
> > any
> > > > > > > way how this can be achieved. I guess this could be a nice
> > addition
> > > > > > > for symfony 1.3, together with a few other plugin enhancements
> > such
> > > > as
> > > > > > > better supported plugin unit&functional testing.
>
> > > > > > > Bernhard
>
> > > > > --
> > > > > Jonathan H. Wage
> > > > > Open Source Software Developer &
> > > > Evangelisthttp://www.jwage.comhttp://www.doctrine-project.orghttp://
> > > >www.symfony-project.org
>
> > > --
> > > Jonathan H. Wage
> > > Open Source Software Developer &
> > Evangelisthttp://www.jwage.comhttp://www.doctrine-project.orghttp://
> >www.symfony-project.org
>
> --
> Jonathan H. Wage
> Open Source Software Developer & 
> Evangelisthttp://www.jwage.comhttp://www.doctrine-project.orghttp://www.symfony-project.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to