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/
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] Example app showing user to "item" authorization?
On 9 Dec 2008, at 04:24, bill hauck wrote:
So my question: is there an example application or best practice on
how to implement a check on all calls to see if the user should be
accessing a specific item? I guess this would apply to any type of
system: blog, auction, cms, etc. -- they all require checking if a
specific user can edit a specific item.
Assuming that you're using DBIx::Class, then the common way of doing
this would be to use ResultSet chaining to limit things.
What you do is add a 'limit_by_user' method (name is not important -
just pick one and stick to it for your entire app) on each ResultSet
class which you can pass $c->user, and have it return a filtered
result set..
You then arrange your controllers such that you will call this method
on all resultsets before actually searching them. The simplest
strategy is to just have code like:
$c->stash->{project} = $c->model('DB::Project')->limit_by_user($c-
>user)->find_by_foo($foo);
whenever you want to do a search.
This works well for simple cases. In more complex cases you can then
use any technique available to have the user filtering logic in one
place (and resultSet agnostic), and have it called from anywhere it
is needed - such as explicitly forwarding to an action to do the
filtering, or inheritance of a common path-part in all your
controllers (using Chained dispatch), or having a final set of
filtering before passing things to your templates in an 'end' action..
The trick is to use the fact you can say, $rs = $schema->resultSet
('Project'); $rs = $rs->search( # limit by criteria 1 ); $rs = $rs-
>search( # limit by criteria 2 ); etc, as many times as you need to
build up a complex search, and adding a common method to your
resultSet classes so that you can do the user filtering in one place.
Which technique to actually use to call into this common user-
filtering code is very much up to you (and varies depending on how
you have built your application / what type of app it is / what the
URL structure is like, etc), but most people would recommend looking
at Chained actions as they tend to naturally make this sort of thing
easy.
I hope that makes enough sense for you to have some ideas about where
to start without confusing you utterly!
Cheers
t0m
___
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/
[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] 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" > 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] 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
[Catalyst] Beginner Question: Controller Layout
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/
Re: [Catalyst] [Announce] Catalyst-Runtime 5.8000_04 shipped to CPAN
On 9 Dec 2008, at 12:46, Guillermo Roditi wrote: 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. No it doesn't (immutable)? I agree that all 'real' Moose classes shouldn't be breaking the meta method like this, but the fact is that there *IS* real code out there which is going to be broken by this, and it's something which we can _avoid_ breaking without too much effort.. Sure, we should be warning people, but breaking their applications when we don't _need_ to just seems silly. Attached nasty hackery which makes my initial test pass, proving that it is possible.. Cheers t0m meta-method.diff2 Description: Binary data ___ 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
Jay and J, Sounds great. Thank you both very much. Kennedy On Sat, Nov 29, 2008 at 1:56 PM, Jason Kuri <[EMAIL PROTECTED]> wrote: > Hello All, > > A new version of the Catalyst Authentication plugin is winging it's > way to CPAN (0.100091.) This update includes the excellent > 'Catalyst::Authentication::Realm::Progressive' realm written by J. > Shirley. > > The Progressive Realm allows you to, with a single call to $c- > >authenticate(), make multiple authentication attempts one at a time, > until one of them succeeds (or they all fail.) This allows you to > check multiple authentication realms to attempt to authenticate a user. > > Some samples of how you might use this are: > > 1) Legacy authentication / migration to new system. If you can't > merge the db's for whatever reason, you could try to authenticate > against the new system, followed by the legacy system. > > 2) Temporary passwords - If you have a separate auth method for > 'temporary' auth - forgot password - initial confirmation, etc, you > can attempt to auth against the temporary password realm, then the > main db. (or the other way around) > > 3) Auth against a local system, followed by a remote system if the > user is not found. > > I'm sure you can come up with hundreds of other uses. > > Please thank J. Shirley for his excellent module. > > 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/ > ___ 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/
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] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Sun, Dec 7, 2008 at 1:47 PM, Tomas Doran <[EMAIL PROTECTED]> wrote:
>
> I'm not sure if the correct fix for the lies in Catalyst, or MX::E::CAF,
> but:
>
> http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=8781
>
> is the minimal test case I've been able to produce for the breakage of the
> Catalyst::Plugin::Authentication's tests and which people still using the
> back-compat auth plugins in their apps would be seeing (if any of them were
> trying it and shouting).
>
I think it's the fact that the mk_accessor call is in BEGIN {} because the
adopt happens at compile time, but the role application within it happens at
runtime.
I am giving this a wontfix until I can figure out if it is even fixable. I'm
not giving up on you, though. Why is it necessary to have the accessors
created at BEGIN time?
I'll experiment with having the role consumption happen in a BEGIN block,
but I don't know what the deal will be with it. I'll keep you all posted.
--
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] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Tue, Dec 09, 2008 at 08:30:10AM +, Tomas Doran wrote: > What versions of Moose and Class::MOP are you running? 0.60 and 0.68 respectively (from perldoc -m Foo |grep VERSION) I'll see if I can find somewhere to actually install Catalyst-Runtime properly, rather than just using a path hack. I'm just worried about knackering my installation and not being able to revert. I did suggest it might be me :) -- Chisel Wright e: [EMAIL PROTECTED] w: http://www.herlpacker.co.uk/ Everyone's first vi session: ^C^C^X^X^X^XquitqQ!qdammit[esc]qwertyuiopasdfghjkl;:xwhat ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
On 8 Dec 2008, at 22:07, Chisel Wright wrote:
MyApp is fine under 5.7014, starting it with:
PERL5LIB=${HOME}/development/open_source/dev-tests/Catalyst-
Runtime-5.8000_04/lib
CATALYST_DEBUG=1 DBIC_TRACE=1 ./script/parley_server.pl
--host=localhost -r -rd 2 --port=3000
any hits to the app give me the following:
[info] *** Request 3 (0.005/s) [11697] [Mon Dec 8 22:05:46 2008] ***
[error] Caught exception in engine "Attribute (headers) does not
pass the type constraint because: Validation failed for 'Header'
failed with value HTTP::Headers=HASH(0xa6dee88) at /usr/local/share/
perl/5.10.0/Moose/Meta/Class.pm line 193
That's quite strange as I didn't think there were any type
constraints in Catalyst. I just got the latest version of your app
and tried it and it works for me (at least the first page does)..
What versions of Moose and Class::MOP are you running?
Cheers
t0m
___
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/
