[jifty-devel] Using Authentication::Password and Template::Declare

Thu Aug 16 23:14:23 EDT 2007

I just submitted a patch to the repository that should make sure
use_mason_wrapper() works. It's a little bit kludgy as it adds a new global
variable to mason requests: $jifty_internal_request, which is set to true if
you call Jifty->handler->mason->show() and pass arguments. Otherwise it is
false.

This is then used in the autohandler to determine if this is a new request
or not.

I've also fixed the error redirect from /errors/requested_private_component
to /__jifty/error/requested_private_component.

I've used Mason for a long time, but I'm not familiar enough with it's guts
to know if there's a way to make it treat a call to exec() so that
autohandlers are not executed, as would be (I believe) the case for a
typical component execution from within a Mason template (i.e., <& foo &>).

Cheers,
Andrew

On 8/15/07, Andrew Sterling Hanenkamp <sterling at hanenkamp.com> wrote:
>
> I didn't forget about it, but it took me until now to get around to
> playing with this. I have the test built to reveal the issue, but the test
> case created blows up a lot of other tests (most of the
> Jifty::Test::WWW::Mechanize tests in t/TestApp/t), so I'm not going to
> commit it until I've got the fix.
>
> If anyone else wants to take a crack at this, feel free. I'm going to see
> if I can get the base_comp fixed up correctly so that Mason realizes that
> the caller of /_elements/wrapper isn't an external request.
>
> Cheers,
> Andrew
>
> On 8/7/07, Edward Funnekotter <efunneko at gmail.com> wrote:
> >
> > Thanks again.  I had been following the same trail as you since my last
> > message, albeit with less knowledge and more confusion.  I had already
> > attempted to adopt the autohandler and comment out the check, which did
> > allow the page to render properly.  I agree that this is not the best long
> > term solution.  Originally, I had no View.pm class at all, but in that
> > case I wasn't seeing my modified wrapper show up for the login/signup/etc.
> > pages.  I think the proper solution is to learn how to implement the wrapper
> > in T-D.  While I am at it, I probably should convert my other pages too.
> >
> > Ed
> >
> >
> > On 8/7/07, Andrew Sterling Hanenkamp < sterling at hanenkamp.com> wrote:
> > >
> > > EdF,
> > >
> > > Erm... I only new that answer because I added the basic POD there
> > > recently rather than having actually tried it. ;)
> > >
> > > Digging into how use_mason_wrapper() works and then the errors, it
> > > looks like you've tripped on a couple bugs. I'm not an authority on these
> > > particular parts of Jifty, but it looks like the first problem is that the
> > > wrapper method defined in use_mason_wrapper() can't actually work unless the
> > > share/web/templates/autohandler is tweaked, but may not need any changes in
> > > and of itself.
> > >
> > > The share/web/templates/autohandler does need at least one update and
> > > that is:
> > >
> > > if ($m->base_comp->path =~ m|/_elements/|) {
> > >     # Requesting an internal component by hand -- naughty
> > >     $m->redirect("/errors/requested_private_component");
> > > }
> > >
> > > This path "/errors/requested_private_component" may have been a good
> > > path at some point in the past, but there's no there there now. This
> > > probably needs to be changed to /__jifty/error/requested_private_component
> > > or something similar and then a component added there to handle the issue
> > > (or maybe it just needs to die here).
> > >
> > > The other update here needs to be that either the request made by
> > > calling Jifty::View::Mason::Handler::handle_comp() needs to fix it up so
> > > that base_comp is set correctly to the path of the page being handled by
> > > Jifty::View, or needs to set a flag or something to keep the error redirect
> > > from happening.
> > >
> > > I don't know what's best in this particular case. I'll see if I can
> > > get a test case put together sometime tomorrow though (unless someone wants
> > > to beat me to it or I don't have time or forget, etc.).
> > >
> > > In the meantime, EdF, I suggest either implementing your wrapper in
> > > T-D without Mason (which can be done by overriding various render_*
> > > methods), remove your App::View class altogether (which is working on our
> > > Metrics application just fine) or doing the following as a hack work-around:
> > >
> > >
> > > bin/jifty adopt web/templates/autohandler
> > >
> > > and modify share/web/templates/autohandler (which was just created in
> > > your local application) and modify it so that /_elements/wrapper is let
> > > through that if-statement. For development purposes, I don't imagine that's
> > > too heinous and it might not hurt you in a production environment, but I'd
> > > still want the real fix before I published my app.
> > >
> > > Anyway, that's my thoughts.
> > >
> > > Cheers,
> > > Andrew
> > >
> > > On 8/7/07, Edward Funnekotter < efunneko at gmail.com > wrote:
> > > >
> > > > Thanks for your quick response Andrew.  I am working off the latest
> > > > T::D, so the use_mason_wrapper() method is available.
> > > >
> > > > This did change my output a bit.  Now my page gets redirected to
> > > > errors/requested_private_component, which it complains about since it seems
> > > > that it doesn't exist for me.  Do I have to declare wrapper to be publicly
> > > > available?  I will keep digging myself, but if you happen to know the answer
> > > > it would be appreciated.
> > > >
> > > >
> > > >
> > > > On 8/7/07, Andrew Sterling Hanenkamp < sterling at hanenkamp.com>
> > > > wrote:
> > > > >
> > > > > EdF,
> > > > >
> > > > > I think we need to clean up some of the remarks regarding the
> > > > > usability of the Template::Declare stuff. It does not have the maturity of
> > > > > Mason, but I wouldn't say there are bugs crawling all over anymore. (At
> > > > > least not the latest repository version, I'm not sure what state the latest
> > > > > CPAN release is in.) I'd say it's certainly suitable for production use. The
> > > > > big problems now tend to be those that are resolved with more time
> > > > > investment in development.
> > > > >
> > > > > An /_elements/wrapper in Mason ought to work. I'm doing it on one
> > > > > of my applications which was started prior to the TD views being added to
> > > > > Jifty and I've never converted it.
> > > > >
> > > > > Do you have a View class defined? If you do, that might be the
> > > > > source of some of the trouble. Since the TD docs are spread across several
> > > > > classes, it might not be clear (and there's no example in this particular
> > > > > case either), but you should be able to call:
> > > > >
> > > > > __PACKAGE__->use_mason_wrapper();
> > > > >
> > > > > in your View class to switch it over to requesting
> > > > > /_elements/wrapper from Mason. That's defined in
> > > > > Jifty::View::Declare::BaseClass.
> > > > >
> > > > > Again, this is all based on using Jifty from a recent fetch from
> > > > > the Subversion repository. I don't know how different the CPAN release is.
> > > > >
> > > > > Cheers,
> > > > > Andrew
> > > > >
> > > > > On 8/7/07, Edward Funnekotter < efunneko at gmail.com> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I have been building an app recently and decided to try to use
> > > > > > the Authentication::Password plugin to handle my user authentication.  Since
> > > > > > the Template::Declare stuff still looked fairly new ('BUGS: Crawling all
> > > > > > over, baby. Be very, very careful.") I figured I would stick to Mason
> > > > > > templates.  My problem is that I have a _elements/wrapper that controls the
> > > > > > main elements of each page, except for the views that are inherited from the
> > > > > > Authentication::Password plugin.  They seem to not get any wrapper that I
> > > > > > can see.
> > > > > >
> > > > > > Some digging shows that they are using the Template::Declare
> > > > > > paradigm.  My question is, how do I get those pages to use my wrapper.  If I
> > > > > > can't do that, how do I make a Template::Declare copy of my wrapper and get
> > > > > > those pages to use it?  I did read through the documentation, but that
> > > > > > didn't really clarify anything.  If there is a tutorial somewhere for
> > > > > > Template::Declare, please just point me to it or point me to some example
> > > > > > code.
> > > > > >
> > > > > > Thanks,
> > > > > > EdF
> > > > > >
> > > > > > _______________________________________________
> > > > > > jifty-devel mailing list
> > > > > > jifty-devel at lists.jifty.org
> > > > > > http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > jifty-devel mailing list
> > > > > jifty-devel at lists.jifty.org
> > > > > http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > jifty-devel mailing list
> > > > jifty-devel at lists.jifty.org
> > > > http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
> > > >
> > > >
> > >
> > > _______________________________________________
> > > jifty-devel mailing list
> > > jifty-devel at lists.jifty.org
> > > http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
> > >
> > >
> >
> > _______________________________________________
> > jifty-devel mailing list
> > jifty-devel at lists.jifty.org
> > http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070816/9b8abd06/attachment-0001.htm