[Catalyst] Re: Default running over chained
any help? is this the correct behavior?
On Tue, Jan 26, 2010 at 5:13 PM, xenoterrac...@gmail.com
wrote:
> I added a default action to my user controller. When I access /user/ a
> chained action is supposed to run, and it ran just fine until i added the
> default action. Now the default runs instead of the chained. No index exists
> in the controller
>
> sub base :Chained('/') : PathPrefix : CaptureArgs(0) { ... }
>
> sub list : Chained('base') : PathPart('') : Args(0) { ... }
>
> sub default : Path { ... }
>
>
--
Caleb Cushing
http://xenoterracide.blogspot.com
___
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] How to de-serialize json?
On Wed, Jan 27, 2010 at 4:14 PM, Bill Moseley wrote: > I see. So you are saying that Content-Type: application/json might need to > be deserialized differently in different applications that share the same > interpreter? Obviously, json could decode into an array ref so that could > not be mapped to request parameters. Is that what you mean? Or that an > application might want the raw json? > I actually have two applications that expect and need the raw data, rather than the serialized response. In one case, it's a simple relay mechanism (unreliable system POSTs JSON feed, and reliable system then rebroadcasts it) similar to a pubsub model. It is much faster to just relay the data rather than deserialize. Another case, storing the data in something like MogileFS. I don't necessarily want to deserialize it but I do need the mime-type from the uploads. I tend to be the type that store data as I receive it, then clean it separately as needed. Half-way contrived examples, but based off of real world stuff I have done/am doing. -J ___ 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] How to de-serialize json?
Excerpts from Bill Moseley's message of Wed Jan 27 19:14:29 -0500 2010: > I see. So you are saying that Content-Type: application/json might need to > be deserialized differently in different applications that share the same > interpreter? Obviously, json could decode into an array ref so that could > not be mapped to request parameters. Is that what you mean? Or that an > application might want the raw json? Well, we know from this thread that the last one, at least, is true; you would like it to go into body_params and I wouldn't. hdp. ___ 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] How to de-serialize json?
On 28 Jan 2010, at 00:14, Bill Moseley wrote: Or that an application might want the raw json? Or that one app depends on JSON::XS doing the decoding whilst one depends on JSON.pm.. 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] How to de-serialize json?
On Wed, Jan 27, 2010 at 1:16 PM, Tomas Doran wrote: > > On 27 Jan 2010, at 15:33, Bill Moseley wrote: > >> >> No big deal. I was just curious why the HTTP::Body approach was not used >> in the existing REST/RPC modules, as that was already the place used by >> Catalyst to de-serialize the body. I thought maybe there was a reason I >> might not understood, which is why I asked. >> > > HTTP::Body isn't really structured for this - you can (and I _do_ in one of > my apps) add or override the content type handlers. > > However as it's class data, this is perl interpreter wide - which means > that two different applications with conflicting requirements can't exist in > the same mod_perl interpreter - not awesome. > I see. So you are saying that Content-Type: application/json might need to be deserialized differently in different applications that share the same interpreter? Obviously, json could decode into an array ref so that could not be mapped to request parameters. Is that what you mean? Or that an application might want the raw json? -- 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] Q: CatalystX::SimpleLogin
On 27 Jan 2010, at 12:06, Bernhard Graf wrote: I have two questions about CX::SimpleLogin: 1. Is there a "simple" way to change the settings for "redirect_after_login_uri" and "redirect_after_logout_uri" ? The 'redirect_after_logout_uri' is just a method, so you can write a method yourself to override it, but then you need code, not config. I have to admit that I'm subclassing the login controller and overriding things myself in my less trivial apps :) I just pushed 77da24b to the git repository to make redirect_after_logout_ur configureable, and 5cfa0e2 does the same for redirect_after_login_uri, assuming you're _removing_ the WithRedirect trait. 2. Why is the redirect code outsourced into a role (CX:S::TraitFor::Controller::Login::WithRedirect) when Catalyst::ActionRole::NeedsLogin errors without it? Good question. The answer is it shouldn't be. Fixed in b512d4e. I've got a couple of other bits to do later tonight or tomorrow, then I'll get a new release out. Thanks for the feedback :) 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] How to de-serialize json?
On 27 Jan 2010, at 15:33, Bill Moseley wrote: No big deal. I was just curious why the HTTP::Body approach was not used in the existing REST/RPC modules, as that was already the place used by Catalyst to de-serialize the body. I thought maybe there was a reason I might not understood, which is why I asked. HTTP::Body isn't really structured for this - you can (and I _do_ in one of my apps) add or override the content type handlers. However as it's class data, this is perl interpreter wide - which means that two different applications with conflicting requirements can't exist in the same mod_perl interpreter - not awesome. Given that the serialization/deserialization isn't hard as is (as noted elsewhere in the thread), I guess that the (potential) overlap isn't too great to be worth trying to do something about this.. 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] uri_for
On 20 Jan 2010, at 09:40, Carl Johnstone wrote:
Tomohiro Hosaka wrote:
Is this correct result?
Yes, the previous situation was a bug. Given
sub foo : Args(1) {
my ($c, $arg) = @_;
};
The URL http://127.0.0.1/foo/bar%2Fbaz would match and set $arg to
'bar/baz'
correctly. However reversing that using uri_for then returns the
incorrect
URL.
However, unfortunately - we have to provide compatibility - for
example c.uri_for('/static', 'css/crud', crud_type ) or similar
constructions were broken.
I've just fixed this in trunk so that if you have an action object
(with $c->uri_for_action, or $c->uri_for($c->action, or $c->uri_for($c-
>controller->action_for('foo') ) (as recommended to construct paths
to actions) - you *will* get the encoding for args and captures.
However passing in a set of strings to basically be concatenated to
the base uri and joined with / to produce paths will still work...
I think this is the best compromise between having round-trippable
URIs, and also maintaining compatibility for legacy applications.
If you feel differently, shout up now please :)
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/
[Catalyst] Catalyst::View::Email 0.21_1
Hi all, sorry to spam the list yet again, but I have released a development version of Catalyst::View::Email for testing and convenience. You know what to do. dhoss ___ 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/
[Catalyst] Catalyst::View::Email 0.21
Hi again all, There were some more fixes taken care of in this release. I have provided a tarball of this release before releasing it on CPAN. Please check it out here: http://dhoss.net/Catalyst-View-Email-0.21.tar.gz, test and let the list/channel (#catalyst) know if you have any issues. Thanks! dhoss ___ 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] How to de-serialize json?
On Wed, Jan 27, 2010 at 7:33 AM, Bill Moseley wrote:
>
>
> On Tue, Jan 26, 2010 at 6:33 AM, J. Shirley wrote:
>>
>>
>> I'm all for reusable code, but in no way should HTTP::Body start
>> taking this behavior by default. I'm not really that sure how
>> effective it is, anyway.
>
> No, I was not suggesting that would be the default (although I'm not sure
> why not handling other serializations by default is a bad idea). Not sure
> what you mean by "effective".
>
>>
>> decode_json( $c->req->body ); Is just not that hard :)
>
> Of course it's not that hard. Of course, this isn't hard, either: [1]
>
> map { s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg; $_ } split /[&;=]/,
> $c->req->body;
>
> I see those as similar operations. The request is serialized in both cases.
>
> But, one should not have to worry about adding low-level details like that
> to application code when using an elegant web framework. ;)
>
>
> No big deal. I was just curious why the HTTP::Body approach was not used in
> the existing REST/RPC modules, as that was already the place used by
> Catalyst to de-serialize the body. I thought maybe there was a reason I
> might not understood, which is why I asked.
>
> [1] Or whatever the correct approach is, and apologies to Damian for the
> map.
>
(Really not trying to beat a dead horse, but I think this thread does
have some useful thoughts in it so I'd like to just summarize)
Well, I think that Data::Serializer is what you are after. As far as
putting that feature directly in HTTP::Body, I'm not really sure what
it gains you since deserializing is not something you always want to
do unless your application can specify it. Decoding, however, is
something you do want regardless of application.
And if your application specifies it, then it seems reasonable to me
to put it in the framework layer. It seems like you could probably
have a request trait that could either automatically or lazily
deserialize things, and that would make everybody happy. So,
something like Catalyst::TraitFor::Request::Deserialize would be
useful. Alternatively, you could also write this as a Plack
middleware.
-J
___
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] Users, roles, HTML::FormFu::DBIx::Class::Model - complete example?
2010/1/27 Octavian Rasnita : > From: "Alex Povolotsky" >> >> Hello! >> >> Maybe someone can provide the community with complete example of >> users/roles editor with HTML::FormFu::DBIx::Class::Model? > > Are you sure this module exists? > Yes, it does exist, just under a different name :) HTML::FormFu::Model::DBIC => http://search.cpan.org/~cfranks/HTML-FormFu-Model-DBIC-0.06000/lib/HTML/FormFu/Model/DBIC.pm ___ 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] Users, roles, HTML::FormFu::DBIx::Class::Model - complete example?
From: "Alex Povolotsky" Hello! Maybe someone can provide the community with complete example of users/roles editor with HTML::FormFu::DBIx::Class::Model? Are you sure this module exists? Octavian ___ 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] How to de-serialize json?
On Tue, Jan 26, 2010 at 6:33 AM, J. Shirley wrote:
>
>
> I'm all for reusable code, but in no way should HTTP::Body start
> taking this behavior by default. I'm not really that sure how
> effective it is, anyway.
>
No, I was not suggesting that would be the default (although I'm not sure
why not handling other serializations by default is a bad idea). Not sure
what you mean by "effective".
> decode_json( $c->req->body ); Is just not that hard :)
>
Of course it's not that hard. Of course, this isn't hard, either: [1]
map { s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg; $_ } split /[&;=]/,
$c->req->body;
I see those as similar operations. The request is serialized in both cases.
But, one should not have to worry about adding low-level details like that
to application code when using an elegant web framework. ;)
No big deal. I was just curious why the HTTP::Body approach was not used in
the existing REST/RPC modules, as that was already the place used by
Catalyst to de-serialize the body. I thought maybe there was a reason I
might not understood, which is why I asked.
[1] Or whatever the correct approach is, and apologies to Damian for the
map.
--
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/
[Catalyst] Catalyst/C:M:Adaptor/Moose/Moosex::Declare bug?
Hi all, This is probably going to end up being nothing to do with catalyst but as this is where I am seeing the problem its where im starting. I have a standalone set of objects that work as expected. When I wrap these with Catalyst::Model::Adaptor for use as a model they fail with the error. http://pastebin.com/m2e87571c (this is a simple test app to highlight the problem) The cat app that generates this error is here http://tinyurl.com/y9vyfmz. I have included two tests one that passes (standalone) and the normal 01app.t test that fails. Just unzip and "prove -l t". I am using the latest CPAN versions of Catalyst (5.80018), Catalyst::Model::Adaptor (0.06), Moose (0.94), MooseX::Declare (0.32) and the Perl version is 5.10.0 on ubuntu. Hopefully somebody with more knowledge of the inner workings can shed some light on the problem. Thanks, Iain. ___ 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/
[Catalyst] Users, roles, HTML::FormFu::DBIx::Class::Model - complete example?
Hello! Maybe someone can provide the community with complete example of users/roles editor with HTML::FormFu::DBIx::Class::Model? Manual drops to foo:bar explaination too often ( Alex. ___ 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/
[Catalyst] Q: CatalystX::SimpleLogin
I have two questions about CX::SimpleLogin: 1. Is there a "simple" way to change the settings for "redirect_after_login_uri" and "redirect_after_logout_uri" ? 2. Why is the redirect code outsourced into a role (CX:S::TraitFor::Controller::Login::WithRedirect) when Catalyst::ActionRole::NeedsLogin errors without it? Bernhard ___ 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] Login as another user ...
> > >
> > >What's the best way to achieve this? I tried $c->authenticate without a
> > >password, but this doesn't seem to work.
> > >
> > >--
> >
>
I use 2 different authentication realms, "ldap" (normal login) and "none"
(single-signon, surrogate) and my login controller decides which one to use,
so that root can surrogate as some other user.
if( $single_signon_user || $surrogate_ok ) {
$c->authenticate({ id=>$id }, 'none');
} else { # normal signon
$c->authenticate({ id=>$id, password=>$password }, 'ldap');
}
And I havethe follwoing in myapp.conf:
default_realm ldap
class password
password_field password
password_type none
class null
. . .
. . .
The bad part is that you can't rely on $c->user for your user data. The user
object will have different data/methods depending on the realm used. So I
use a MyAppUser class that abstracts that, providing the user data
independent from the realm used.
You can also inherit from the Authentication classes and do your own thing
in there, such as ignore the need for a password. But I found the realm
strategy easy and independent. Besides I often use 4 or 5 auth different
realms simultaneously...
-rodrigo
___
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::View::Email stopped working
Excellent... I had this exact problem yesterday, and thought I would
have to battle through modules tracking down the source of the
problem... but totally randomly I read this posting in the list and it
fixed my problem..
thanks very much :)
Devin Austin wrote:
Charlie Garrison wrote:
Good morning,
I'm getting errors like the following when sending emails from my app
(it was working fine previously):
Caught exception in MMM::View::Email::Template->process "Can\'t
locate object method "is_simple" via package "sendmail" (perhaps you
forgot to load "sendmail"?) at
/Library/Perl/5.8.8/Email/Sender/Simple.pm line 100."
When trying to find out exactly where the problem was; I noted that
backend is no longer using Email::Send like it used to (& the
documentation says), eg:
# Setup how to send the email
# all those options are passed directly to Email::Send
sender => {
mailer => 'SMTP',
# mailer_args is passed directly into Email::Send
mailer_args => {
Host => 'smtp.example.com', # defaults to localhost
username => 'username',
password => 'password',
}
C::V::Email now seems to be using Email::Sender instead. And I'm
having trouble working out the correct config options I should be
using. I've got 'mailer' set to 'SMTP' and there should be a
$transport for that in Email::Sender. I'm using the following config
(for local test server):
mailer SMTP
Host192.168.1.5
Is this a bug with C::V::Email or Email::Sender, or am I doing
something wrong?
Charlie
Hi Charlie/Everyone Else Who Experienced the Breakage,
Catalyst::View::Email version 0.20 *should* in theory fix the recent
breaks. Please install (most conveniently using cpanf, attainable
through App::CPAN::Fresh) and test, and notify the list/irc channel if
you have any issues.
Also, see my previous email to the list regarding this fix/release.
Thanks,
dhoss
___
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/
