Straight templates (Was: Re: [Maypole] model_class issues on 1.7->2.x upgrade?)

[Simon Flack]

On Sat, 4 Dec 2004 12:14:13 -0500, Jesse Sheidlower wrote
> On Sat, Dec 04, 2004 at 04:20:52PM +0000, Simon Flack wrote:
> > On Fri, 3 Dec 2004 23:20:23 -0500, Jesse Sheidlower wrote
> > > On Thu, Nov 18, 2004 at 01:03:36PM -0800, Peter Speltz wrote:
> > > > 
> > > > --- Jesse Sheidlower <jester@panix.com> wrote:
> > > > 
> > > > > 
> > > > > Before I spend too much time debugging this, I thought someone
> > > > > might have run into this and could help out.
> > > > > 
> > > > > I just upgraded Maypole from 1.7 to 2.04. Several applications
> > > > > were unaffected, but one relatively complex one, which has some
> > > > > authentication juju going on, had problems. I'm now throwing
> > > > > errors of the sort:
> > > > > 
> > > > >   caught authenticate error: Can't call method "can" on an undefined
> > > > >   value at...
> > > > > 
> > > > > with the relevant line, in the main module, being
> > > > > 
> > > > >   return $r->model_class->sub_authenticate($r)
> > > > >    if $r->model_class->can("sub_authenticate");
> > > > > 
> > > > 
> > > > What's the main module? You're driver?   Are you going to a page that
doesn't
> > 
> > Indeed, is that code in your driver, or are you referring to
> > call_authenticate() in Maypole.pm? If it's the former, that's your problem.
> 
> Yes, it was in my driver. I was following the instructions that are 
> in Maypole::Manual::Request, and that are on the Wiki's 
> authentication page. Perhaps these should be changed :-)

Good point. I've made a small change to the wiki to check r->model_class
before calling method on it.

> > > > have a model class associated with it like a straight template?   Wrap
above
> > > > code in an "if ($r->model_class) { warn "No model classs in sub
authenticate; 
> > > > .. . } and see if everything works ok. Check error log for warnings
and see
> > > > what situations you get the warning.
> > > 
> > > Just coming back to this after some time working on the real $JOB.
> > > 
> > > Indeed, this was only happening on the frontpage template; anything
> > > associated with a model class works fine.
> > > 
> > > Which leads me to two questions:
> > > 
> > > 1. What changed from 1.7 to 2.x so that visiting such a page no 
> > > longer works, and more to the point what do I need to do under 2.x 
> > > so that visits to such a page don't fail? Is there a way to default 
> > > things to the base model class if there's no other?
> > 
> > 2.x authenticates plain templates but 1.7 didn't. But that shouldn't cause a
> > problem in itself, it depends what your authenticate() method is doing.
> 
> My authentication routine was not dissimilar to what's in the above-referenced
> pages. I have different access levels, but the code is straightforward.
> 
> For now, though, just sticking a
> 
>   return OK if $r->{template} eq "frontpage";
> 
> at the top of the routine seems to have done the trick. For this app
> it's my only template page. Perhaps for others, if I had template
> pages that did need authentication, I'd have to do more.
> 
> > When Maypole is given a request that doesn't have a model, or the action isn't
> > public, $r->model_class is undefined. So if you're calling a method on
> > $r->model_class in your authenticate() method, you need to check that there is
> > a model_class first.
> > 
> > BTW, Maypole checks to see if there's a model_class->authenticate() and if so,
> > calls it before calling $r->authenticate. So you shouldn't need to do that
> > yourself in your driver's authenticate() method.
> 
> See above. It's in the docs!

Interesting, Maypole has handled model_class->authenticate since 1.0. I
suppose authenticate and sub_authenticate are separate hooks, but that's not
particularly clear in the docs.

--simonflk