Re: [Catalyst] $c->detach and $c->action
yes, but that means doing the private-path-to-action work that detach (or forward/_invoke_as_path) will re-do anyway. it may be worth the cost anyway in order to have the functionality, so i may go ahead and implement a detach_as_action (or whatever) here. thx > > On 1 Feb 2007, at 02:05, Michael Reece wrote: > >> is there something like detach that will also set the current >> 'action' to the one being detached to? > > Not until 5.80 but there's no reason you can't simply set $c->action > - it -is- an accessor. > > -- > Matt S Trout, Technical Director, Shadowcat Systems Ltd. > Offering custom development, consultancy and support contracts for > Catalyst, > DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for > details. > + Help us build a better perl ORM: http://dbix- > class.shadowcatsystems.co.uk/ + > > > > ___ > List: Catalyst@lists.rawmode.org > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.rawmode.org/ > Dev site: http://dev.catalyst.perl.org/ > ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Shoot out -- Catalyst / RoR / Other MVC apps --
> On Tue, May 08, 2007 at 09:28:35AM +0100, Anthony Gardner wrote: >> I seem to remember hearing sth a few months ago about a comp between >> various MVC apps comprising of various teams / tasks / time limits etc. >> >> Does anyone know what I'm talking about here?! > > If it was MVC, why would rails be included? > > -- > Matt S TroutNeed help with your Catalyst or DBIx::Class what distinction are you making here to exclude rails from MVC? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Shoot out -- Catalyst / RoR / Other MVC apps --
> On 10/05/2007, at 1:51 AM, Dave Rolsky wrote:
>
>> On Wed, 9 May 2007, A. Pagaltzis wrote:
>>
>>> Delegation means that the caller communicates only with the
>>> object that delegates and doesnt know which object does the
>>> actual work. Thats not whats happening in your example.
>>>
>>> Something like this would be delegation:
>>>
>>>sub trail_length {
>>>my $self = shift;
>>>$self->breadcrumbs->trail_length;
>>>}
>>>
>>> Here the caller talks only to VegGuide::Response and doesnt even
>>> know that theres a VegGuide::Breadcrumbs object behind the scene.
>>
>> I think there's a name for tha pattern I'm using, but I can't
>> remember it or find a good reference online.
>
> Would that be the factory method pattern?
>
> http://en.wikipedia.org/wiki/Factory_method_pattern
>
> --
> Adam Clarke
or the closely-related Dependency/Provider injection pattern?
Dependency injection is a pattern in which responsibility for object
creation and object linking is removed from the objects themselves and
transferred to a factory.
^- http://en.wikipedia.org/wiki/Dependency_injection
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason view hackers (and other views), PING
> On Sat, 12 May 2007, Matt S Trout wrote:
> [...]
>>> call for the view. The default for this in the Mason view seems to be
>>> the
>>> same as that in the TT2 view, which is to use $c->req->match. That
>>> seems
>>> reasonable to me.
>>
>> That's one of the things that needs to change, the standard for views is
>> now $c->action.
>
> Easy enough to fix.
>
>
> -dave
fwiw, this is what i use as my default:
$c->stash->{template} = $c->action->namespace . '/'
. $c->action->name . '.html';
but i don't know how well that plays with chained actions.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] ActiveRecord for Perl
> On 5/22/07, Adam Bartosik <[EMAIL PROTECTED]> wrote: > I doubt there's anything worth porting in ActiveRecord that one of the > many Perl options (DBIx::Class, Rose::DB::Object, Class::DBI, Tangram, > Alzabo) doesn't provide. > > - Perrin one thing i really like about AR is the association proxies, where relationships themselves are objects you can call methods (ie, find) on class User < ActiveRecord::Base has_many :items end class Item < ActiveRecord::Base belongs_to :user end items = user.items item = user.items.find(params[:id]) new_item = user.items.create!(params[:item]) you can get close to that with RDBO's $user->find_items() (and maybe DBIC has something similarish) but the ruby way here feels so much better! ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] debug mode
i use the following in sandbox httpd.conf's:
BEGIN { $ENV{MYAPP_DEBUG} = 1; }
use MyApp;
and s/1/0/ for prod.
> What is the best way to deal with the -Debug flag between a production and
> development environment? Obviously its not desirable to go into the file
> and remove the flag every time the code goes to prod. I see you can
> start
> the stanalone server with -d to force debug. I think I remember about an
> environment variable to set debug also. Is the preferred method to take
> the
> hardcoded flag out and use one of these, or is there another way (such as
> a
> config option)? How are people dealing with this?
>
> Thanks,
> John
> ___
> List: Catalyst@lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] debug mode
> On Mon, Jun 04, 2007 at 12:55:38PM -0700, Dylan Vanderhoof wrote:
>> Oh, missed this email. Yours looks better than mine. =)
>
> Except for being a performance hit on every single method call on $c
> (there's
> a reason I keep telling people not to make everything a plugin ...).
does *{"$class\::debug"} = sub { 1 }; somehow avoid this performance hit?
or are you talking about the extra call to $c->config?
>> > -Original Message-
>> > From: Matthew Pitts [mailto:[EMAIL PROTECTED]
>> > Sent: Monday, June 04, 2007 8:23 AM
>> > To: The elegant MVC web framework
>> > Subject: RE: [Catalyst] debug mode
>> >
>> >
>> > I wrote a cheap little plugin for my app to override
>> > $c->debug to return
>> > the debug flag from $c->config->{debug}. As such:
>> >
>> > package MyApp::Plugin::DebugMode;
>> >
>> > sub debug {
>> > my $c = shift;
>> >
>> > return $c->config->{debug} || 0;
>> > }
>> >
>> > 1;
>> >
>> > Then I just add a "debug: 1" line to my DEV/QA/UAT configs and make it
>> > "debug: 0" for my PROD config. It's been working pretty well for me.
>> >
>> > Enjoy,
>> >
>> > Matt Pitts
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
plugins; was Re: [Catalyst] debug mode
if the catalyst base controller class provided an easy way to access $c
from a utility method (vs an action method, which receives $c
'automatically'), then i think plugins might be a little less popular.
some of my bits have ended up as controllers because i'd rather
$c->twiddle_with_session();
than
$self->twiddle_with_session($c);
session is just an example here, it could need something from $c->config,
$c->request.. it doesn't strike me as particularly wrong for the methods
to live on $c when they will primarily only be calling other methods on
$c.
still, depending on frame of reference, i've moved/developed some things
to/as base controllers, and it has helped to have something like this in
my Base::Controller, but maybe it should come for free?
__PACKAGE__->mk_accessors('_context');
sub _ACTION : Pricvate {
my ($self, $c) = @_;
$self->_context($c);
$self->SUPER::_ACTION($c);
}
> On Tue, Jun 05, 2007 at 08:40:52AM -0400, Matthew Pitts wrote:
>> On Tue, 2007-06-05 at 01:18 +0100, Matt S Trout wrote:
>> > On Mon, Jun 04, 2007 at 12:55:38PM -0700, Dylan Vanderhoof wrote:
>> > > Oh, missed this email. Yours looks better than mine. =)
>> >
>> > Except for being a performance hit on every single method call on $c
>> (there's
>> > a reason I keep telling people not to make everything a plugin ...).
>>
>> Am I correct in saying that the NEXT overhead is proportional to the
>> number of packages in the ISA chain and not the number of methods the
>> plugins override? If so, then if I were to bring all my plugins into one
>> big "framework" plugin would that improve the NEXT performance?
>
> Or you could avoid making them plugins. 9 times out of 10 they should've
> been a model, a controller base class or an external utility module - see
> the ExtendingCatalyst POD for more info.
>
> --
> Matt S Trout Need help with your Catalyst or DBIx::Class
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: plugins; was Re: [Catalyst] debug mode
> if the catalyst base controller class provided an easy way to access $c
> from a utility method (vs an action method, which receives $c
> 'automatically'), then i think plugins might be a little less popular.
>
> some of my bits have ended up as controllers because i'd rather
oops, s/controllers/plugins/ in the line above..
>
> $c->twiddle_with_session();
>
> than
>
> $self->twiddle_with_session($c);
>
> session is just an example here, it could need something from $c->config,
> $c->request.. it doesn't strike me as particularly wrong for the methods
> to live on $c when they will primarily only be calling other methods on
> $c.
>
>
> still, depending on frame of reference, i've moved/developed some things
> to/as base controllers, and it has helped to have something like this in
> my Base::Controller, but maybe it should come for free?
>
> __PACKAGE__->mk_accessors('_context');
>
> sub _ACTION : Pricvate {
> my ($self, $c) = @_;
> $self->_context($c);
> $self->SUPER::_ACTION($c);
> }
>
>
>> On Tue, Jun 05, 2007 at 08:40:52AM -0400, Matthew Pitts wrote:
>>> On Tue, 2007-06-05 at 01:18 +0100, Matt S Trout wrote:
>>> > On Mon, Jun 04, 2007 at 12:55:38PM -0700, Dylan Vanderhoof wrote:
>>> > > Oh, missed this email. Yours looks better than mine. =)
>>> >
>>> > Except for being a performance hit on every single method call on $c
>>> (there's
>>> > a reason I keep telling people not to make everything a plugin ...).
>>>
>>> Am I correct in saying that the NEXT overhead is proportional to the
>>> number of packages in the ISA chain and not the number of methods the
>>> plugins override? If so, then if I were to bring all my plugins into
>>> one
>>> big "framework" plugin would that improve the NEXT performance?
>>
>> Or you could avoid making them plugins. 9 times out of 10 they should've
>> been a model, a controller base class or an external utility module -
>> see
>> the ExtendingCatalyst POD for more info.
>>
>> --
>> Matt S Trout Need help with your Catalyst or DBIx::Class
>
>
> ___
> List: Catalyst@lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forms generation
> On Thu, Jun 14, 2007 at 11:33:17AM -0700, Michael Reece wrote: >> i've been looking at Form::Processor and similar, but the tricky bit >> for me is that i want the view to be both responsible for generating >> the HTML and deciding which fields belong on which form, without an >> intermediate form object that has to inform both the view and >> controller. > > You can't let the View decide because the client can post whatever > they feel. right, this my attempts to let the view still decide, without trusting the client post, by letting the view register (in the session) exactly which fields were provided, and then have the controller look at only those fields. > And I the Controller shouldn't have to bother with > individual fields, but just if the entire post is valid or not (as the > controller needs to know what page to return). i've been leaning towards the models providing the validation profiles for whatever subset of fields the view was allowed to render. > But say someone wants to change their password -- you have to validate > that the old password is correct, the new password matches the > "Enter password again:" field, and that they are different from the old > password. How do you communicate that logic back to the controller or > whatever in the session? the answer is by allowing the model to provide the validation coderef for the password field, which notes it has a dependency on the old_password and password_confirm fields, makes the appropriate comparisons, et al. > It makes sense to have a separate form object to handle that work. i'll probably realize that as soon as i try to swap DFV for RHTMF or other, and wish i had abstracted or adopted a general API, but until then i'm happy enough with models returning DFV validation closures, et al.. but only if that also supports my goal of not having the authoritative list of fields to be rendered defined in a .pm or .yml file, but in the .html template where it belongs imho. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Serving server-dependent static content
Catalyst::Plugin::Static::Simple can more or less do what you want.
http://search.cpan.org/~agrundma/Catalyst-Plugin-Static-Simple-0.19/lib/Catalyst/Plugin/Static/Simple.pm#Including_additional_directories
note this example provides a sub-ref in the static include path, and that
sub receives $c, and thus can inspect $c->request or $c->config or
whatever else it needs to decide which path(s) to include.
however, ultimately i had issues with this plugin because it really wants
to serve up anything with any extension (but for an exception list),
rather than only anything prefixed with /static/. and for what did match
/static/, it provided no easy way to shift off that path part, so it ended
up looking in /path/static/static/ unless i made overrides elsewhere to
try to fix up the $c->req->path myself (or risk exposing the parent
directory, shudder).
finally, you will want to solve this via your webserver config. however,
sometimes you don't want to rely on apache during development (perhaps you
favor myapp_server.pl).
in my case, i wanted mason-esque inheritance for static files, so if a
cobrand does not provide an image it is served from the default
collection. for production, it is done with mod_rewrite rules for each
virtual host.
but for development, i took my favorite bits out of
Catalyst::Plugin::Static::Simple and created a Myapp::Controller::static
that handles it. overall, i think the behavior works better as a
controller than a plugin, so usual action methods can be used to control
routes for 'static' files, rather than a complex and unsatisfying array of
$c->config options. but for now, that means rolling your own.
michael.
> Good afternoon - I am working on a Catalyst application that serves
> dynamic
> website content for multiple sites, and I've run into some difficulty
> about
> static content. Each website has unique static content (images, css, rss)
> and I am trying to serve that static content from the site's unique
> directory. I have found lots of documentation on how to serve all static
> content from a single directory, but not much on a servername-dependent
> directory. For example:
>
> Request: http://www.timjohnson.com/css/global.css
> Should be served with: /var/www/html/sites/timjohnson.com/css/global.css
>
> I came close to making this happen just using the Alias directive in
> httpd.conf, but I couldn't get that to accept a variable, %{SERVER_NAME},
> in
> it. If someone has a solution from the Apache side, that's fine but I
> suspect that it might be easier to do this with
> Catalyst::Plugin::Static::Simple, though I again have not figured out how
> to
> tell it to use a variable name when it creates the path the request is
> supposed to be mapped to. I am sending this to the Catalyst list because
> I
> suspect it might be something other people have faced before using
> Catalyst.
>
> My setup is a recent version of Catalyst running on Apache 2.2 with
> mod_perl. Any suggestions would be quite welcome - thank you very much.
>
>
>
>
> Peter Lytle
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Serving server-dependent static content
> On 8/12/07, Peter Lytle <[EMAIL PROTECTED]> wrote: >> If someone has a solution from the Apache side, that's fine but I >> suspect that it might be >> easier to do this with Catalyst::Plugin::Static::Simple > > Don't serve static content through perl. Let your webserver do it. > Usually people just set up virtual hosts with different > DOCUMENT_ROOTs. Is there a reason that won't work for you? > > - Perrin a lot of times, 'static' content is found via database queries. and sometimes that content needs to be protected from unauthorized viewers, and your authorization mechanisms are already built into your application, so you can't just use Alias/Rewrite directives to still have apache serve up that tree. that said, is there a way to have catalyst defer back to the web server, after deciding not to issue a 403? has anyone experimented with using $c->res->status(-1) for this purpose? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
