[Catalyst] How to get default()-like behavior outside of the Root controller

[Trevor Leffler]

It turns out the length of the chaining is a variable in this equation.

In my Test Controller...

This gives "good" behavior:
sub base : Chained('/') PathPart('test') CaptureArgs(0) {}
sub another : Chained('base') PathPart('') CaptureArgs(0) {}
sub index : Chained('another') PathPart('') Args(0) {...}
sub default : Chained('another') PathPart('') Args() { ... }

But this gives too much "weight" to default, allowing it to "win" over 
index():
sub index : Chained('another') PathPart('') Args(0) {...}
sub default : Chained('base') PathPart('') Args() { ... }

So, the shorter chain wins, eh?  This latter scenario is more common for 
me.  I'll look into having my index() $c->forward to the bits I need.

--Trevor

On 02/10/2015 02:19 PM, Trevor Leffler wrote:
> Hi Aristotle,
>
> On 02/10/2015 02:39 AM, Aristotle Pagaltzis wrote:
>> Hi Trevor,
>>
>> * Trevor Leffler <tleffler at uw.edu> [2015-02-07 00:00]:
>>> Requests for non-extant paths fall through to Root->default(), which
>>> gives the (undesired) default root view. I tried giving my top-level
>>> controllers their own default() methods, but as others have found [1],
>>> 'default() : Path' has precedence over 'index : Chained'.
>>
>>      package MyApp::Admin;
>>      sub default : Chained('base') PathPart('') { ... }
>>      package MyApp::Survey;
>>      sub default : Chained('base') PathPart('') { ... }
>>
>> Note how you don’t specify any particular number of arguments. So it
>> will match any number of trailing URL segments.
>>
>> I *think* this will work. I haven’t tried it.
>
> I had tried this earlier with poor results.  However, I spun up a quick
> Foo catalyst project for testing and found that if I defined *all* the
> defaults()'s as :Chained in Root/Admin/Survey/etc. then they played well
> with my other methods, all of which are :Chained.  Once you go
> :Chained...  ;)
>
>> However, contrary to what you claimed, splitting the app into multiple
>> Cat apps joined together at the PSGI level *will* also work just fine.
>> That will lead to requests for /admin/* always being dispatched to
>> MyApp::Admin – which gets to have its own MyApp::Admin::Controller::Root
>> with a `default` action that applies only to it. Likewise requests for
>> /survey/* will always be dispatched to MyApp::Survey which equally has
>> its own root controller with a `default` action that applies only to it.
>> If the parts of your app are not closely related, this will be a more
>> natural structure.
>
> I don't think I spoke against splitting my app up, rather I just ignored
> that line of thought.  ;)  There may be too many
> relationships/dependencies across the major areas to split it up in the
> immediate future, but I can see some architectural advantages to doing
> so.  Simply the fact that I've got variations in template wrappers may
> be an indicator.
>
> Thanks,
> --Trevor
>
>> Regards,
>>
>
> _______________________________________________
> 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.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/