RE: [Catalyst] Dispatching based on path and host/domain

[Curtis Fletcher]

 Write an Action Class.
 
 You can put whatever you want in the match() method. In your case,
 
 return 0 if grep { $c-req-host =~ /$_/ } 
 @{$self-attributes-{Domain}||[]}

I gave this a go (in principle it looks ideal), but the documentation on
Catalyst::Action is pretty sparse and only talks about replacing the
execute method. I'm assuming that if ActionClass-match() returns
false the dispatcher assumes the method doesn't match, I gave that a
quick test:

package Catalyst::Action::Domain;
use strict;
use warnings;
use base 'Catalyst::Action';
sub match
{
my $self = shift;
my ($c) = @_;
return 0;
};

package MyAPP::Controller::Admin::Website1::Abstract
sub index :Local
{
}

sub edit :Local :ActionClass('Domain')
{
}

http://mydomain.com/admin/website1/abstract/edit bounced me right back
to the default controller, I was kind of expecting it to behave like
NEXT in that it would fail to match
http://mydomain.com/admin/website1/abstract/edit but would then match
http://mydomain.com/admin/website1/abstract setting the first arg to
'edit'. Ah this may be specific to index as a not-really action it
doesn't accept parameters the way I thought it did 

E.G.
http://mydomain.com/admin/website1/abstract/iamnotamethod

Does not dispatch to MyAPP::Controller::Admin::Website1::Abstract-index
with ARGS being ('iamnotamethod') I think I answered my own question,
but there's no harm in having the result in the archives no? (especially
if I'm wrong)
(Also, Did someone say that index was a hack? And that we should use
base instead?)

Dumping out the Action Object I can see:
'attributes' =
{
'ActionClass' =
[
'Catalyst::Action::Domain'
],
'Path' =
[
'admin/website1/abstract/edit'
]
}

But I can't seem to find anywhere that this structure is set up, given
the code in your Action example how would you go about setting the
'Domain' key in the attributes class from the Controller the Action is
used in, apologies if this is a question with an obvious answer.

Finally isn't $c-req-host the hostname of the connecting client? I
ended up mangling $c-req-base at the moment though I'm not sure that's
the best way to go.

Really finally, has anyone thought of putting together a flowchart of
the Classes/methods involved in a Catalyst request response if it's been
done I'd love to look at it and if not if might be a good exercise for
me.

Thanks again for the really sterling help/suggestions.


___
List: Catalyst@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/

RE: [Catalyst] Dispatching based on path and host/domain

[Curtis Fletcher]

 -Original Message-
 From: Matt Pitts [mailto:[EMAIL PROTECTED] 
 Sent: 22 April 2008 03:06
 To: The elegant MVC web framework
 Subject: RE: [Catalyst] Dispatching based on path and host/domain
 
  You've probably heard this before on the list, but...
  
  Ideally, you shouldn't have enough code in your Controllers 
 to justify
  sharing the app across domains that need different functionality.
 The
  meat of the app should be in the Models, then you can just run
 multiple
  Cat apps - one with Cart controllers and one without - that use the
  same
  shared Models.

Absolutely right, my controllers are much, much too heavy. This all came
from learning as I went and I distinctly remember the point at which I
gave up trying to put business logic in the model. At the time there
seemed to be minimal if any examples that illustrated the model being
anything other than an adaptor for DBIx::Class::Schema so I just figured
I was mistaken in my attempt to do so.

So could I ask, now I know a little more than I did then, Does everyone
here subclass DBIx::Class::Resultset (a-la
http://catalyst.perl.org/calendar/2007/16) for their business logic
specific methods? (Well those that use DBIx::Class as their model
anyway)

Thanks for the Help Matt, it's certainly made me think.

___
List: Catalyst@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/