I am a user of https://metacpan.org/pod/Dancer#load_app <q> load_app 'Forum', prefix => '/forum', settings => {foo => 'bar'}; </q> I reuse controler modules in different deployment modules. Some controler modules are useful CPAN modules. They do not extend the DSL, so, are not Dancer::Plugin's. Can I use the namespace Dancer::App for those modules? -- Henk
Can you give an example of one that is useful as a CPAN module? On Sun, Dec 8, 2013 at 12:27 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
I am a user of https://metacpan.org/pod/Dancer#load_app
<q> load_app 'Forum', prefix => '/forum', settings => {foo => 'bar'}; </q>
I reuse controler modules in different deployment modules. Some controler modules are useful CPAN modules. They do not extend the DSL, so, are not Dancer::Plugin's.
Can I use the namespace Dancer::App for those modules?
-- Henk _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, 8 Dec 2013, sawyer x wrote:
Can you give an example of one that is useful as a CPAN module?
Yes, lots. How many Dancer::App's can you find that implement: - a blog - an URL shortener - bookmarks - pastebins - or (from the docs) a forum? Some of them need an Auth system but we have Dancer-Plugin-Auth-Extensible Just configure your Dancer::App in config.yml I am working on a "mailman" system. Do you want to reinvent a "usergroup"? I do. And I want it to look NOT like http://lists.preshweb.co.uk/mailman/listinfo/dancer-users So: Dancer::App::Usergroup Can I have that namespace? -- Henk
On Sun, Dec 8, 2013 at 12:27 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
I am a user of https://metacpan.org/pod/Dancer#load_app
<q> load_app 'Forum', prefix => '/forum', settings => {foo => 'bar'}; </q>
I reuse controler modules in different deployment modules. Some controler modules are useful CPAN modules. They do not extend the DSL, so, are not Dancer::Plugin's.
Can I use the namespace Dancer::App for those modules?
-- Henk
I think that namespace would be a problem for a few reasons: - we don't know if we'll end up using it for something - it's very generic If someone wants to create the same thing ("hey, I want a mailman in Dancer too"), you basically get a clash. Now you'll have Dancer::App::Mailman and Dancer::App::Perlman and Dancer::App::Mailman::Faster, etc. The best approach, IMHO, is to give your project a name (like "mailman" is the name) and use that. This is what Starman, Twiggy, Dancer, Mojo, etc. do. We all give our projects names and release them under those names. Also, another general note: web applications don't really fit the CPAN structure. I think every web framework (including Dancer) gets this wrong. Our installation tools are not suited for this type of program. We do our best (sort of) to allow easy encapsulation but it's still the wrong approach. I don't think anyone figured it out yet in Perl-land. On Sun, Dec 8, 2013 at 12:57 PM, Henk van Oers <henk@signature.nl> wrote:
On Sun, 8 Dec 2013, sawyer x wrote:
Can you give an example of one that is useful as a CPAN module?
Yes, lots. How many Dancer::App's can you find that implement: - a blog - an URL shortener - bookmarks - pastebins - or (from the docs) a forum?
Some of them need an Auth system but we have Dancer-Plugin-Auth-Extensible Just configure your Dancer::App in config.yml
I am working on a "mailman" system. Do you want to reinvent a "usergroup"? I do. And I want it to look NOT like http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
So: Dancer::App::Usergroup
Can I have that namespace?
-- Henk
On Sun, Dec 8, 2013 at 12:27 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
I am a user of https://metacpan.org/pod/Dancer#load_app
<q> load_app 'Forum', prefix => '/forum', settings => {foo => 'bar'}; </q>
I reuse controler modules in different deployment modules. Some controler modules are useful CPAN modules. They do not extend the DSL, so, are not Dancer::Plugin's.
Can I use the namespace Dancer::App for those modules?
-- Henk
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, 8 Dec 2013, sawyer x wrote:
I think that namespace would be a problem for a few reasons: - we don't know if we'll end up using it for something
I know you will not if you give Dancer::App::Usergroup to me
- it's very generic
Yes. Like Dancer::Plugin And I can make any plugin.
If someone wants to create the same thing ("hey, I want a mailman in Dancer too"), you basically get a clash. Now you'll have Dancer::App::Mailman and Dancer::App::Perlman and Dancer::App::Mailman::Faster, etc.
Yep. Just like in the Plugin namespace.
The best approach, IMHO, is to give your project a name (like "mailman" is the name) and use that. This is what Starman, Twiggy, Dancer, Mojo, etc. do. We all give our projects names and release them under those names.
No we dont.
Also, another general note: web applications don't really fit the CPAN structure. I think every web framework (including Dancer) gets this wrong. Our installation tools are not suited for this type of program. We do our best (sort of) to allow easy encapsulation but it's still the wrong approach. I don't think anyone figured it out yet in Perl-land.
I figured it out. You want me to clame Dancers and one of these is Dancers::Usergroup Think again. -- Henk
On Sun, Dec 8, 2013 at 12:57 PM, Henk van Oers <henk@signature.nl> wrote:
On Sun, 8 Dec 2013, sawyer x wrote:
Can you give an example of one that is useful as a CPAN module?
Yes, lots. How many Dancer::App's can you find that implement: - a blog - an URL shortener - bookmarks - pastebins - or (from the docs) a forum?
Some of them need an Auth system but we have Dancer-Plugin-Auth-Extensible Just configure your Dancer::App in config.yml
I am working on a "mailman" system. Do you want to reinvent a "usergroup"? I do. And I want it to look NOT like http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
So: Dancer::App::Usergroup
Can I have that namespace?
-- Henk
On Sun, Dec 8, 2013 at 12:27 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
I am a user of https://metacpan.org/pod/Dancer#load_app
<q> load_app 'Forum', prefix => '/forum', settings => {foo => 'bar'}; </q>
I reuse controler modules in different deployment modules. Some controler modules are useful CPAN modules. They do not extend the DSL, so, are not Dancer::Plugin's.
Can I use the namespace Dancer::App for those modules?
-- Henk
I'm sorry, Henk. I'm not sure I understand your email. On Sun, Dec 8, 2013 at 2:15 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
On Sun, 8 Dec 2013, sawyer x wrote:
I think that namespace would be a problem for a few reasons: - we don't know if we'll end up using it for something
I know you will not if you give Dancer::App::Usergroup to me
We don't "give". It's CPAN. First come, first serve. If you upload Dancer::App::Henk to CPAN now, it's yours. We can't control that. What we're doing here is conversing and trying to decide together on something that makes sense.
- it's very generic
Yes. Like Dancer::Plugin And I can make any plugin.
That's not the same. The Dancer::App namespace is used by Dancer internally. The Dancer::Plugin is a namespace to allow user plugins. Moose uses MooseX, we use Dancer::Plugin. Also, we have already asked in the past to not use generic names for plugins to allow other people to have room as well, and to make sure we don't crowd possible generic namespaces. That's why we renamed Dancer::Plugin::Authorize to Dancer::Plugin::Auth::RBAC. So Dancer::App and Dancer::Plugin are really not the same.
If someone wants to create the same thing ("hey, I want a mailman in
Dancer too"), you basically get a clash. Now you'll have Dancer::App::Mailman and Dancer::App::Perlman and Dancer::App::Mailman::Faster, etc.
Yep. Just like in the Plugin namespace.
Which is also why we renamed Dancer::Plugin::Authorize. Which is also why we had an entire discussion and asked people not to pick generic names. The benefit is that you at least know it's plugins under Dancer::Plugin, whereas Dancer::App is used by Dancer itself.
The best approach, IMHO, is to give your project a name (like "mailman"
is the name) and use that. This is what Starman, Twiggy, Dancer, Mojo, etc. do. We all give our projects names and release them under those names.
No we dont.
"We" as "Starman, Twiggy, Dancer, Mojo", yes, we do. Perhaps you don't, but you asked for our advice, and this is our advice. We kindly request that you do not use anything under Dancer::App because it's not the proper place for it, in our opinion. If you want to do it anyway, we can't stop you. It's Perl after all. :)
Also, another general note: web applications don't really fit the CPAN
structure. I think every web framework (including Dancer) gets this wrong. Our installation tools are not suited for this type of program. We do our best (sort of) to allow easy encapsulation but it's still the wrong approach. I don't think anyone figured it out yet in Perl-land.
I figured it out.
I'm not sure we mean the same thing here. Do you mean you figured out how to distribute web applications easily with the CPAN toolchain? I'd love to hear how.
You want me to clame Dancers and one of these is Dancers::Usergroup
I don't understand these two sentences.
On Sun, 8 Dec 2013, sawyer x wrote:
I'm sorry, Henk. I'm not sure I understand your email.
No problem. [...]
So Dancer::App and Dancer::Plugin are really not the same.
I told you so. (And Dancer::App is not a namespace yet, see: locate) Let me ask for an other namespace: Dancer::Loadapp -- Henk
On Sun, Dec 8, 2013 at 3:38 PM, Henk van Oers <henk@signature.nl> wrote:
On Sun, 8 Dec 2013, sawyer x wrote:
So Dancer::App and Dancer::Plugin are really not the same.
I told you so.
I thought you meant that if people can use Dancer::Plugin, why can't they use Dancer::App. I probably misunderstood.
(And Dancer::App is not a namespace yet, see: locate)
Dancer/App.pm *is* used internally. That's why Dancer/App/* is a problem. Dancer/Plugin/* is not because it's meant for that purpose.
Let me ask for an other namespace: Dancer::Loadapp
I don't think that's good either. Why can't this be a plugin, by the way?
On Sun, 8 Dec 2013, sawyer x wrote:
On Sun, Dec 8, 2013 at 3:38 PM, Henk van Oers <henk@signature.nl> wrote:
On Sun, 8 Dec 2013, sawyer x wrote:
So Dancer::App and Dancer::Plugin are really not the same.
I told you so.
I thought you meant that if people can use Dancer::Plugin, why can't they use Dancer::App. I probably misunderstood.
(And Dancer::App is not a namespace yet, see: locate)
Dancer/App.pm is used internally. That's why Dancer/App/* is a problem. Dancer/Plugin/* is not because it's meant for that purpose.
Let me ask for an other namespace: Dancer::Loadapp
I don't think that's good either.
Why not?
Why can't this be a plugin, by the way?
I told you so.
Why can't this be a plugin, by the way?
I'll make the tactical mistake of jumping into this thread before my first coffee, and say that I agree with Sawyer: I think that those modules could very well find their home in the ::Plugin namespace. Typically, plugins do add keywords, but they don't have to: they can also extend the functionality of the application itself. Henk, do you already have some of your code on GitHub? If it is, it would probably be easier to use one of them as an example of that I mean. Joy, `/anick
And I'll make the tactical mistake of jumping into this thread after a long day :) and say that I agree with Sawyer and Yanick. I'd like to add this: Let's say you publish Dancer::App::MyGreatApp for other people to use. Some of them will use it as is, like without touching it, but others (most of them ?) will want to tweak it, change some stuff, expand on it, etc. And it will be much easier if it's a plugin. If you know POE, I think I could compare what you're trying to publish as a POE component. That would be translated in a Dancer::Plugin. Now, if your code can't fit in a plugin, then first, we'd like to see the code, and second, if it's really out of the Plugin's league, then we could think of something else. Like Dancer::Component. But I honestly doubt it can't fit into a Plugin dams. On Sun, Dec 8, 2013, at 08:42 AM, Yanick Champoux wrote:
Why can't this be a plugin, by the way?
I'll make the tactical mistake of jumping into this thread before my first coffee, and say that I agree with Sawyer: I think that those modules could very well find their home in the ::Plugin namespace.
Typically, plugins do add keywords, but they don't have to: they can also extend the functionality of the application itself.
Henk, do you already have some of your code on GitHub? If it is, it would probably be easier to use one of them as an example of that I mean.
Joy, `/anick
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, 8 Dec 2013, Yanick Champoux wrote:
Why can't this be a plugin, by the way?
I'll make the tactical mistake of jumping into this thread before my first coffee, and say that I agree with Sawyer: I think that those modules could very well find their home in the ::Plugin namespace.
OK. The namespace Dancer::Plugin::App sounds good.
Typically, plugins do add keywords, but they don't have to: they can also extend the functionality of the application itself.
Typically, load_app's do not add keywords. That's why the Subject is "Namespace for load_app modules".
Henk, do you already have some of your code on GitHub? If it is, it would probably be easier to use one of them as an example of that I mean.
On github I have Amsterdam.pm https://github.com/hvoers/PNL/blob/master/lib/Amsterdam.pm But I do not want to claim the Amsterdam namespace on CPAN. Dancer::Plugin::App::Amsterdam will do just fine. I'll make a Dancer::Plugin::App::AmsterdamX.pm to make things clear. Yes, that's Sawyer's namespace. See http://amsterdamx.pm/
Joy, `/anick
-- Henk
We didn't mean Dancer::Plugin::App... On Sun, Dec 8, 2013 at 11:53 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
On Sun, 8 Dec 2013, Yanick Champoux wrote:
Why can't this be a plugin, by the way?
I'll make the tactical mistake of jumping into this thread before my first coffee, and say that I agree with Sawyer: I think that those modules could very well find their home in the ::Plugin namespace.
OK. The namespace Dancer::Plugin::App sounds good.
Typically, plugins do add keywords, but they don't have to: they can also
extend the functionality of the application itself.
Typically, load_app's do not add keywords. That's why the Subject is "Namespace for load_app modules".
Henk, do you already have some of your code on GitHub? If it is, it would
probably be easier to use one of them as an example of that I mean.
On github I have Amsterdam.pm https://github.com/hvoers/PNL/blob/master/lib/Amsterdam.pm But I do not want to claim the Amsterdam namespace on CPAN.
Dancer::Plugin::App::Amsterdam will do just fine.
I'll make a Dancer::Plugin::App::AmsterdamX.pm to make things clear. Yes, that's Sawyer's namespace. See http://amsterdamx.pm/
Joy,
`/anick
-- Henk
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Mon, 9 Dec 2013, sawyer x wrote:
We didn't mean Dancer::Plugin::App...
OK fine. What namespace are YOU willing to give US. TINW http://acronyms.thefreedictionary.com/TINW WE want a namespace.
On 13-12-08 06:41 PM, Henk van Oers wrote:
WE want a namespace.
Acme::* ? Only jesting, only jesting... Okay, let's try this again from the top. If you wish to publish a full-fledged application, which the Amsterdam.pm seems to be, then what I would consider the right place is App::Amsterdam. Sawyer was right when he was saying that CPAN is historically not tailor-suited for applications, and so far I think the App::* namespace is the closest we have of a place for packaged up end-applications. This being said, I would *strongly* argue that App::Amsterdam should not be pushed to CPAN in its current form. This is a very specific website that can't be reused as part of something else, or really used as-is by anybody but you. On the other hand, if you want to morcel and publish pieces of the Amsterdam app that could be reused (a forum controller, a mailing list interface, etc), then the typical way nowaday is to package that into a, e.g., Dancer::Plugin::Forum module. Now, it is true that Dancer has that concept of sub-apps that can be used via 'load_app'. I have yet to see somebody package functionality leveraging this mechanism instead of the plugin infrastructure, but I can see that it's totally possible -- and now that you have mentioned it, I'm intrigued. But, closer to the point, if you do have something that you can't wrap as a plugin -- and for the moment it seems this is not the case -- then as mentioned before Dancer::App::* is an iffy namespace, just because of the way we have layed out the design so far. If you do really have something that will make more sense to package as a sub-app, then dams's suggestion of using Dancer::Component::* would be the sanest way to go. So, to recap: full application? App::Stuff Add-on to Dancer to make it more awesome? Dancer::Plugin::Stuff Brand new concept that can't be wrapped in a plugin? Perhaps Dancer::Component::Stuff. But I strongly suggest that you bounce the code in here, as I'm pretty sure we can help you to coax that strange mutant into a more mundane plugin. Joy, `/anick
On Sun, 8 Dec 2013, Yanick Champoux wrote: [...]
Brand new concept that can't be wrapped in a plugin? Perhaps Dancer::Component::Stuff. But I strongly suggest that you bounce the code in here, as I'm pretty sure we can help you to coax that strange mutant into a more mundane plugin.
Thank you. I will do that. -- Henk
participants (5)
-
Damien Krotkine -
Henk van Oers -
Henk van Oers -
sawyer x -
Yanick Champoux