a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
- Updating package of p5 module Catalyst::Component::ACCEPT_CONTEXT
from 0.06 to 0.07
- Use Module::Install as module type
- Adjusting license according to META.yaml
Upstream changes:
0.07 11 June 2009
Fix tests with Catalyst 5.80005
- Updating package for p5 module Catalyst::Component::ACCEPT_CONTEXT to
0.06 from 0.05
- Setting license to gnu-gpl-v2
- Adjusting dependencies
Upstream changes:
0.06 24 April 2009
Switch from NEXT to MRO::Compat
to trigger/signal a rebuild for the transition 5.8.8 -> 5.10.0.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=...").
Models and Views don't usually have access to the request object,
since they probably don't really need it. Sometimes, however, having
the request context available outside of Controllers makes your
application cleaner. If that's the case, just use this module as
a base class:
package MyApp::Model::Foobar;
use base qw|Catalyst::Component::ACCEPT_CONTEXT Catalyst::Model|;
Then, you'll be able to get the current request object from within
your model:
sub do_something {
my $self = shift;
print "The current URL is ". $self->context->req->uri->as_string;
}
