NAME

Jifty::Manual::Cookbook

DESCRIPTION

This document aims to provide solutions to common questions of "How do I do x with Jifty?" While the solutions here certainly aren't the only way to do things, they're generally the solutions the developers of Jifty use, and ones that work pretty well.

HOW DO I ...

Limit access to pages to logged-in users

The best place to do this is probably in your application's Dispatcher. If, for example, you wanted to limit access to /secret to logged-in users, you could write:

    before qr'^/secret' => run {
        unless(Jifty->web->current_user->id) {
            Jifty->web->tangent('/login');
        }
    };

Then, in your login form component, you would write something like:

    <% Jifty->web->return(to => '/', submit => $login_action) $>

The combination of the tangent and return will cause the user to be returned to wherever they came from. See Jifty::Continuation for more information.

If you want model-level access control, Jifty provides a ready-built ACL system for its models; See Jifty::Manual::AccessControl for details.

Finally, you can also allow or deny specific actions in the dispatcher, to limit who is able to perform what actions -- see Jifty::API.

Take actions based on data in URLs

You can add actions to the request based on data in URLs, or anything else, using Jifty::Request::add_action. For example, suppose you wanted to make the path /logout log the user out, and redirect them to the home page. You could write:

    before '/logout' => {
        Jifty->web->request->add_action( class => 'Logout' );
        Jifty->web->request->add_action(class     => 'Redirect',
                                        arguments => { url => '/' });
    };

Pass HTML form input directly to components

Sometimes, you don't want to take an action based on input from HTML forms, but just want to change how the page is displayed, or do something similarly transient.

Jifty::Action is great, but it doesn't have to be the answer to everything. For cases like this, it's fine to use typical HTML <input>s. Their values will be accessible as request arguments, so you can fetch them with get in the dispatcher, and they will be passed as arguments to top-level Mason components that list them in <%args>. And don't worry about namespace conflicts with Jifty's auto-generated argument fields -- Jifty prefixes all its names with J: so there won't be a problem.