[Catalyst] some basic Catalyst theory questions

[Sebastian Riedel]

Am 06.06.2005 um 23:55 schrieb Perrin Harkins:

> On Mon, 2005-06-06 at 23:11 +0200, Sebastian Riedel wrote:
>
>> Next to the context you get an eval cage around your method call with
>> profiling.
>>
>
> Is there a concept for how exceptions should be handled in  
> Catalyst?  My
> usual approach is that I have one eval{} at the top level and never  
> try
> to catch anything below that unless I think I can do something  
> useful to
> recover from it.

It's up to you how to handle them...
But unhandled exceptions are collected and presented on the sweet  
debug screen in -Debug mode.

>
>
>> I tend to use this little idiom...
>>
>>      use YAML 'LoadFile';
>>      use Path::Class 'file';
>>
>>      MyApp->config(
>>          LoadFile( file( MyApp->config->{home}, 'myapp.yml' ) ) );
>>
>
> That looks good.  Some kind of config plugin and some mention in the
> docs would be nice, but I'm glad to see it's that easy.

Contributions welcome... it's a matter of a few lines of code, but  
until now nobody requested a plugin...

>
>
>> Funny, everybody thinks it's much more flexible than everything else
>> on the market.
>> And keep in mind that mod_rewrite is very platform specific, we
>> support CGI, all versions of mod_perl, FastCGI, SpeedyCGI, Zeus and
>> more!
>>
>
> I just meant that tools like mod_rewrite can fix shortcomings in URL
> handling at the app level.

We don't have shortcomings... :)

>
>
>> IMO, having the uri right next to your method (in code) makes the
>> whole mapping dead simple.
>>
>>
>>      sub method : Path('/foo/bar') {}
>>
>
> The trouble is, if I want to move your app to /exec/obidos/bar, I need
> to edit your source code, don't I?  Other frameworks like
> CGI::Application do define an interaction between methods, but they
> don't use absolute paths like this.  I suppose there's a way to use
> regexes to get around this, but that seems clunky.

No wait, all uri's you define are relative to the applications root!

     <Location /exec/obidos/bar>

And it would be all relative to that...

>
>
>> It works with all engines!
>> Yes docs are a bit slim, but Christian our machinist :) promised
>> benchmarks and example configs for all platforms...lets hope this
>> post motivates him some more!
>>
>
> That would be good, because it's not very clear how one should set  
> up a
> CGI script to trap a whole range of URLs.  I'm guessing it involves
> PATH_INFO.

Yes, we use PATH_INFO i guess :)

>
>> Most people just prefer using Catalyst::Plugin::FormValidator, so i
>> guess thats why everybody overlooked it. ;)
>>
>
> The docs in C::P::FV are pretty skimpy too, really.  I would never  
> have
> guessed I was supposed to use it to read URL args, since that isn't  
> how
> it gets used in other systems I've seen.  Most of them still read the
> values from CGI or Apache::Request after doing the validation.
>
> I don't mean to be a pain about the docs.  If I were a Catalyst  
> user at
> this point, I'd consider working on them.  Right now though, I'm just
> dabbling with it and making toy apps to compare against other systems,
> so I'm not at the point where that would make sense yet.

No wait, you asked for $c->req->params which are the parameters.
You want arguments $c->req->args.

Those are naturally not handled by Data::FormValidator! :)

You can access them via @{ $c->req->args } or directly in your actions

     sub action : Local {
         my ( $self, $c, $arg1, $arg2, $arg3... ) = @_;
     }

We try to give you as much syntactic sugar as possible with perl5,  
but the perl6 port i'm working on will be much sweeter!!! ;)

--
sebastian