[Catalyst] Global 'helper' methods
Hi, Please could you advise the best way of having a global 'helper' class that has all commonly used methods in it accessible for any part of the catalyst app. I found this thread http://stackoverflow.com/questions/11941836/catalyst-global-subroutines With one indicating it's ok to put them in the main MyApp.pm and another saying to use Moose Roles. What is considered the correct way and could you provide an example of how I create this helper class and bolt it to the Catalyst application. Many thanks, Craig Chant I.T. Manager [Description: cid:image001.png@01CD5F4A.17E848D0] Main Line01903 602664 Direct Line 01903 227753 Visit our website http://www.homeloanpartnership.com HomeLoan Partnership have been named the Best Mortgage Network, 2012, at the myintroducer.com Industry Awards This Email and any attachments contain confidential information and is intended solely for the individual to whom it is addressed. If this Email has been misdirected, please notify the author as soon as possible. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained, and all copies must be deleted immediately. Whilst we take reasonable steps to try to identify any software viruses, any attachments to this e-mail may nevertheless contain viruses, which our anti-virus software has failed to identify. You should therefore carry out your own anti-virus checks before opening any documents. HomeLoan Partnership will not accept any liability for damage caused by computer viruses emanating from any attachment or other document supplied with this e-mail. HomeLoan Partnership reserves the right to monitor and archive all e-mail communications through its network. No representative or employee of HomeLoan Partnership has the authority to enter into any contract on behalf of HomeLoan Partnership by email. HomeLoan Partnership is a trading name of H L Partnership Limited, registered in England and Wales with Registration Number 5011722. Registered office: 26-34 Old Street, London, EC1V 9QQ. H L Partnership Limited is authorised and regulated by the Financial Services Authority. inline: image001.png___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Global 'helper' methods
Well I opted for putting my globals (methods and constants) in MyApp.pm
It's working grand with $c-myMethod or $c-MY_CONSTANT
I use to have them working as a bareword within my application , but
$c-MY_CONSTANT is just as easy!
Many thanks for all the input and help, it really is appreciated.
-Original Message-
From: Lukas Thiemeier [mailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 13:56
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
Hi Craig,
Writing helpers in your main App.pm and using roles is not either-or.
Roles are one possibility to modify your classes in a reusable way.
If your helpers are really global, which means that they are used by all, or
almost all your controllers, I would put them into your main application class.
If you have more than one application which make use of the same
helpers: Put them into a role:
YourHelperRole.pm:
package YourHelperRole;
use Moose::Role;
has some_attribute = ( ... ); # if you need attributes
sub helpermethod1{
my ($self, $other, $args) = @_;
do_something();
}
sub helpermethod2{
my ($self, $other, $args) = @_;
do_something_different();
}
no Moose::Role; # or use namespace::autoclean or MooseX::MarkAsMethod
1;
App.pm:
use Catalyst qw( ... );
extends Catalyst;
with qw/YourHelperRole/;
...
In my opinion, extending your main App.pm with roles is only useful if you need
the same helpers in different locations, too.
If you only need them for that single application, avoid the overhead related
to using roles.
If you have helpers which are only needed by some controllers, create a role
for your controllers. You can not only implement helpers in you roles, you can
also create method-modifiers, which change the way your methods behave.
Here is an example, which writes sth to the log, after the delete
method was called:
YourLogRole.pm:
package YourLogRole;
use Moose::Role;
requires qw/delete/; #die if the consuming class has no delete
after delete = sub{
my ($self, $c) = @_;
$c-log-debug(DELETE called);
};
no Moose::Role;
1;
Controller1.pm: (has the helpers, but no logging)
package Controller1;
use Moose;
extends Catalyst::Controller;
with qw/
YourHelperRole
/;
sub someaction :Local {
my ($self, $c) =@_;
$self-helpermethod1();
}
...
Controller2.pm: (has helpers AND logging)
package Controller2;
use Moose;
extends Catalyst::Controller;
with qw/
YourLogRole
YourHelperRole
/;
sub delete :Local :Args(1) { ... }
Controller3.pm (has logging, but no helpers)
package Controller3;
use Moose;
extends Catalyst::Controller;
with qw/
YourLogRole
/;
sub delete :Local :Args(1) { ... }
Roles are very powerful tools. I use them a lot.
Read the Moose docs for more information.
If you don't want to learn Moose, roles and so on now, just remember:
1. write sth in a role
2. consume the role in a moose class, using with
3. your roles methods and attributes will be available in the consuming class
Lukas
On 10/30/2012 02:03 PM, Craig Chant wrote:
Hi,
Please could you advise the best way of having a global 'helper' class
that has all commonly used methods in it accessible for any part of
the catalyst app.
I found this thread
http://stackoverflow.com/questions/11941836/catalyst-global-subroutine
s
With one indicating it's ok to put them in the main MyApp.pm and
another saying to use Moose Roles.
What is considered the correct way and could you provide an example of
how I create this helper class and bolt it to the Catalyst application.
Many thanks,
*/Craig Chant/*
I.T. Manager
Description: cid:image001.png@01CD5F4A.17E848D0
Main Line01903 602664
Direct Line 01903 227753
Visit our website http://www.homeloanpartnership.com
*HomeLoan Partnership have been named the Best Mortgage Network, 2012,
at the myintroducer.com Industry Awards*
This Email and any attachments contain confidential information and is
intended solely for the individual to whom it is addressed. If this
Email has been misdirected, please notify the author as soon as
possible. If you are not the intended recipient you must not disclose,
distribute, copy, print or rely on any of the information contained,
and all copies must be deleted immediately. Whilst we take reasonable
steps to try to identify any software viruses, any attachments to this
e-mail may nevertheless contain viruses, which our anti-virus software
has failed to identify. You should therefore carry out your own
anti-virus checks before opening any documents. HomeLoan Partnership
will not accept any liability for damage caused by computer viruses
emanating from any attachment or other document supplied with this e-mail.
HomeLoan Partnership reserves the right to monitor and archive all
e-mail communications through its
Re: [Catalyst] Global 'helper' methods
You can also define your constants in YourApp/Constants.pl, and use
YourApp::Constants wherever you need them.
YourApp/Constants.pm:
use constant { FOO = 1 };
1;
Controller.pm:
use YourApp::Constants;
# and in some method
...
my $global_foo = FOO;
There might be a better way, but this works...
For handling dates, I recommend DateTime, available on cpan:
Another reason to use DBIC:
DBIx::Class::Inflatecolumn::DateTime automatically transforms dates
stored in a database into a DateTime object, which can be used like this:
my $uk_string = $datetime-dmy('/');
my $us_string = $datetime-ymd('-');
But DateTime is not related to DBIC, DBIC just makes using it easy.
Use it if you have to work with dates a lot. It has lots of methods for
outputting dates, times or both in different formats, and it allows
datetime-math...
On 10/30/2012 03:39 PM, Craig Chant wrote:
Well I opted for putting my globals (methods and constants) in MyApp.pm
It's working grand with $c-myMethod or $c-MY_CONSTANT
I use to have them working as a bareword within my application , but
$c-MY_CONSTANT is just as easy!
Many thanks for all the input and help, it really is appreciated.
-Original Message-
From: Lukas Thiemeier [mailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 13:56
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
Hi Craig,
Writing helpers in your main App.pm and using roles is not either-or.
Roles are one possibility to modify your classes in a reusable way.
If your helpers are really global, which means that they are used by all, or
almost all your controllers, I would put them into your main application
class.
If you have more than one application which make use of the same
helpers: Put them into a role:
YourHelperRole.pm:
package YourHelperRole;
use Moose::Role;
has some_attribute = ( ... ); # if you need attributes
sub helpermethod1{
my ($self, $other, $args) = @_;
do_something();
}
sub helpermethod2{
my ($self, $other, $args) = @_;
do_something_different();
}
no Moose::Role; # or use namespace::autoclean or MooseX::MarkAsMethod
1;
App.pm:
use Catalyst qw( ... );
extends Catalyst;
with qw/YourHelperRole/;
...
In my opinion, extending your main App.pm with roles is only useful if you
need the same helpers in different locations, too.
If you only need them for that single application, avoid the overhead
related to using roles.
If you have helpers which are only needed by some controllers, create a role
for your controllers. You can not only implement helpers in you roles, you
can also create method-modifiers, which change the way your methods behave.
Here is an example, which writes sth to the log, after the delete
method was called:
YourLogRole.pm:
package YourLogRole;
use Moose::Role;
requires qw/delete/; #die if the consuming class has no delete
after delete = sub{
my ($self, $c) = @_;
$c-log-debug(DELETE called);
};
no Moose::Role;
1;
Controller1.pm: (has the helpers, but no logging)
package Controller1;
use Moose;
extends Catalyst::Controller;
with qw/
YourHelperRole
/;
sub someaction :Local {
my ($self, $c) =@_;
$self-helpermethod1();
}
...
Controller2.pm: (has helpers AND logging)
package Controller2;
use Moose;
extends Catalyst::Controller;
with qw/
YourLogRole
YourHelperRole
/;
sub delete :Local :Args(1) { ... }
Controller3.pm (has logging, but no helpers)
package Controller3;
use Moose;
extends Catalyst::Controller;
with qw/
YourLogRole
/;
sub delete :Local :Args(1) { ... }
Roles are very powerful tools. I use them a lot.
Read the Moose docs for more information.
If you don't want to learn Moose, roles and so on now, just remember:
1. write sth in a role
2. consume the role in a moose class, using with
3. your roles methods and attributes will be available in the consuming class
Lukas
On 10/30/2012 02:03 PM, Craig Chant wrote:
Hi,
Please could you advise the best way of having a global 'helper' class
that has all commonly used methods in it accessible for any part of
the catalyst app.
I found this thread
http://stackoverflow.com/questions/11941836/catalyst-global-subroutine
s
With one indicating it's ok to put them in the main MyApp.pm and
another saying to use Moose Roles.
What is considered the correct way and could you provide an example of
how I create this helper class and bolt it to the Catalyst application.
Many thanks,
*/Craig Chant/*
I.T. Manager
Description: cid:image001.png@01CD5F4A.17E848D0
Main Line01903 602664
Direct Line 01903 227753
Visit our website http://www.homeloanpartnership.com
*HomeLoan Partnership have been named
Re: [Catalyst] Global 'helper' methods
On Tue, Oct 30, 2012 at 7:03 AM, Craig Chant
cr...@homeloanpartnership.comwrote:
So it seems it’s OK to whack them in the main MyApp.pm , here is an
example of what is currently in a ‘MemberGlobs.pm’, which is ‘required’ in
90% of all the perl scripts.
Be careful with that approach. I'd stick with method that need to get
inserted into the request cycle -- not just a catch-all for something you
don't know where it really belongs.
##
# Yank Date #
##
sub YankDate {
#_[0] = UK Date
# split to parts
my @dte = split(/\//, $_[0]);
Where does $_ come from? Now might be a good time to start using
PerlCritic because it's a pain later to try and clean up code.
# rebuild to yank date
my $yank = $dte[2]-$dte[1]-$dte[0];
Where's this date coming from? The database? Look at inflating all dates
and times to DateTime objects.
Then the rendering of that object becomes a View issue.
How do you see the timezone? That's also a rendering/View issue.
It's not pretty, but what I tend to do in the View (say, in a Template) is:
Event Time: [% set_user_time_zone( event.start_time ).strftime( loc(
'_time_with_zone' ) ) %]
set_user_time_zone clones the DateTime object and sets the timezone and
locale on the DateTime objet. The _time_with_zone is a string that gets
translated -- although mostly to %c, %x, and %X. But, by using
localization it can be anything.
# return result
$yank;
Yes, check out PerlCritic.
}
I’m forever having to switch between UK dates and USA dates so have helper
methods.
See above.
Where do these go?
Also where do you put application global constants?
Not a clear line, but you have an app config for app-specific config. But,
I also have App::Constants that export constats which is useful for when
you need the constants outside of Catalyst.
--
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Global 'helper' methods
Thanks Lukas,
I appreciate there is DateTime , though I have so much legacy code that uses my
helper class re-writing everything will be a mammoth task.
I hand rolled a lot when I first started out with Perl, didn't know much about
CPAN or PPM, and couldn't load any modules that weren't part of the core
install on the original 'shared' hosting I was using.
Plus I always felt loading an entire module to re-arrange a tiny string seems a
bit OTT?
Dunno, what's the overhead of DateTime?
Craig.
-Original Message-
From: Lukas Thiemeier [mailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 14:52
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
You can also define your constants in YourApp/Constants.pl, and use
YourApp::Constants wherever you need them.
YourApp/Constants.pm:
use constant { FOO = 1 };
1;
Controller.pm:
use YourApp::Constants;
# and in some method
...
my $global_foo = FOO;
There might be a better way, but this works...
For handling dates, I recommend DateTime, available on cpan:
Another reason to use DBIC:
DBIx::Class::Inflatecolumn::DateTime automatically transforms dates stored in a
database into a DateTime object, which can be used like this:
my $uk_string = $datetime-dmy('/');
my $us_string = $datetime-ymd('-');
But DateTime is not related to DBIC, DBIC just makes using it easy.
Use it if you have to work with dates a lot. It has lots of methods for
outputting dates, times or both in different formats, and it allows
datetime-math...
On 10/30/2012 03:39 PM, Craig Chant wrote:
Well I opted for putting my globals (methods and constants) in
MyApp.pm
It's working grand with $c-myMethod or $c-MY_CONSTANT
I use to have them working as a bareword within my application , but
$c-MY_CONSTANT is just as easy!
Many thanks for all the input and help, it really is appreciated.
-Original Message-
From: Lukas Thiemeier [mailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 13:56
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
Hi Craig,
Writing helpers in your main App.pm and using roles is not either-or.
Roles are one possibility to modify your classes in a reusable way.
If your helpers are really global, which means that they are used by all, or
almost all your controllers, I would put them into your main application
class.
If you have more than one application which make use of the same
helpers: Put them into a role:
YourHelperRole.pm:
package YourHelperRole;
use Moose::Role;
has some_attribute = ( ... ); # if you need attributes
sub helpermethod1{
my ($self, $other, $args) = @_;
do_something();
}
sub helpermethod2{
my ($self, $other, $args) = @_;
do_something_different();
}
no Moose::Role; # or use namespace::autoclean or MooseX::MarkAsMethod
1;
App.pm:
use Catalyst qw( ... );
extends Catalyst;
with qw/YourHelperRole/;
...
In my opinion, extending your main App.pm with roles is only useful if you
need the same helpers in different locations, too.
If you only need them for that single application, avoid the overhead
related to using roles.
If you have helpers which are only needed by some controllers, create a role
for your controllers. You can not only implement helpers in you roles, you
can also create method-modifiers, which change the way your methods behave.
Here is an example, which writes sth to the log, after the delete
method was called:
YourLogRole.pm:
package YourLogRole;
use Moose::Role;
requires qw/delete/; #die if the consuming class has no delete
after delete = sub{
my ($self, $c) = @_;
$c-log-debug(DELETE called);
};
no Moose::Role;
1;
Controller1.pm: (has the helpers, but no logging)
package Controller1;
use Moose;
extends Catalyst::Controller;
with qw/
YourHelperRole
/;
sub someaction :Local {
my ($self, $c) =@_;
$self-helpermethod1();
}
...
Controller2.pm: (has helpers AND logging)
package Controller2;
use Moose;
extends Catalyst::Controller;
with qw/
YourLogRole
YourHelperRole
/;
sub delete :Local :Args(1) { ... }
Controller3.pm (has logging, but no helpers)
package Controller3;
use Moose;
extends Catalyst::Controller;
with qw/
YourLogRole
/;
sub delete :Local :Args(1) { ... }
Roles are very powerful tools. I use them a lot.
Read the Moose docs for more information.
If you don't want to learn Moose, roles and so on now, just remember:
1. write sth in a role
2. consume the role in a moose class, using with
3. your roles methods and attributes will be available in the
consuming class
Lukas
On 10/30/2012 02:03 PM, Craig Chant wrote:
Hi,
Please could you advise the best way of having a global 'helper'
class that has all commonly used methods
Re: [Catalyst] Global 'helper' methods
Hm... how to measure the overhead of a module?
There is a XS version of the module which is used if you have a C
compiler. I don't know the exact overhead, but I know that it is fast.
I have no experience with the pure perl version of that module.
If all you have to do with the dates is the simple string transformation
you are right. As I said before: I recommend to use DT if you are
working with dates a lot. Doing math on dates and times is annoying,
because of leap years, epochs, timezones and so on. If you need this:
Using DateTime is recommended. If not: Its not :)
If you are ONLY using pure perl modules:
You can include all required modules in your distribution. It should run
on any perl installation, even in a shared host environment.
App::FatPacker helps you doing this...
But this doesn't work as soon as you use XS modules.
On 10/30/2012 04:03 PM, Craig Chant wrote:
Thanks Lukas,
I appreciate there is DateTime , though I have so much legacy code that uses
my helper class re-writing everything will be a mammoth task.
I hand rolled a lot when I first started out with Perl, didn't know much
about CPAN or PPM, and couldn't load any modules that weren't part of the
core install on the original 'shared' hosting I was using.
Plus I always felt loading an entire module to re-arrange a tiny string seems
a bit OTT?
Dunno, what's the overhead of DateTime?
Craig.
-Original Message-
From: Lukas Thiemeier [mailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 14:52
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
You can also define your constants in YourApp/Constants.pl, and use
YourApp::Constants wherever you need them.
YourApp/Constants.pm:
use constant { FOO = 1 };
1;
Controller.pm:
use YourApp::Constants;
# and in some method
...
my $global_foo = FOO;
There might be a better way, but this works...
For handling dates, I recommend DateTime, available on cpan:
Another reason to use DBIC:
DBIx::Class::Inflatecolumn::DateTime automatically transforms dates stored in
a database into a DateTime object, which can be used like this:
my $uk_string = $datetime-dmy('/');
my $us_string = $datetime-ymd('-');
But DateTime is not related to DBIC, DBIC just makes using it easy.
Use it if you have to work with dates a lot. It has lots of methods for
outputting dates, times or both in different formats, and it allows
datetime-math...
On 10/30/2012 03:39 PM, Craig Chant wrote:
Well I opted for putting my globals (methods and constants) in
MyApp.pm
It's working grand with $c-myMethod or $c-MY_CONSTANT
I use to have them working as a bareword within my application , but
$c-MY_CONSTANT is just as easy!
Many thanks for all the input and help, it really is appreciated.
-Original Message-
From: Lukas Thiemeier [mailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 13:56
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
Hi Craig,
Writing helpers in your main App.pm and using roles is not either-or.
Roles are one possibility to modify your classes in a reusable way.
If your helpers are really global, which means that they are used by all, or
almost all your controllers, I would put them into your main application
class.
If you have more than one application which make use of the same
helpers: Put them into a role:
YourHelperRole.pm:
package YourHelperRole;
use Moose::Role;
has some_attribute = ( ... ); # if you need attributes
sub helpermethod1{
my ($self, $other, $args) = @_;
do_something();
}
sub helpermethod2{
my ($self, $other, $args) = @_;
do_something_different();
}
no Moose::Role; # or use namespace::autoclean or MooseX::MarkAsMethod
1;
App.pm:
use Catalyst qw( ... );
extends Catalyst;
with qw/YourHelperRole/;
...
In my opinion, extending your main App.pm with roles is only useful if you
need the same helpers in different locations, too.
If you only need them for that single application, avoid the overhead
related to using roles.
If you have helpers which are only needed by some controllers, create a role
for your controllers. You can not only implement helpers in you roles, you
can also create method-modifiers, which change the way your methods behave.
Here is an example, which writes sth to the log, after the delete
method was called:
YourLogRole.pm:
package YourLogRole;
use Moose::Role;
requires qw/delete/; #die if the consuming class has no delete
after delete = sub{
my ($self, $c) = @_;
$c-log-debug(DELETE called);
};
no Moose::Role;
1;
Controller1.pm: (has the helpers, but no logging)
package Controller1;
use Moose;
extends Catalyst::Controller;
with qw/
YourHelperRole
/;
sub someaction :Local {
my ($self, $c) =@_;
$self
RE: [Catalyst] Global 'helper' methods
Hi Hugh,
I assume this is for Apache and I'm running IIS7, so I guess it isn't
compatible?
It looks like I've been having performance problems because millions of rows
get blessed into objects, not sure of this but it looks like a DBIC thing at
the moment.
That's not good, and is part of the issue of ORM (so I've read), I'm not as
old as you, but I'm still old school, get only the columns and rows you need
when you need them, well that's my take on it and it seems to work for me.
Regards,
Craig.
From: Hugh Barnard [mailto:hugh.barn...@gmail.com]
Sent: 30 October 2012 15:47
To: The elegant MVC web framework
Subject: Re: [Catalyst] Global 'helper' methods
Hi
On measurement in general, I'd recommend: Devel::NYTProf::Apache ; there's a
write up here:
http://www.slideshare.net/bobcatfish/profiling-with-develnytprof
I'm dealing with a largish Catalyst/mod_perl thing at the moment and it's been
tremendously helpful. One tip is that it is very picky about closing the files
that it needs to compile the profiles, I write these into /tmp and then crunch
them with the command line tools.
Incidentally, I am 62 and therefore pretty old-skool and not mad for
ORM-everywhere. It looks like I've been having performance problems because
millions of rows get blessed into objects, not sure of this but it looks like a
DBIC thing at the moment. Currently I've 'cursor'-ed them:
my $cursor = $entries-cursor;
while ( my @row_values = $cursor-next ) {
and that seems to give some improvements in that area...
Best regards Hugh
On 30 October 2012 15:24, Lukas Thiemeier
spamcatc...@thiemeier.netmailto:spamcatc...@thiemeier.net wrote:
Hm... how to measure the overhead of a module?
There is a XS version of the module which is used if you have a C
compiler. I don't know the exact overhead, but I know that it is fast.
I have no experience with the pure perl version of that module.
If all you have to do with the dates is the simple string transformation
you are right. As I said before: I recommend to use DT if you are
working with dates a lot. Doing math on dates and times is annoying,
because of leap years, epochs, timezones and so on. If you need this:
Using DateTime is recommended. If not: Its not :)
If you are ONLY using pure perl modules:
You can include all required modules in your distribution. It should run
on any perl installation, even in a shared host environment.
App::FatPacker helps you doing this...
But this doesn't work as soon as you use XS modules.
On 10/30/2012 04:03 PM, Craig Chant wrote:
Thanks Lukas,
I appreciate there is DateTime , though I have so much legacy code that uses
my helper class re-writing everything will be a mammoth task.
I hand rolled a lot when I first started out with Perl, didn't know much
about CPAN or PPM, and couldn't load any modules that weren't part of the
core install on the original 'shared' hosting I was using.
Plus I always felt loading an entire module to re-arrange a tiny string seems
a bit OTT?
Dunno, what's the overhead of DateTime?
Craig.
-Original Message-
From: Lukas Thiemeier
[mailto:spamcatc...@thiemeier.netmailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 14:52
To: catalyst@lists.scsys.co.ukmailto:catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
You can also define your constants in YourApp/Constants.pl, and use
YourApp::Constants wherever you need them.
YourApp/Constants.pm:
use constant { FOO = 1 };
1;
Controller.pm:
use YourApp::Constants;
# and in some method
...
my $global_foo = FOO;
There might be a better way, but this works...
For handling dates, I recommend DateTime, available on cpan:
Another reason to use DBIC:
DBIx::Class::Inflatecolumn::DateTime automatically transforms dates stored in
a database into a DateTime object, which can be used like this:
my $uk_string = $datetime-dmy('/');
my $us_string = $datetime-ymd('-');
But DateTime is not related to DBIC, DBIC just makes using it easy.
Use it if you have to work with dates a lot. It has lots of methods for
outputting dates, times or both in different formats, and it allows
datetime-math...
On 10/30/2012 03:39 PM, Craig Chant wrote:
Well I opted for putting my globals (methods and constants) in
MyApp.pm
It's working grand with $c-myMethod or $c-MY_CONSTANT
I use to have them working as a bareword within my application , but
$c-MY_CONSTANT is just as easy!
Many thanks for all the input and help, it really is appreciated.
-Original Message-
From: Lukas Thiemeier
[mailto:spamcatc...@thiemeier.netmailto:spamcatc...@thiemeier.net]
Sent: 30 October 2012 13:56
To: catalyst@lists.scsys.co.ukmailto:catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Global 'helper' methods
Hi Craig,
Writing helpers in your main App.pm and using roles is not either-or.
Roles are one possibility to modify your classes in a reusable way.
If your helpers are really
Re: [Catalyst] Global 'helper' methods
Perhaps it is feasible for you to bypass object inflation. 1) DBIx::Class is not built for speed, it's built for convenience and ease of use, but sometimes you just need to get the data, and skip the fancy objects. http://search.cpan.org/~frew/DBIx-Class-0.08200/lib/DBIx/Class/Manual/Cookbook.pod#Skip_row_object_creation_for_faster_results 2) If the HashRefInflator solution above is not fast enough for you, you can use a DBIx::Class to return values exactly as they come out of the database http://search.cpan.org/~frew/DBIx-Class-0.08200/lib/DBIx/Class/Manual/Cookbook.pod#Get_raw_data_for_blindingly_fast_results ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Global 'helper' methods
On 30 Oct 2012, at 14:03, Craig Chant wrote: So it seems it’s OK to whack them in the main MyApp.pm , here is an example of what is currently in a ‘MemberGlobs.pm’, which is ‘required’ in 90% of all the perl scripts. snip I’m forever having to switch between UK dates and USA dates so have helper methods. Where do these go? The example function was immutable, and side effect free. As such, it's purely functional, and thus I'd import it (i.e. write a module which just exported functions, and export it from there). Also where do you put application global constants? How constant is constants? If it's configurable, it comes from the config file! If it's a real constant (as per the functions above), same situation applies. However, I'd suggest that if you need functions such as this, your entire approach is broken! You should be inflating all dates and times into DateTime objects, and then using a correctly configured DateTime::Formatter::XXX to format them as appropriate for the output context. This would mean that you'd set the date format generically for a user / page / whatever granularity you want, and you'd do conversion in one or two places - thus supporting the DRY principle, and allowing you to be much more flexible in future, when you need other date/time output formats. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Global 'helper' methods
On 30 Oct 2012, at 14:39, Craig Chant wrote: Well I opted for putting my globals (methods and constants) in MyApp.pm It's working grand with $c-myMethod or $c-MY_CONSTANT I use to have them working as a bareword within my application , but $c-MY_CONSTANT is just as easy! It's also several times slower :) Unless they are methods (which use state) or constants which are really config, they're really better off in a function based style. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Global 'helper' methods
On 30 Oct 2012, at 15:03, Craig Chant wrote: Plus I always felt loading an entire module to re-arrange a tiny string seems a bit OTT? Yes, it is :) If you know that re-arranging a string is all you're ever going to be doing, then sure - don't' do that.. However, usually when you're dealing with the US, then you're _also_ dealing with a time zone offset, right? You don't want to only show local format dates, but also local time zones. As a case in point, right now (for this working week), we're out of daylight savings time in the UK, however they're still in daylight savings times on the east of the US… I for one do not want to care about this sort of stuff, ever. Dunno, what's the overhead of DateTime? Significantly less than the overhead of caring about time zones, ever. :-D If you're only doing day resolution (or only UTC), it's less convincing… But basically, I wouldn't care unless it specifically shows up as slow in a real profile - premature optimisation is the root of all evil, etc. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Global 'helper' methods
On 30 Oct 2012, at 15:47, Hugh Barnard wrote: Hi On measurement in general, I'd recommend: Devel::NYTProf::Apache ; there's a write up here: http://www.slideshare.net/bobcatfish/profiling-with-develnytprof ++ Personally, I'd not be using mod_perl if I could help it, but NYTProf is awesome! . It looks like I've been having performance problems because millions of rows get blessed into objects, not sure of this but it looks like a DBIC thing at the moment. Inflating a million objects is costly. Are you really building an HTML page with a million rows? If so, why (isn't paging a better solution?) I.e. I'd generally say you should either paginate things, or make the query return an aggregate set of results by doing the math or whatever at the DB server. However, if you really do need to re-inflate a lot of stuff, look at DBIx::Class::ResultClass::HashRefInflator - given you only want the raw data and none of the clever, this is much much faster :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
