--- Dave Howorth <dhoworth at mrc-lmb.cam.ac.uk> wrote:
> Peter Speltz wrote:
> > while we're on subject. here's some subs useful for making the addnew
> > permission form with select boxes. I added these to M::P::Authorization.pm.
>
>
> Hi Peter,
>
> Thanks for the subs. I'm not sure their natural home is
> M::P::Authorization.pm though?
>
> > # pjs -- ok_model_classes() -- turns ok tables into a list of classes
> > sub ok_model_classes {
> > my ($r) = @_;
> > map { $r->config->model->class_of($r, $_) } keys
> %{$r->config->ok_tables};
> > }
>
> This is using ok_tables to decide what classes it's possible for the
> authorization system to manage. I would rather use the authorization
> system to determine what's possible and allowed and deduce an
> appropriate value for display_tables and ok_tables for a particular
> request from that.
>
This intention completely blew over my head. :) Interesting though. Question:
What do you mean by Maypole is confused about authorization/authentication. my
take on Maypole access /authentication/authoriztion is :
ok_tables determines access
M::P::A:UsersessionCookie authenticates
M::P::Authorize authorizes
I'm pretty happy with that but i may be confused and am no expert on a/a/a.
> But in any event I think this sub would belong in the model rather than
> the authorization subsystem.
>
> > # returns list of public actions for model class
> > sub model_actions {
> > my ($r, $model) = @_;
> > #$model ||= $r->model_class;
> > die "No model to get actions for." unless $model;
> > use Class::Inspector;
> > my $methods = Class::Inspector->methods($model);
> > my @actions = ();
> > for my $meth (@$methods) {
> > push @actions, $meth if $model->is_public($meth);
> > }
> > @actions;
> > }
>
> Again, I think this method properly belongs in the model class. I
> originally put it in the driver class out of laziness! I find it's
> easier to prototype things like that.
>
I thought so to. then i thought maypole determined the action. then i realized
its the model that does. :)
> > To use them i have this huge ugly sub prep_form_input in my permission
> class.
> > It's like an AsForm but just for this one class.
>
> I think this is view-specific? It's setting up template arguments, it's
> making use of particular methods of dealing with cgi parameters and
> X/HTML output elements etc. There isn't really anywhere for
> class-specific view-related code that comes to mind (rereading that,
> perhaps a TT plugin is the obvious place?), so I guess the model class
> where you've got it is probably best. It's an action, or a large part of
> one. Some (all?) of the view-related code could be moved to the template
> itself to achieve better separation.
>
Ahh, this brings me to my enduring quesiton of model and view separation.
A model knows the data and the forms of the data it needs. Its all defined in
db shema. In short the model knows exactly what type of form it needs and the
View knows none of this. Its the dumbest thing on the block. So my argument is
why should I the programmer program inputs in the views? The model can do that
so much easier since it knows what it needs.. Then the view will just worry
about displaying them. Making things pretty. This is why i'm a big fan of
AsForm and HTML::Element. They saved my life :).
=====
pjs
__________________________________
Do you Yahoo!?
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT