[Catalyst] some basic Catalyst theory questions

[Sebastian Riedel]

Am 06.06.2005 um 22:16 schrieb Perrin Harkins:
> I'm working on my presentation about MVC frameworks for YAPC, and I  
> have
> some questions about the theory behind some of the design decisions in
> Catalyst.

Cool!

>
> - What's the reasoning behind the use for $c->forward() everywhere in
> place of normal method calls?  The only clear advantage I can see is
> that the context object is passed along automatically.  Is there  
> another
> reason?

Next to the context you get an eval cage around your method call with  
profiling. (in the log with enabled -Debug)
And you get some generic points for AOP hooks, but thats just theory  
actually... :)

>
> - The examples show machine-specific configuration like database
> connection params and file paths being specified in the code itself.
> That would be a big portability problem, if you have to modify the  
> code
> on every new machine.  Is there a plan for Catalyst to help people  
> with
> putting this kind of stuff in a config file?  (Note that I am not
> talking about things like database table relationships, just the pure
> config stuff that is likely different on every installation of the  
> same
> app.)

We already have a $c->config->{home} variable, which always points to  
the applications home (we hacked Module::Build to let you install cat  
apps like ordinary cpan modules!)

I tend to use this little idiom...

     use YAML 'LoadFile';
     use Path::Class 'file';

     MyApp->config(
         LoadFile( file( MyApp->config->{home}, 'myapp.yml' ) ) );

Deployment can't be much easier... :)


>
> - In a similar vein, defining URLs directly in the code seems less
> flexible than doing it somewhere else, and makes Catalyst apps hard to
> relocate.  (Although of course mod_rewrite solves any URL  
> problem.)  Is
> there any alternate way of defining URL to method mappings?

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!

IMO, having the uri right next to your method (in code) makes the  
whole mapping dead simple.


     sub method : Path('/foo/bar') {}

vs.

     package MyApp::C::Foo;

     sub method {}


     RewriteEngine On

     RewriteRule ^/foo/bar$ /foo/method


Just look at the mess the Rails folks call Routes, it's horrible...

And in case you still don't like the actual dispatcher, subclass  
Catalyst::Dispatcher and do as you want, every single bit in Catalyst  
is exchangeable. ;)

>
> - Does all of this URL stuff work with the CGI engine?  I can imagine
> ways it might work using PATH_INFO, but the docs on how to configure a
> web server to use the different engines seem pretty slim.  Maybe I'm
> looking in the wrong place.

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!

>
> - None of the intro docs show any use of query args ( $c->req()- 
> >params
> () ) at all, and at first I wasn't sure it was even supported.  Is  
> this
> an intentional thing, to encourage people to use other approaches,  
> or is
> it just that URLs like /action27/thing13/ are more fun to write about?

Not intentional, patches are very welcome...
Most people just prefer using Catalyst::Plugin::FormValidator, so i  
guess thats why everybody overlooked it. ;)

>
> Thanks for your help with this.  I will probably have
> more questions
> later, but that should do it for now.

Just ask, or join #catalyst...

--
sebastian