Re: [Catalyst] Documentation on DBIx Class
On 16 Jan 2008, at 07:54, Peter Sørensen wrote: Now I've come across Catalyst and DBIx. *cough* DBIC :) -- Mike Whitaker - [EMAIL PROTECTED] ___ 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] TT VMethods
Also the CPAN module
Template::Plugin::Comma
can be used for doing this.
Octavian
- Original Message -
From: Mitchell Jackson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 13, 2007 4:35 AM
Subject: [Catalyst] TT VMethods
Today I saw how easy it is to extend Template-Toolkit within Catalyst.
Perhaps somebody here will find this useful.
I wanted to easily format dollar amounts from within the tt2 template. I
had been doing this with [% FILTER format( %.2f ) %], but having
FILTER/END everywhere seemed a bit annoying, and I wanted to add commas to
make the data easier to read on large numbers.
In Catalyst, you can add extensions to Template from your app's lib
directory. You can add filters ( Template::Plugin::Filter ) and VMethods
( Template::Plugin::VMethods ) simply by putting them into
MyApp/lib/Template/Plugin
Following is an example that adds a 'commify' method to any scalar
template variable. [% var.commify %] to add seperating commas, [%
var.commify(2) %] to add commas and round to two decimal places
/Mitch
OnSite Mobile
#MyApp/lib/Template/Plugin/commify.pm
package Template::Plugin::commify;
use Template::Plugin::VMethods;
use base qw(Template::Plugin::VMethods);
@SCALAR_OPS = qw(commify);
=head1 commify
VMethod extension to format a number with pretty commas each 3rd digit,
and to specify decimal precision
Template Syntax:
[% USE commify %]
[% test = '1234567890.983457' %]
[% test.commify%] 1,234,567,890.983457
[% test.commify(2) %] 1,234,567,890.98
=cut
sub commify {
my ( $data, $precision ) = @_;
my $decimals;
# don't do anything to the data if it doesn't look like a number
return $data
if $data !~ /^\d+(?:\.\d+)$/;
# round to the specified precision
$data = sprintf %.${precision}f, $data
if defined $precision;
# detach the decimals, we don't want commas there
$decimals = $1 if $data =~ s/(\.\d+)//;
# insert commas
$data =~ s/(\d{1,3})(?=(?:\d\d\d)+(?!\d))/$1,/g;
# reattach decimals
$data .= $decimals if defined $decimals;
$data;
}
1;
___
List: [EMAIL PROTECTED]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.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] TT VMethods
different country, different separators :-) e.g: 10,000.00 is ten thousand in the usa 10.000,00 is ten thousand in germany Am 17.01.2008 um 15:42 schrieb Chisel Wright: On Thu, Jan 17, 2008 at 01:14:22PM +0100, Moritz Onken wrote: please implement localization (different separators) Huh? -- Chisel Wright e: [EMAIL PROTECTED] w: http://www.herlpacker.co.uk/ I even make myself laugh sometimes... ___ 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/ ___ 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] Catalyst, REST and Firefox
Jonas Alves wrote:
On Jan 17, 2008 2:32 PM, Christopher H. Laco [EMAIL PROTECTED] wrote:
I've touched on this before, and posted about it on UP:
http://use.perl.org/~jk2addict/journal/35411
In a nutshell, Firefox 2.x Accept header totaly screws with the REST
controller when you use it as a base for View negotiations. If you have
a default type of text/html pointed to a View::TT, REST will see
text/xml from Firefox and try and send that instead, based on this header:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
What does everyone think about a config option/toggle to tell REST to
ignore the Accept header, allowing it to fall back to the default
content-type in config when no Cntent-Type header or content-type params
are specified?
-=Chris
I have a subclass of Action::Serialize that does this:
my $default = $controller-config-{serialize}{default};
my $pcontent_type = $c-req-preferred_content_type;
my $content_types = $c-req-accepted_content_types_qvalue;
my $ordered_content_types = $c-req-accepted_content_types;
my $max_qvalue = $content_types-{$pcontent_type};
my %max_qvalue_content_types = map {
$content_types-{$_} eq $max_qvalue ? ($_ = $default) : ()
} keys %$content_types;
my $content_type = $max_qvalue_content_types{$default}
|| $pcontent_type
|| $c-req-content_type;
And in a subclass of Request::REST mixed with Plugin::Flavour:
sub preferred_content_type {
my $self = shift;
if ($self-flavour) {
my $type = $self-{ext_map}{$self-flavour}
|| $self-_ext_to_type($self-flavour);
return $type;
}
$self-accepted_content_types-[0];
}
sub accepted_content_types_qvalue {
my $self = shift;
return $self-{content_types_qvalue} if $self-{content_types_qvalue};
my %types;
if ($self-method eq GET $self-param('content-type')) {
$types{ $self-param('content-type') } = 2;
}
# This is taken from chansen's Apache2::UploadProgress.
if ( $self-header('Accept') ) {
$self-accept_only(1) unless keys %types;
my $accept_header = $self-header('Accept');
my $counter = 0;
foreach my $pair ( split_header_words($accept_header) ) {
my ( $type, $qvalue ) = @{$pair}[ 0, 3 ];
next if $types{$type};
$qvalue = 1 unless defined $qvalue;
$types{$type} = sprintf '%.3f', $qvalue;
}
}
return $self-{content_types_qvalue} = \%types;
}
That way all works fine. If you add an extension to the uri (like
.json or .xml), it serves that content-type. Else it tries to find the
greater qvalue on the Accept Header and tries to serve that. If it has
more than one content-type with the same max qvalue it tries to find
the default content-type in that list and serve it. If it isn't in the
max qvalue list than it serves the first content-type on that list.
I think that is a sane approach.
Well volunteered! I can't speak for the flavour stuff, but I'd think the
q value logic would be well served in the REST package. :-)
I'd personally like the flavour stuff in there as well. In my case, I'm
half way there. I have a type= that takes a friendly name (atom, rss,
json) ... along wieh adding some of those content types to MIME::Types
since it's missing a few of them for type-extension mapping.
-=Chris
signature.asc
Description: OpenPGP digital signature
___
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] Catalyst, REST and Firefox
At 12:03 PM 1/17/2008, Christopher H. Laco wrote:
Jonas Alves wrote:
On Jan 17, 2008 2:32 PM, Christopher H. Laco [EMAIL PROTECTED] wrote:
I've touched on this before, and posted about it on UP:
http://use.perl.org/~jk2addict/journal/35411
In a nutshell, Firefox 2.x Accept header totaly screws with the REST
controller when you use it as a base for View negotiations. If you have
a default type of text/html pointed to a View::TT, REST will see
text/xml from Firefox and try and send that instead, based on this header:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
What does everyone think about a config option/toggle to tell REST to
ignore the Accept header, allowing it to fall back to the default
content-type in config when no Cntent-Type header or content-type params
are specified?
-=Chris
I have a subclass of Action::Serialize that does this:
my $default = $controller-config-{serialize}{default};
my $pcontent_type = $c-req-preferred_content_type;
my $content_types = $c-req-accepted_content_types_qvalue;
my $ordered_content_types = $c-req-accepted_content_types;
my $max_qvalue = $content_types-{$pcontent_type};
my %max_qvalue_content_types = map {
$content_types-{$_} eq $max_qvalue ? ($_ = $default) : ()
} keys %$content_types;
my $content_type = $max_qvalue_content_types{$default}
|| $pcontent_type
|| $c-req-content_type;
And in a subclass of Request::REST mixed with Plugin::Flavour:
sub preferred_content_type {
my $self = shift;
if ($self-flavour) {
my $type = $self-{ext_map}{$self-flavour}
|| $self-_ext_to_type($self-flavour);
return $type;
}
$self-accepted_content_types-[0];
}
sub accepted_content_types_qvalue {
my $self = shift;
return $self-{content_types_qvalue} if $self-{content_types_qvalue};
my %types;
if ($self-method eq GET $self-param('content-type')) {
$types{ $self-param('content-type') } = 2;
}
# This is taken from chansen's Apache2::UploadProgress.
if ( $self-header('Accept') ) {
$self-accept_only(1) unless keys %types;
my $accept_header = $self-header('Accept');
my $counter = 0;
foreach my $pair ( split_header_words($accept_header) ) {
my ( $type, $qvalue ) = @{$pair}[ 0, 3 ];
next if $types{$type};
$qvalue = 1 unless defined $qvalue;
$types{$type} = sprintf '%.3f', $qvalue;
}
}
return $self-{content_types_qvalue} = \%types;
}
That way all works fine. If you add an extension to the uri (like
.json or .xml), it serves that content-type. Else it tries to find the
greater qvalue on the Accept Header and tries to serve that. If it has
more than one content-type with the same max qvalue it tries to find
the default content-type in that list and serve it. If it isn't in the
max qvalue list than it serves the first content-type on that list.
I think that is a sane approach.
Well volunteered! I can't speak for the flavour stuff, but I'd think
the q value logic would be well served in the REST package. :-)
I'd personally like the flavour stuff in there as well. In my case,
I'm half way there. I have a type= that takes a friendly name (atom,
rss, json) ... along wieh adding some of those content types to
MIME::Types since it's missing a few of them for type-extension mapping.
-=Chris
Just wanted to note that using extensions on URIs to select
content_type is a technique mentioned in the RESTful Web Services
book. I think it was touted as a way to be sure the right type was
returned. I hadn't gotten to seeing if it'd work with REST stuff
here. Color me interested ___
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] Catalyst, REST and Firefox
On Jan 17, 2008 6:03 PM, Christopher H. Laco [EMAIL PROTECTED] wrote:
Jonas Alves wrote:
On Jan 17, 2008 2:32 PM, Christopher H. Laco [EMAIL PROTECTED] wrote:
I've touched on this before, and posted about it on UP:
http://use.perl.org/~jk2addict/journal/35411
In a nutshell, Firefox 2.x Accept header totaly screws with the REST
controller when you use it as a base for View negotiations. If you have
a default type of text/html pointed to a View::TT, REST will see
text/xml from Firefox and try and send that instead, based on this header:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
What does everyone think about a config option/toggle to tell REST to
ignore the Accept header, allowing it to fall back to the default
content-type in config when no Cntent-Type header or content-type params
are specified?
-=Chris
I have a subclass of Action::Serialize that does this:
my $default = $controller-config-{serialize}{default};
my $pcontent_type = $c-req-preferred_content_type;
my $content_types = $c-req-accepted_content_types_qvalue;
my $ordered_content_types = $c-req-accepted_content_types;
my $max_qvalue = $content_types-{$pcontent_type};
my %max_qvalue_content_types = map {
$content_types-{$_} eq $max_qvalue ? ($_ = $default) : ()
} keys %$content_types;
my $content_type = $max_qvalue_content_types{$default}
|| $pcontent_type
|| $c-req-content_type;
And in a subclass of Request::REST mixed with Plugin::Flavour:
sub preferred_content_type {
my $self = shift;
if ($self-flavour) {
my $type = $self-{ext_map}{$self-flavour}
|| $self-_ext_to_type($self-flavour);
return $type;
}
$self-accepted_content_types-[0];
}
sub accepted_content_types_qvalue {
my $self = shift;
return $self-{content_types_qvalue} if $self-{content_types_qvalue};
my %types;
if ($self-method eq GET $self-param('content-type')) {
$types{ $self-param('content-type') } = 2;
}
# This is taken from chansen's Apache2::UploadProgress.
if ( $self-header('Accept') ) {
$self-accept_only(1) unless keys %types;
my $accept_header = $self-header('Accept');
my $counter = 0;
foreach my $pair ( split_header_words($accept_header) ) {
my ( $type, $qvalue ) = @{$pair}[ 0, 3 ];
next if $types{$type};
$qvalue = 1 unless defined $qvalue;
$types{$type} = sprintf '%.3f', $qvalue;
}
}
return $self-{content_types_qvalue} = \%types;
}
That way all works fine. If you add an extension to the uri (like
.json or .xml), it serves that content-type. Else it tries to find the
greater qvalue on the Accept Header and tries to serve that. If it has
more than one content-type with the same max qvalue it tries to find
the default content-type in that list and serve it. If it isn't in the
max qvalue list than it serves the first content-type on that list.
I think that is a sane approach.
Well volunteered! I can't speak for the flavour stuff, but I'd think the
q value logic would be well served in the REST package. :-)
I'd personally like the flavour stuff in there as well. In my case, I'm
half way there. I have a type= that takes a friendly name (atom, rss,
json) ... along wieh adding some of those content types to MIME::Types
since it's missing a few of them for type-extension mapping.
Well, I don't mind to help in that too. I think that the flavour stuff
is very useful. Especially if you need to use the REST interface from
some lib/framework/api where isn't easy to set the Accept header. And
I think that is much more clean than the query-string type parameter.
--
Jonas
___
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] Debugging Catalyst with Eclipse
Hello, Nathan. You write 17 2008 ., 18:37:19: I'm using Eclipse IDE + EPIC to debug my Catalyst apps. With Pad::Walker it can show values on variables even objects it's very useful to understand insides of processing) I'm using it in complex: internal browser, error output, debugger In the most of cases it helps me. What things are you interested in? P.S. Really I'm still looking for good Perl IDE, but it still very poor assortment. -- dreelmailto:[EMAIL PROTECTED] Dmitriy S. Sinyavskiy Web-developerPerl, Catalyst, MSSQL FGUE EZANTelecommunication, data transfer networks and devices. ___ 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/
