Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugins cannot access DSL from other plugins #1230

Closed
xsawyerx opened this issue Aug 10, 2016 · 1 comment
Closed

Plugins cannot access DSL from other plugins #1230

xsawyerx opened this issue Aug 10, 2016 · 1 comment

Comments

@xsawyerx
Copy link
Member

This is an issue related to GH #1226, but in this case it's plugins accessing DSL by other plugins.

package MyApp {
    use Dancer2;
    use Dancer2::Plugin::Foo;
}

package Dancer2::Plugin::Foo {
    use Dancer2::Plugin;
    use Dancer2::Plugin::Bar;
    plugin_keywords('outer');
    sub outer { inner() }
}

package Dancer2::Plugin::Bar {
    use Dancer2::Plugin;
    plugin_keywords('inner');
    sub inner {1}
}

We have a Dancer App which loads a plugin which then loads another plugin. Both plugins have DSL keywords. Currently the second plugin (Bar) has a keyword (inner) which will never be exposed anywhere. It is not available to the App or to the first plugin (Foo).

xsawyerx added a commit that referenced this issue Aug 10, 2016
This test show-cases the problem (and my offered solution to it)
of having plugins loading other plugins and getting their DSL
keywords.

It creates an app (and to make it more fun, it sets the appname
to a class that doesn't exist) and two plugins. The first loads
the second. They both provide DSL keywords.

It then tries to use the inner plugin's keyword in either the
app, the appname class, or the plugin itself, hoping that it will
work in the plugin itself - which fails right now.
xsawyerx added a commit that referenced this issue Aug 10, 2016
The reason plugins calling DSL on other plugins doesn't work
is because we explicitly only allow importing plugins DSL
from applications.

The way we verify this is by trying to call "app" attribute
on the consuming class. Plugins don't have this. The change
I made here is to check if "->dsl->app" is also available,
which is available in plugins.

This fixed GH #1230.
cromedome pushed a commit that referenced this issue Aug 13, 2016
This test show-cases the problem (and my offered solution to it)
of having plugins loading other plugins and getting their DSL
keywords.

It creates an app (and to make it more fun, it sets the appname
to a class that doesn't exist) and two plugins. The first loads
the second. They both provide DSL keywords.

It then tries to use the inner plugin's keyword in either the
app, the appname class, or the plugin itself, hoping that it will
work in the plugin itself - which fails right now.
cromedome pushed a commit that referenced this issue Aug 13, 2016
The reason plugins calling DSL on other plugins doesn't work
is because we explicitly only allow importing plugins DSL
from applications.

The way we verify this is by trying to call "app" attribute
on the consuming class. Plugins don't have this. The change
I made here is to check if "->dsl->app" is also available,
which is available in plugins.

This fixed GH #1230.
cromedome added a commit that referenced this issue Aug 13, 2016
@cromedome
Copy link
Contributor

Merged with 9775d00. Closing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants