Re: [Catalyst] [OT] ASP.NET MVC#
On Dec 21, 2007 10:22 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: i'm not completely following the new syntax that you are proposing, so please forgive if I am wide of the mark here ... but ... IMO the existing syntax is really not *that* bad - the only mild crit I have is that Args() really means I'm an endpoint, which it doesn't say. For me, a simple improvement would be to allow an alternative name such as EndpointArgs that is a bit more obvious, and keep the rest just as it is. My argument really is that the number of parameters an action takes is independent from the fact that it is an end point or is not, and that you should not have one attribute that carries both of those meanings. So my latest proposal is to use Args to indicate the numer of parameters an action takes (just like you do it now, but also when you now use CaptureArgs) and IsParent to indicate that you can attach other actions to it. I worry a bit that two syntaxes, achieving the same thing but looking quite different to each other, and both coexisting in docs, mailing lists, and code, are just going to add more potential confusion than they clear up. Understood. If my proposal gets accepted I volunteer to purge CaptureArgs from the docs (and the Ministry of Love will go after those that mention CaptureArgs on the mailing lists). I think my proposal is really minimal - in fact I would say it does not introduce more new things than your 'simple improvement' above. Cheers, Zbigniew Lukasiak http://perlalchemy.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC#
Or maybe a better idea would be to use IsParent (or Parent) for those actions that can have children (logical isn't it?). Then we could use Args all the time instead of CaptureArgs (with EndPoint). Z. On Dec 20, 2007 12:31 PM, Matt S Trout [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 02:18:17PM +, Zbigniew Lukasiak wrote: On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... A proof of concept implementation is in Catalyst::Controller::PathPart. It replaces the attributes at parsing time, I guess this would not be appropriate for the core of Catalyst. I am now going to port that change into lib/Catalyst/DispatchType/Chained.pm. I am not sure I'll be able to do it though. Remember you can't break backcompat in the process either ... -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://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@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/ -- Zbigniew Lukasiak http://brudnopis.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC#
i'm not completely following the new syntax that you are proposing, so please forgive if I am wide of the mark here ... but ... IMO the existing syntax is really not *that* bad - the only mild crit I have is that Args() really means I'm an endpoint, which it doesn't say. For me, a simple improvement would be to allow an alternative name such as EndpointArgs that is a bit more obvious, and keep the rest just as it is. I worry a bit that two syntaxes, achieving the same thing but looking quite different to each other, and both coexisting in docs, mailing lists, and code, are just going to add more potential confusion than they clear up. Assuming that is what would happen - that's what I gather from Zbigniew's first description. D On 12/21/07, Zbigniew Lukasiak [EMAIL PROTECTED] wrote: Or maybe a better idea would be to use IsParent (or Parent) for those actions that can have children (logical isn't it?). Then we could use Args all the time instead of CaptureArgs (with EndPoint). Z. On Dec 20, 2007 12:31 PM, Matt S Trout [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 02:18:17PM +, Zbigniew Lukasiak wrote: On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... A proof of concept implementation is in Catalyst::Controller::PathPart. It replaces the attributes at parsing time, I guess this would not be appropriate for the core of Catalyst. I am now going to port that change into lib/Catalyst/DispatchType/Chained.pm. I am not sure I'll be able to do it though. Remember you can't break backcompat in the process either ... -- 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@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/ -- Zbigniew Lukasiak http://brudnopis.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ -- Daniel McBrearty email : danielmcbrearty at gmail.com http://www.engoi.com http://danmcb.vox.com http://danmcb.blogger.com find me on linkedin and facebook BTW : 0873928131 ___ 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] [OT] ASP.NET MVC#
On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... A proof of concept implementation is in Catalyst::Controller::PathPart. It replaces the attributes at parsing time, I guess this would not be appropriate for the core of Catalyst. I am now going to port that change into lib/Catalyst/DispatchType/Chained.pm. I am not sure I'll be able to do it though. Cheers, Zbigniew http://perlalchemy.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC#
On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... Ok - so I attach a patch (it is against http://dev.catalyst.perl.org/repos/Catalyst/branches/current/Catalyst-Runtime - I hope that is the 5.80 trunk - if not tell me and I'll change it). It passes the tests. In two cases when the test application uses the original TestApp::Controller::Action::Chained::* instead of TestApp::Controller::Action::ChainedEndPoint::* - I think this is due to how the test application is build. I've marked those cases in the test file and modified the tests so that they pass. For the tests I've copied the tests of live_component_controller_action_chained.t and adopted it to test TestApp::Controller::Action::ChainedEndPoint instead of TestApp::Controller::Action::Chained. So - what do you think? Zbigniew http://perlalchemy.blogspot.com/ ChainedEndPoint.diff.gz Description: GNU Zip compressed data ___ 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] [OT] ASP.NET MVC
The chained thing is probably the single most useful thing in cat IMO (if it's possible to even make such a dumb call ;) The way I have come to see it (it took a while, reading discussions here helped me grasp this) is that the way you design your URI space is very very fundamental to design of a web app. Chained helps you to remember this and try to get it right at the start. It also makes the decision about what actions go in what controllers separate from decisions about URI namespace. (I haven't really figured out if that is entirely a good thing or not, but it seems helpful.) The syntax *is* a bit hard to get used to at first - I find that the important thing is to remember that Args() defines an endpoint (hope I am remembering that right), other than that take a good look at what the debug server tells you when it starts up. (Without that info it'd be a royal PITA) Centralised routing stuff might be nice to have, but the way Chained flies now is pretty darn neat, once you get used to it. For me, I think I might prefer to be able to see the routing info right there in the action definition - where you need it. There isn't much cause to use anything other than Chained, as far as I can see (except the odd private helper method). BTW I talked about this a bit at the (first) Brussels Perl Mongers group a month or two back, and I have someone coming round for a beer later this evening - they have been wanting to port their Mason app to Catalyst, and I'm gonna see if I can help them get started. cheers Daniel ___ 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] [OT] ASP.NET MVC
I'm still holding hopes for:
Chained('../')
-=Chris
signature.asc
Description: OpenPGP digital signature
___
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] [OT] ASP.NET MVC
On Dec 17, 2007 4:03 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: The chained thing is probably the single most useful thing in cat IMO (if it's possible to even make such a dumb call ;) The way I have come to see it (it took a while, reading discussions here helped me grasp this) is that the way you design your URI space is very very fundamental to design of a web app. Chained helps you to remember this and try to get it right at the start. It also makes the decision about what actions go in what controllers separate from decisions about URI namespace. (I haven't really figured out if that is entirely a good thing or not, but it seems helpful.) The syntax *is* a bit hard to get used to at first - I find that the important thing is to remember that Args() defines an endpoint (hope I am remembering that right), other than that take a good look at what Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). -- Zbigniew Lukasiak http://brudnopis.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC
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.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://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@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] [OT] ASP.NET MVC
--- Matt S Trout [EMAIL PROTECTED] 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@lists.scsys.co.uk
Listinfo:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
Re: [Catalyst] [OT] ASP.NET MVC
I'd love to *get* reaction, but last time I tried (admittedly a long time back) I had to scrape my brains off the ceiling ... (and I don't really have enough to go round for that kind of thing) ... ___ 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] [OT] ASP.NET MVC#
On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://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@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] [OT] ASP.NET MVC
--- Jonathan Rockway [EMAIL PROTECTED] wrote: On Wed, 2007-12-12 at 09:18 +0200, Octavian Rasnita wrote: Hi, I haven't read anywhere that : Local is deprecated, and I use it very often. Why is it deprecated? I found it works very well, and it is the most simple solution. Who told you this? It's not. Local is theoretically a special case of chained (not implemented that way, but it could be)... Feel free to use Local if it meets your needs. Regards, Jonathan Rockway The error originate with me, I saw on IRC sometime ago a poster being told to stay away from :Local and to prefer :Path instead. Maybe it was for a particular usage, but the impression I received was that although not official deprecate it was not considered a good practice. Thank you for correcting the error. As to your comment about :Local being a special case of Chaining, if you could talk to that I'd appreciate it. I didn't understand that :Local would dispatch through multiple controllers... but maybe I didn't get the gist of your thought. Could you clarify what you meant my that? Because when I encounter people new to Catalyst and getting interested, it seems like the confusion about what type of Action Attribute to use and how to arrange controllers is a big barrier. I know it might seem like a bit of a silly thing to get stuck on, but I know of two people that gave up on Catalyst because it seemed to them to be too many ways to do a very straightforward and simple thing, such as map a URI to a controller, while potentially capturing path arguments. My original comment that started this was how I noticed the Microsoft MVC framework they are distributing is using a standalone dispatching class to build up a URI dispatcher. I've noticed in all my MVC research over the past year that this model is very common. Catalyst is doing things a little different here and I think there is power to our model, but confusion as well. So I was hoping to generate some discussion about that and maybe it could lead to a wiki page or POD or something to give newbies a little guidance as well as offer some general advantages to the Catalyst system. --john Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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] [OT] ASP.NET MVC
Good afternoon, On 12/12/07 at 2:42 AM -0600, Jonathan Rockway [EMAIL PROTECTED] wrote: On Wed, 2007-12-12 at 09:18 +0200, Octavian Rasnita wrote: I haven't read anywhere that : Local is deprecated, and I use it very often. Why is it deprecated? I found it works very well, and it is the most simple solution. Who told you this? It's not. On 11/12/07 at 7:59 AM -0800, John Napiorkowski [EMAIL PROTECTED] wrote: Then we also have :Local, which is also considered somewhat deprecated in favor of :Path, :Default which I was confused too and wondered why I should stop using :Local. Charlie -- Charlie Garrison [EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia O ascii ribbon campaign - stop html mail - www.asciiribbon.org http://www.ietf.org/rfc/rfc1855.txt ___ 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] [OT] ASP.NET MVC
--- Christopher H. Laco [EMAIL PROTECTED] wrote:
Dear MS: Welcome to the party.
http://www.hanselman.com/blog/ASPNET35ExtensionsPlusMVCHowToScreencast.aspx
Interesting to see another take on MVC inside some
bastion of ASP.NET.
-=Chris
Looks like they are using a routing system to connect
up the different pieces. This seems to be the most
common way I've seen for mapping URIs to controllers,
Catalyst being the exception. Catalyst's system does
allow additional levels of control and granularity,
since the Controller is namespaced and can inherit
functionality, while the actions it includes are also
namespaced and can inherit, via ActionClasses.
However I have found that it's a potential point of
confusion for some new developers. For example I have
been asked what's the best way to map the following
url:
/person/{personID}/posts/{postID}
There are a couple of ways, some of them not so good.
For example you can create a 'Person' controller and
then use the regex action attribute, which is still
around but is sorta considered deprecated in favor of
chaining, which is probably better for the above
(since it's lets you more easily reuse info at the
chain base).
And with chaining you could create all the chained
actions in a single class, or use the Chain(.) feature
to spread this over a couple of controllers. That's
what I usually do, but then you sometimes end up with
a mess of nearly empty controller classes.
Then we also have :Local, which is also considered
somewhat deprecated in favor of :Path, :Default which
is recommended only for things like capturing bad URLs
and directing to a not found page (or if you are
clever, so sort of soundex or spelling correction to
see if that would match a known url)
Another potential disadvantage of this, besides the
confusion, is that you end up which a Controller
namespace generally having to map to your URI
namespace, and if you need to change the URI namespace
you end up renaming and moving controllers, around.
What do the rest of you think? What could be better
or more clear in terms of best practices? Because I
think this is a place where a lot of newbies get lost,
and compared to the 'there's only a single way to do
it' method of using router classes, we can lose out.
I know of at least two developers that gave up on
Catalyst for this reason. Maybe we can start a list
of common URI namespaces and recommended ways to
handle it? Or is it time to start warning on some of
the older action attributes, like :Local, etc., in
order to reduce the number of choices a bit and make
things more clear.
Also if we could work up an example that showed the
benefit of the Catalyst way that would also help us.
Thoughts?
--john
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
___
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/
