All, I'd like to submit my module to CPAN. If nobody has any objections, I would like help with two questions: 1. Chapter, what chapter should this be listed under? (WWW?) I can't find Dancer2 anywhere. 2. Should interface style be listed as OO? On Sun, Sep 8, 2013 at 8:37 AM, Pedro Melo <melo@simplicidade.org> wrote:

Hi

On Sunday, September 8, 2013, Slavik Goltser wrote:

...

Hi everyone, I have done some work on migrating the Dancer::Template::Mason2 plugin to Dancer2.

The code is located on github: https://github.com/theslava/perl-dancer2-template-mason2

I would love to hear some feedback (I am sure backwards compatibility with Dancer1 will be one of the points). Please keep in mind that I am very new to Moo(se)/Dancer and there are some things that I have done in the code that I do not completely understand.

This code is based directly on Jonathan's code so the license for this plugin is the same as his. I think the license he mentions in his code is the Artistic License 2.0 ... I have sent him an e-mail asking for clarification.

Enjoy, Slava

I have a working Mason plugin for dancer2 that I'm using on production on Github.

I'll look at yours and suggest any improvements later today.

Bye,

-- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

Took a quick look yesterday, definitely going to incorporate some code. On Sat, Sep 28, 2013 at 6:46 AM, Pedro Melo <melo@simplicidade.org> wrote:

Hi,

checkout https://github.com/melo/perl-dancer2-template-mason

It solves the problem with using autoextend_request_path, and it also allows the user to override everything from Config.

Bye,

On Fri, Sep 27, 2013 at 3:08 AM, Slavik Goltser <slavikg@gmail.com> wrote:

...

All,

I'd like to submit my module to CPAN. If nobody has any objections, I would like help with two questions: 1. Chapter, what chapter should this be listed under? (WWW?) I can't find Dancer2 anywhere. 2. Should interface style be listed as OO?

On Sun, Sep 8, 2013 at 8:37 AM, Pedro Melo <melo@simplicidade.org> wrote:

...

Hi

On Sunday, September 8, 2013, Slavik Goltser wrote:

...

Hi everyone, I have done some work on migrating the Dancer::Template::Mason2 plugin to Dancer2.

The code is located on github: https://github.com/theslava/perl-dancer2-template-mason2

I would love to hear some feedback (I am sure backwards compatibility with Dancer1 will be one of the points). Please keep in mind that I am very new to Moo(se)/Dancer and there are some things that I have done in the code that I do not completely understand.

This code is based directly on Jonathan's code so the license for this plugin is the same as his. I think the license he mentions in his code is the Artistic License 2.0 ... I have sent him an e-mail asking for clarification.

Enjoy, Slava

I have a working Mason plugin for dancer2 that I'm using on production on Github.

I'll look at yours and suggest any improvements later today.

Bye,

-- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

-- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

there is already a Dancer::Template::Mason, this plugin is intended to be a Dancer2 module. data_dir ... I followed the original module closely, will take a look to see what happens when it isn't there. thank you for taking a look. On Mon, Sep 30, 2013 at 10:56 AM, Pedro Melo <melo@simplicidade.org> wrote:

Hi,

On Mon, Sep 30, 2013 at 3:29 PM, Slavik Goltser <slavikg@gmail.com> wrote:

...

Took a quick look yesterday, definitely going to incorporate some code.

Feel free, I don't have enough time to clean it up and push to CPAN… Two comments on your code:

* I would rename to Dancer::Template::Mason, given that the name of the module is Mason, not Mason2. * Drop the data_dir part from your code: Mason defaults are safe enough, no need to add different semantics at this layer, the user can always make his own mind and change the config.

Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

Hi, On Mon, Sep 30, 2013 at 5:34 PM, Slavik Goltser <slavikg@gmail.com> wrote:

there is already a Dancer::Template::Mason, this plugin is intended to be a Dancer2 module.

Sure, I know, but I'm saying that the name should be Dancer2::Template::Mason not Dancer2::Template::Mason2, because the template system is called Mason, not Mason2.

data_dir ... I followed the original module closely, will take a look to see what happens when it isn't there.

I think in the situation less is more. The less you add as semantics to your layer, the less documentation one needs to know how D2::T::Mason will work, because you can say "just look at Mason defaults". Besides, there is no good data_dir default to use. Your suggestion about using comp_root/data is not good because with shared perl installs you might not even have permissions to write there. The default data_dir doesn't have that problem.

thank you for taking a look.

No problem. I'm still using a git submodule to have my own Dancer2::Template::Mason module, so having this on CPAN will make my life easier. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org

Hi, On Mon, Sep 30, 2013 at 8:35 PM, Slavik Goltser <slavikg@gmail.com> wrote:

I agree on the naming (it was a conflict in my mind when I was doing it). the data_dir is literally ripped out from the original. any idea where it puts things without any data_dir definition?

Yes, on the default place as set by Mason. It's defined here [1] and currently is set to be a temporary directory that will be deleted when the process dies. [1]: https://metacpan.org/module/Mason::Interp#data_dir I'll try your module with some of my sites at work to see if I can detect further problems. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org

Hi, On Tue, Oct 1, 2013 at 4:35 PM, Slavik Goltser <slavikg@gmail.com> wrote:

That is a good point. I tried to be as close as possible to the original.

Mason and HTML::Mason are totally different beasts internally. I don't think you should have this as a goal. Your goal should be to make the best Template plugin for Mason users. What are you thoughts on data_dir? I would like to stick with how the

original plugin implemented it (as a dir next to views/). One other reason for that is (according to the doc) is that you win a bit on startup as you don't have to recompile the module, although I kind of feel like startup time is a bit of a moot point for an application that technically does not get restarted often.

I rather have the Mason default myself. The Mason documentation already mention that you should define a data_dir to a directory somewhere if you care about performance that much. I can say that defaulting to views/data will not work on my apps, that part of the tree is not writable by the user that runs the webapp. For most common use, having a fresh data_dir on restart is actually a good thing, it makes debugging situations with timestamps between deployed .mc/.mi files and cached compiled objects simpler.. So I still prefer my way: kill it, let users override all config. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ xmpp:melo@simplicidade.org mailto:melo@simplicidade.org