Re: [Catalyst] [Announce] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Sun, Dec 7, 2008 at 4:38 PM, Tomas Doran [EMAIL PROTECTED] wrote: Please find attached a simple test case for the behavior needed by Catalyst::Plugin::Cache::Curried (and anything else which says __PACKAGE__-mk_accessors(qw/ meta /)) - found by looking at MojoMojo's current test failures. Yeah dude. wontfix. You don't get to take over Moose's meta method. Immutable replaces the accessor when inlining the meta method. You can argue with Moose over who has the right to that particular method name, but that's out of the scope of my module. -- Guillermo Roditi (groditi) ___ 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] ANNOUNCE: Progressive authentication attempts
On Sat, Nov 29, 2008 at 11:56:02AM -0700, Jason Kuri wrote: Please thank J. Shirley for his excellent module. Thank You! This came at the perfect time in a key internal project at work. It's working like a charm with LDAP falling through to Minimal realms. Chisel -- Chisel Wright e: [EMAIL PROTECTED] w: http://www.herlpacker.co.uk/ Pink is my favourite crayon ___ 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/
[Catalyst] Problem with the order of action
Hi.
Let's say I have (and I do) something like this in one controller:
sub create : Path('/users/new') {
and something like this in another controller:
sub attribute : Regex('^([^/]+)/([^/]+)(?:/page/(\d+))?$') {
My goal here is to try to match the url with /users/new and, that failing,
try matching with that regex up there.
My problem, as many of you will have figured out, if that /users/new is
bumping into the attribute sub (which makes sense, as it does match the
regex).
Is there any way of tampering with the order the methods in the controllers
are tried? (other than changing the names of the controllers, hopefully)
Thanks,
jac
--
José Castro
http://jose-castro.org/
___
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] Beginner Question: Controller Layout
This dovetails nicely with my question ([Catalyst] Example app showing user to item authorization?). For this site how would you control which user/band edits which scheduled events, uploads pictures, etc.? Do you have each function check the database? Do you write one function for each type of item and simply call it? Any examples / guidance is greatly appreciated. Thanks --- On Tue, 12/9/08, David Schmidt [EMAIL PROTECTED] wrote: From: David Schmidt [EMAIL PROTECTED] Subject: [Catalyst] Beginner Question: Controller Layout To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Tuesday, December 9, 2008, 3:17 PM Hello list, I am at the point of starting a new project and have yet to choose a controller layout. my application is a site where: music bands can - register - fill out (and later edit) a profile - upload pictures and songs - schedule events which will be displayed on a calendar visitors can - browse all of the above information - register to a newsletter admins can - edit all of the above stuff Well, I suppose you get the picture. I am hoping to get some guidance here from someone who has experience One solution that comes to my mind would be to make a controlller for each role (admin, band, visitor) another one would be to make a controller for each type of media (songs, pictures, band, ...) Either way I am not able to tell which one is most suitable beforehand. thanks in advance david ___ 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/ ___ 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/
[Catalyst] Re: Beginner Question: Controller Layout
bh == bill hauck [EMAIL PROTECTED] writes:
bh For this site how would you control which user/band edits which
bh scheduled events, uploads pictures, etc.? Do you have each
bh function check the database? Do you write one function for each
bh type of item and simply call it?
for granular authorizations like this i'd have my controller mix-in a
base class which would provide functions like:
$self-can_edit_widget($widget_id)
then the can_edit_widget can do whatever sorts of authz necessary.
usually this means that it'll return true if the $c-user is in some
sort of administrator role or has a relationship to the widget in
question that allows for the action.
this method might be something like:
sub can_edit_widget {
my ($self, $widget_id) = @_;
my $c = $self-context;
return 1 if $c-check_any_user_role($c-user, 'administrator');
return 1 if $c-model('MyApp::Widgets')-is_owner($c-user, $widget_id);
return;
}
i'm not sure that this could be considered best practice or even
recommended, but it does allow for a mix of role based and app
specific authz. by doing the work in a mix-in class the authz logic
is easily changed (or audited) independently of what the controller is
doing. it's also nice for controllers to ask relevant questions like
can_edit_widget rather than is_owner ... if nothing else the guy
who maintains your code next will understand why you wanted to know.
k.
--
kevin montuori
[EMAIL PROTECTED]
___
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] Problem with the order of action
José Castro wrote:
Hi.
Let's say I have (and I do) something like this in one controller:
sub create : Path('/users/new') {
and something like this in another controller:
sub attribute : Regex('^([^/]+)/([^/]+)(?:/page/(\d+))?$') {
My goal here is to try to match the url with /users/new and, that
failing, try matching with that regex up there.
My problem, as many of you will have figured out, if that /users/new is
bumping into the attribute sub (which makes sense, as it does match the
regex).
Is there any way of tampering with the order the methods in the
controllers are tried? (other than changing the names of the
controllers, hopefully)
I think here you should look at what you're trying to do, and map it
onto Catalyst a little differently. That Regex is worrying me.
Have you read the documentation on the Chained method of dispatching?
I think it could be the right way to do that.
Cheers,
Toby
___
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] Beginner Question: Controller Layout
hi, David, Good morning. Recommendation == Controllers: - Musicians (might even breakdown by Music Bands/Duets and soloists). I know you mentioned about 'Music Bands' but no harm in considering if the application should have a further breakdown (good for reporting purposes). - Subscriptions And Products/Plans(if your project is going to earn you some revenue) - Attachments (possibly for operations related to your images, music and other attachments. Operations can be upload, resize, back up and so forth). - Events ( possibly to manage events) - Communications ( for your newsletters and possibly other form of communications) View: --- Within the View of each entity (which was made into a controller, ie Musicians, Subscriptions, Attachments, Events), have role checks to allow for different groups of users to do things (ie. visitors can browse information but not edit). Hope it helps. 2008/12/10 David Schmidt [EMAIL PROTECTED] Hello list, I am at the point of starting a new project and have yet to choose a controller layout. my application is a site where: music bands can - register - fill out (and later edit) a profile - upload pictures and songs - schedule events which will be displayed on a calendar visitors can - browse all of the above information - register to a newsletter admins can - edit all of the above stuff Well, I suppose you get the picture. I am hoping to get some guidance here from someone who has experience One solution that comes to my mind would be to make a controlller for each role (admin, band, visitor) another one would be to make a controller for each type of media (songs, pictures, band, ...) Either way I am not able to tell which one is most suitable beforehand. thanks in advance david ___ 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/ ___ 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] Beginner Question: Controller Layout
On Tue, Dec 9, 2008 at 7:17 AM, David Schmidt [EMAIL PROTECTED] wrote:
Hello list,
I am at the point of starting a new project and have yet to choose a
controller layout.
my application is a site where:
music bands can
- register
- fill out (and later edit) a profile
- upload pictures and songs
- schedule events which will be displayed on a calendar
visitors can
- browse all of the above information
- register to a newsletter
admins can
- edit all of the above stuff
Well, I suppose you get the picture. I am hoping to get some guidance
here from someone who has experience
One solution that comes to my mind would be to make a controlller for
each role (admin, band, visitor)
another one would be to make a controller for each type of media
(songs, pictures, band, ...)
Either way I am not able to tell which one is most suitable beforehand.
thanks in advance
david
Hi David,
Whenever I'm building a new application I always try to think of the
URI scheme, and how I can construct it to be the most RESTful and
still the most sane (the distinction between REST and RPC is to not
have create/edit/delete URIs; this is why I say RESTful rather than
strict REST).
Then I try to associate every ownership pattern that may exist. For
example, if a member can belong to one or more bands, then the member
is a root level action, and you would have /member/{id} (an important
note at the bottom to read, too).
Under a member account, you would have your bands. That would create
/member/{id}/band for a listing, and then /member/{id}/band/{id} for a
specific band.
You can continue this path down the chain for any level of ownership.
Now, as it associates to controllers is quite simple but may require a
bit of experimenting to get right. The secret sauce lies in using
base controllers to build up your individual items (band, member,
song) so that you can use the Chained dispatch type, and have
instances of the base controllers in various points of the URI chains,
with a resultset (assuming you use DBIx::Class) that is chained along
with it.
So, you can have a URI structure like:
/band/{id}/song/{id}
/member/{id}/band/{id}/song/{id}
/song/{id}
Then, you really only have to maintain one set of controllers, as the
others should consist of little more than configuration on how to
access the DBIx::Class::ResultSet to use to find the record, and then
a simple 'use parent MyApp::ControllerBase::Band;' (or whatever) and
you're set.
An important note on URI construction:
If you have lookups like /member/joe_schmoe and a RPC-based URI
structure with URIs like /thing/(create|edit|delete) then you have to
make sure that the token you use to query is never
qr/create|edit|delete/. This is a silly restriction, and it ends up
binding you to using just numeric ids or not allowing arbitrary
tokens. A popular scheme is instead to use /member/id/{numeric_id} or
/member/name/joe_schmoe then you have /member/(create|edit|delete)
without any possibility of conflict.
Hope this helps, and if you want more information you can tune into
the talk I'm giving at Orlando Perl Oasis next month (hopefully will
see you there) where I'm going over this exact subject! You can see
more details at http://perloasis.org/opw2009/
-Jay
___
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/
