[Catalyst] Cascading action dispatching
My apologizes if this has been addressed before, I couldn't find
anything in the archives.
I'm trying to figure out a way to have my Cat app dispatch in a way that
would allow multiple actions in the same namespace and have them called
in succession until one of them actually handles the request.
I have a client that really likes base-level URLs, like
"/shoppingmallxyz", and wants to use them for landing pages that are
functionally different. In some of these cases the base-level URL paths
are really just monikers for things that are retrieved from the DB and
if it exists, then a page is rendered.
For example, I want to have a controller Center that has an action like
the following:
sub base_lookup : PathPart('') Chained('/') Args(1) {
my ( $self, $c, $moniker ) = @_;
my $center = $c->model('Common::Center')
->find_by_moniker($moniker);
if ( $center ) {
... do some stuff to fill stash and specify template ...
} else {
... give notice that this action couldn't handle the request ...
}
}
And then another controller Promotion that has an action like this:
sub base_lookup : PathPart('') Chained('/') Args(1) {
my ( $self, $c, $moniker ) = @_;
my $promo = $c->model('Common::WebPromotion')
->find_by_moniker($moniker);
if ( $promo ) {
... do some stuff to fill stash and specify template ...
} else {
... give notice that this action couldn't handle the request ...
}
}
If the Center::base_lookup action doesn't find a center from the given
moniker it bows out and the dispatcher then goes on to find the
Promotion::base_lookup action which will essentially to the same thing
as the Center::base_lookup action but instead use the base url argument
as a moniker to lookup a promotion.
I guess, if neither action can handle the request, then the dispatcher
would just fall back to default.
I was thinking I might be able to accomplish this with a call to
$c->dispather->dispatch(), but in a simple test I did this just results
in a recursive call.
I greatly appreciate any help with this.
Thanks,
--
Matthew W. Pitts
Software Engineer
[EMAIL PROTECTED]
336.202.3913 (mobile)
A3 IT Solutions, LLC
www.a3its.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] Cascading action dispatching
On Fri, 2007-10-19 at 17:16 -0400, Matthew Pitts wrote:
>
> I'm trying to figure out a way to have my Cat app dispatch in a way
> that
> would allow multiple actions in the same namespace and have them
> called
> in succession until one of them actually handles the request.
>
> I have a client that really likes base-level URLs, like
> "/shoppingmallxyz", and wants to use them for landing pages that are
> functionally different. In some of these cases the base-level URL
> paths
> are really just monikers for things that are retrieved from the DB and
> if it exists, then a page is rendered.
I guess another, maybe more elegant, way to accomplish this same effect
would be to override register_actions in the Controllers where I want to
do this and have a call to a register_dynamic_actions method like so:
package MyApp::Controller::Center;
sub register_actions {
my $self = shift;
my ( $c ) = @_;
$self->register_dynamic_actions($c);
return $self->SUPER::register_actions(@_);# or NEXT?
}
sub register_dynamic_actions {
my $self = shift;
my ( $c ) = @_;
my $centers = $c->model('Center')->all;
while ( my $center = $centers->next ) {
my $action = $self->create_action(...);
$c->dispatcher->register($c, $action);
}
}
1;
An obvious side-effect (AFAIK) of doing it this way is that the app has
to be restarted for new dynamic actions to take affect. The benefit,
however, is that the root-level pseudo-actions I was trying to achieve
with on-the-fly DB lookups are now first class actions and would not
require a DB call on each request.
I may be crazy... anybody got any thoughts on this?
--
Matthew W. Pitts
Software Engineer
[EMAIL PROTECTED]
336.202.3913 (mobile)
A3 IT Solutions, LLC
www.a3its.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] Cascading action dispatching
On Sun, 2007-10-21 at 15:39 +0100, Ash Berlin wrote:
> Have you looked at Chained actions?
Yes, I'm currently using chained actions quite a bit. The problem that I
have, is I want a way to have multiple actions chained against root
('/') that are in different Controllers and have the dispatcher call
each one in succession until one of the them actually handles the
request. Basically, I want to have a lot of root-level urls that aren't
first class actions, they're just monikers for DB resources. The catch
is that I don't want to do the all the lookups in the same root-chained
action, because the different monikers are defined in different models.
If you haven't already, check out my original post on this thread where
I explain it in more detail.
Thanks for your comments.
v/r
--
Matthew W. Pitts
Software Engineer
[EMAIL PROTECTED]
336.202.3913 (mobile)
A3 IT Solutions, LLC
www.a3its.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] Cascading action dispatching
On Sun, 2007-10-21 at 20:10 +0100, Matt S Trout wrote: > Yes, you're crazy. Acceptance is the first stage to recovery. > OTOH you appear to be the same same sort of crazy I was when I wrote > register_actions and intentionally factored the process in such a way > that it was overridable, so don't let that stop you implementing this. This is probably the way I'll do this, because it'll DWIW. But, at some point I'll probably hate myself for it when I want to chain against my dynamically built actions. > The only better solution I can think of is to handle whether you > accept the > action via an action class, but we need to add a > $action->match_captures for chain mid-points to make that elegant, > currently you only get a match on end point which would be a bit messy > to implement. I'll take your word on the messy part and look forward to 5.80. Thanks very much for the input. v/r -- Matthew W. Pitts Software Engineer [EMAIL PROTECTED] 336.202.3913 (mobile) A3 IT Solutions, LLC www.a3its.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/
[Catalyst] MyApp::C::PageHooks - thoughts ?
I wanted to get some thoughts on something a little different that I'm
doing...
What I want to to have is Controllers that are temporary (i.e. date
sensitive) that represent a particular "promotion" that's running on a
site. This promotion may need to affect different areas of the site, but
I don't want to have $c->forward calls like the following everywhere
that I need the Promo's code to inject stash data.
$c->forward('Controller::Promos::Foo', 'some_action')
So, I decided to do a form of "hooks" within my app so that any given
controller can affect the stash for a defined set of hooks.
Below is the first run of my code to implement this. Basically, I
override Controller->register_actions and run through all the
controllers looking for C->config->{pagehooks} and build a local hashref
containing the hook definitions.
Then, in all the places throughout the app that are defined as
"hookable" I just do a:
$c->forward('Controller::PageHooks', 'run_hook', 'hook_name', [ 'arg1',
'arg2' ]);
and it "just works".
The main advantage with is that I can remove the promo's controller and
don't need to change any other controllers. I can even get my design
guys to code their templates in such a way that when the promo expires,
every place on the site affected by the promo magically goes back to
pre-promo look-and-feel.
Any thoughts on my level of sanity here?
package MyApp::Controller::PageHooks;
use base 'Catalyst::Controller';
use strict;
use warnings;
my $HOOKS = {};
sub register_actions {
my $self = shift;
my ( $c ) = @_;
$self->register_hooks($c);
return $self->SUPER::register_actions(@_);
}
sub register_hooks {
my ( $self, $c ) = @_;
my @ctrls = $c->controllers;
foreach my $ctrl (@ctrls) {
my $ctrl_ref = $c->controller($ctrl);
if ( $ctrl_ref->config->{pagehooks} ) {
my $hook = $ctrl_ref->config->{pagehooks};
while ( my ($hook, $action) = each(%{$hook}) ) {
$HOOKS->{$hook} ||= ();
push @{$HOOKS->{$hook}}, [ $ctrl, $action ];
}
}
}
}
sub run_hook : Private {
my ( $self, $c, $hook, @args ) = @_;
if ( $hook && $HOOKS->{$hook} ) {
foreach my $action_ref (@{$HOOKS->{$hook}}) {
my $ctrl = $c->controller($action_ref->[0]);
my $act = $ctrl->action_for($action_ref->[1]);
if ( $ctrl && $act ) {
$c->forward($action_ref->[0], $action_ref->[1], [EMAIL
PROTECTED]);
}
}
}
}
1;
--
Matthew W. Pitts
Software Engineer
[EMAIL PROTECTED]
336.202.3913 (mobile)
A3 IT Solutions, LLC
www.a3its.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] MyApp::C::PageHooks - thoughts ?
On Mon, 2007-10-29 at 15:52 -0500, [EMAIL PROTECTED] wrote: > Why not just store promos in the database and have a static controller > that > acts on active promos? No changing application code for the promo. > easy > to do future promos too as you can have an epoch start and end time > for the > promo in the db tables that the controller takes into account. This is actually how it works - I have a generic Promotions controller that looks them up from the db and applies date filtering, but it "proxies" action calls to a first-class controller for a given promotion if a corresponding controller exists. So, if I have a promotion with a defined moniker of 'MidnightMadness' and a Controller::Promotions::MidnightMadness exists, then action calls get proxied to this controller. Because of this particular client's needs there is no way to pigeon hole promotions into a standard set of code. Sometimes they want "this", sometimes they want "that". So, I still need to have a first-class controller for a given promotion. This is why I did the hooks - I can have a generic interface where any promotion can manipulate the stash. The big caveat is that I have to define the places where I want hooks and over time they could get messy. Thanks for the input. -- Matthew W. Pitts Software Engineer [EMAIL PROTECTED] 336.202.3913 (mobile) A3 IT Solutions, LLC www.a3its.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/
[Catalyst] PAR deployment w/ non-standard layout
Due to our initial development effort being broken down b/t code and design, our application has somewhat of a non-standard layout. I'm now looking to use PAR to deploy the app, but I'm having some issues due to our non-standard setup and I'm hoping someone can shed some light on the magic behind 'make catalyst_par'. Does the built PAR contain all of the app's "root" content? I've built some test PARs and I can't find where it has this content included. However, when I run a test server via a PAR and browse the the /tmp/par-... directory that contains the app I find the inc/lib/MyApp/root directory that contains all such "rootness". If the PAR doesn't get built with "root" inside, then does it copy "root" into the /tmp/par-... directory when it is run via 'parl myapp.par script/myapp_server.pl'? Are there still issues with PAR's /tmp/par-... magic in a FCGI setup with multiple "versions" of the same app? Reference: http://www.gossamer-threads.com/lists/catalyst/users/11148 I want to be able to run my UAT and PROD apps on the same system, but obviously they would need different home directories. Can I use myapp.par as a FCGI internal process in mod_fcgid? Would I just replace my Apache directive references to 'script/myapp_fastcgi.pl' with 'parl myapp.par script/myapp_fastcgi.pl'? Are there any issues with using the following for mod_fcgid to support my non-standard layout: 'CATALYST_HOME=/path/to/home parl myapp.par script/myapp_fastcgi.pl'? TIA for any help. Regards, -matt pitts ___ 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] So, what do we want in the -next- book?
On Tue, 2008-04-29 at 12:06 -0500, Cory Watson wrote: > On Tue, Apr 29, 2008 at 9:51 AM, J. Shirley <[EMAIL PROTECTED]> > wrote: > Dare I say, an Enlightened Perl Development book? > > > > Being in the middle of 5 or 6 apps that all use the 'enlightened' > stack of perl libraries I can personally say that I would _love_ to > have this book to recommend to our developers or to others. > > > I love DBIC, Catalyst, Moose and friends because they don't force me > into a particular way of doing things. The problem with this approach > is that, for the newb, there are so many choices to make. It's not > always clear which is the best. I know I've made -- and continue to > make -- bad choices that I later have to undo. A guide into this area > of perl would likely be very helpful. ++ I've been using Perl for many years with the last two being professional and I'm just now becoming somewhat aware of what the "enlightened" libraries are. I stumble in this area a lot. A book into this area as a whole would be very nice. v/r -matt pitts ___ 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/
