Re: [Catalyst] Re: Detach won't detach?
--
Jonas
2009/1/28 Jonathan Rockway j...@jrock.us
* On Tue, Jan 27 2009, pie3...@comcast.net wrote:
Why not
sub auto :Private {
my $c = pop;
return user_logged_in || $c-res-redirect( ... );
}
Because now the correctness of your application depends on undocumented
behavior (the return value of $c-res-redirect).
With $c-res-redirect || 0 you are already depending on $c-res-redirect
return value. So what's the difference?
--
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] Patch for Catalyst::Plugin::Unicode::Encoding
On Tue, Mar 18, 2008 at 11:01 AM, Bill Moseley [EMAIL PROTECTED] wrote:
On Tue, Mar 18, 2008 at 03:38:06AM -0500, Jonathan Rockway wrote:
* On Tue, Mar 18 2008, Bill Moseley wrote:
The plugin decodes all parameters using:
$_ = $c-encoding-decode( $_, $CHECK ) for ( ref($value) ?
@{$value} : $value );
I'd think it would be wise to check to see if the string is already
decoded:
for ( ref($value) ? @{$value} : $value ) {
next if Encode::is_utf8($_);
$_ = $c-encoding-decode( $_, $CHECK );
}
Never check is_utf8. Encode will do the right thing regardless of
the internal representation of the string.
This is decoding, not encoding.
Without testing is_utf8 and if the parameters are already decoded I
rightly get:
[error] Caught exception in engine Cannot decode string with wide
characters at
/usr/local/share/perl/5.8.8/Catalyst/Plugin/Unicode/Encoding.pm
line 74.
http://blog.jrock.us/articles/Fuck%20the%20internal%20representation.pod
Yes, checking is_ut8 before encoding doesn't make sense.
No, you never should check the flag. See Miyagawa's post
http://use.perl.org/~miyagawa/journal/35700.
--
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] exceptions and chained actions
On Tue, Mar 11, 2008 at 4:12 PM, Dami Laurent (PJ) [EMAIL PROTECTED] wrote: Hi Catalysters, It seems that if an exception is raised in the entry point to an action chain, Catalyst still tries to forward to the other chain components, accumulating all exceptions into $c-errors. Is there a way to stop the chain at the first exception ? Thanks in advance, Laurent Dami Probably you need to catch it and call detach. -- 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] Catalyst, REST and Firefox
On Jan 18, 2008 8:46 PM, Adam Jacob [EMAIL PROTECTED] wrote: Jonas, Myself, Jshirley, or Claco would gladly take patches to C::A::REST to add this functionality. Send us the patch, and we'll get it tested and out the door. Adam Hi Adam, I started to write a patch some time ago, just need some docs and tests. But right now I don't have time to finish it. Maybe next week. :) -- 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] 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] PathPart help
On 11/16/07, Jason Kohles [EMAIL PROTECTED] wrote:
On Nov 16, 2007, at 11:11 AM, Christopher H. Laco wrote:
sub has_user : Chained('id|name|email') NoPathPart CaptureArgs(0) { }
sub edit : Chained('has_user') PathPart('edit') Args(0) { }
That NoPathPart you already have with an empty PathPart('').
--
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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Directory layout
On 11/8/07, Gerda Shank [EMAIL PROTECTED] wrote: Thanks for the responses to my question about the View Directory. I'm still trying to figure out the reasons for the rest of the directory layout. The templates are not in the View directory, because the lib hierarchy is just for Perl code. Is that right? Is root kind of the equivalent of htdocs? What else would go in the static subdirectory besides images? Would you put css files in here? Does javascript go in static, or does it get a directory underneath root? Are any parts of the layout created by catalyst.pl changeable, or would it break Catalyst to rename them? If, for example, root was changed to htdocs, or you didn't use the static directory? Sorry for all the questions. I've been studying the documentation, but haven't had much like finding explanations for these things, and I'm not sure where to look in the code. Thanks, Gerda Shank I put all my static files under static. Usually I have a directory structure like this: root/static/ root/static/js root/static/css root/static/images -- 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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
