[Catalyst] [OT] ASP.NET MVC

John Napiorkowski jjn1056 at yahoo.com
Mon Dec 17 22:10:30 GMT 2007


--- Matt S Trout <dbix-class at trout.me.uk> wrote:

> On Mon, Dec 17, 2007 at 07:31:21AM -0800, John
> Napiorkowski wrote:
> > Yeah, the main configuration is definitely the
> right
> > place to be maintain centralized routing and to
> more
> > cleanly separate the URI namespace.  Just that as
> you
> > say, it's not clear to people when they first
> start
> > probably because there isn't a lot of people
> saying
> > that and the documentation and quick start guides
> > don't seem to promote that idea.
> 
> No, it's absolutely and horribly the wrong place -
> that's why nobody uses
> the feature even though it's supported. It basically
> turns your main mapping
> into a god object; why does the mapping info for the
> admin interface need to
> be related in any way shape or form to the mapping
> for the user interface,
> for example?
> 
> Self-contained URI mapping info for controllers is
> essential to encapsulated
> code re-use.
> 
> The one time I tend to use the main app config to
> supply such info is to
> rename a particular part of a site for a specific
> deployment - for e.g.
> if I have
> 
> MyApp::Controller::Blog::base :Chained('/')
> :PathPart('blog') :CaptureArgs(0)
> 
> I might do
> 
> <Controller Blog>
>   <Action base>
>     PathPart news
>   </Action>
> </Controller>
> 
> to rename that URI segment to /news instead of
> /blog.
> 
> > If you give me a template to start with, either as
> an
> > advent article or other I will definitely try to
> > expand it out, as long as you don't me giving it
> the
> > once or twice over.  
> 
> I was offering to provide an example of how to use
> base classes in ways
> that are entirely impossible with a crappy central
> routing system - the
> Reaction CRUD controller is a good example of this,
> it provides
> 
> $base/
> $base/create
> $base/id/*/view
> $base/id/*/edit
> $base/id/*/delete
> 
> actions, where $base is the chain part leading up to
> 'sub base'
> 
> So to bind that in you do
> 
> package MyApp::Controller::Admin::Foo
> 
> use base qw(Reaction::UI::Controller::CRUD);
> 
> __PACKAGE__->config(
>   actions => { base => { Chained => '/admin/base',
> PathPart => 'foo' } },
>   ... # model name etc. here
> );
> 
> and assuming you have
> 
> MyApp::Controller::Admin::base :Chained('/')
> :PathPart('admin') :CaptureArgs(0)
> 
> /admin/foo/
> /admin/foo/create
> /admin/foo/id/*/view
> /admin/foo/id/*/edit
> /admin/foo/id/*/delete
> 
> actions all immediately appear ready to go.
> 
> This sort of thing simply isn't possible with a
> central routing system, which
> is why in spite of people periodically claiming
> they're "easier" I've always
> been against the concept.

Hi,

Thanks for clarifying your thoughts for me.  I went
and looked at the Reaction repo to get a better idea
of what you are talking about.  

I may not have properly explained what I was thinking
regarding mapping and configuration.  However I found
what you wrote to be very elucidating.  I guess what
you are saying is that it's not such a good idea to
put all the URI mapping information, (such as
controller namespace, action path or pathpart, etc) in
your global configuration, since as you say it
improperly couples things that are not related and it
also prevents you from using base controller classes
in the way you've describe.  However I am sure you can
understand that it's not obvious to many people to do
their development this way, particularly without any
examples (and with all the examples commonly tossed
around not doing this at all).

I still think a solid and well documented example will
help here.  We should choose something that would suck
if it wasn't developed in Catalyst.  I guess what I am
shooting for is a clear and understandable reason why
Catalyst's de-centralized routing can lead to more
flexible and more robust designs, since as you say
things more less tightly coupled, among other reasons.
 Having such an explanation would be very useful in
articulating what's great about Catalyst and also
offer guidance to beginners as to the best way to
structure their projects.  As I mentioned in an
earlier post, this is a big point of confusion for all
the new Catalyst developers I've run into.  I know of
at least two people that decided to just use :Default
everywhere and stop trying to understand what to do. 
This system is a major plus for Catalyst, especially
with the way it can play so well with Chaining (as the
Reaction example you gave showed).  To my eyes it
makes Catalyst development beautiful and I'd like to
make that more obvious to people when choosing a
development framework.

--John


> 
> -- 
>       Matt S Trout       Need help with your
> Catalyst or DBIx::Class project?
>    Technical Director                   
> http://www.shadowcat.co.uk/catalyst/
>  Shadowcat Systems Ltd.  Want a managed development
> or deployment platform?
> http://chainsawblues.vox.com/           
> http://www.shadowcat.co.uk/servers/
> 
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo:
>
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping



More information about the Catalyst mailing list