Help-Site Computer Manuals
  Algorithms & Data Structures   Programming Languages   Revision Control
  Cameras   Computers   Displays   Keyboards & Mice   Motherboards   Networking   Printers & Scanners   Storage
  Windows   Linux & Unix   Mac

Recipes for common tasks in Jifty

Jifty::Manual::Cookbook - Recipes for common tasks in Jifty


Jifty::Manual::Cookbook - Recipes for common tasks in Jifty


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 ...

Create an LDAP autocomplete field

You need an action in your application. Then run

  jifty action --name LdapSearch

in lib/myApp/Action/ add the search field

  use Jifty::Action schema {

    param search =>

        autocompleter is \&ldap_search;


we need the Net::LDAP manpage and an accessor to our LDAP value.

  use Net::LDAP;


and we can write our ldap_search fonction. Search need at least 3 characters and return an array of DisplayName (login)

  sub ldap_search {

    my $self = shift;

    my $search = shift;

    my @res;

    if (length $search > 2) {

         if (! $self->LDAP() ) {

            $self->LDAP( Net::LDAP->new('');

            $self->LDAP()->bind( );



          base    => 'ou=people,dc=myorg,dc=org',

          filter => '(cn='.$filter.')',

          attrs   =>  ['uid','cn','givenname','displayname'],

          sizelimit => 10


        foreach my $entr ( $result->sorted('cn') ) {

            push @res, $entr->get_value('displayname').' ('.$entr->get_value('uid').')';



    return @res;


Add Atom/RSS Feeds ?

You could generate atom/rss feeds for virtually any model in your application. For instance, suppose there's a ``Post'' model (like a blog entry), you could use the XML::Feed manpage to do this:

    # In '/feed' template





    use XML::Feed;

    my $posts = MyApp::Model::PostCollection->new();


    my $feed = XML::Feed->new( $type );

    $feed->title( Jifty->config->framework('ApplicationName') . " Feed" );

    $feed->link( Jifty->web->url );

    $feed->description( $feed->title );

    while( my $post = $posts->next ) {

        my $feed_entry = XML::Feed::Entry->new($type);



        $feed_entry->link( Jifty->web->url . "/posts/" . $post->id );

        $feed_entry->issued( $post->created_on );

        $feed_entry->summary( $post->body );

        $feed->add_entry( $feed_entry );



    <% $feed->as_xml |n %>

And add this in MyApp/ to make URI look prettier:

    # note the case of the feed types

    on qr{^/feed/(Atom|RSS)}, run {

        set type => $1;



And of course, you need to put these in your HTML header template (conventionally that's /_elements/header):

    <link rel="alternate" type="application/atom+xml" title="Atom" href="/feed/atom" />

    <link rel="alternate" type="application/rss+xml" title="RSS" href="/feed/rss" />

Use date or time objects with the database?

On your columns, specify either

    filters are 'Jifty::DBI::Filter::DateTime'

for a timestamp (date and time), or

    filters are 'Jifty::DBI::Filter::Date'

for just a date. Jifty will then automatically translate to and from DateTime objects for you when you access the column on your model. Additionally, if you add:

    filters are qw(Jifty::Filter::DateTime Jifty::DBI::Filter::Date)

Jifty will inspect the model's current_user for a time_zone method, and, if it exists, set the retrieved DateTime object's time zone appropriately. All dates are stored in UTC in the database, to ensure consistency.

Emulate 'created_on' field like Rails ?

In Rails, if you have a field named 'created_on', it's automatically set to the creation time of the record. How can I emulate this behaviour in Jifty ?

The trick here is to use the Scalar::Defer manpage. And declare your column like this:

    column created_on =>

        type is 'timestamp',

        label is 'Created On',

        default is defer { DateTime->now },

        filters are 'Jifty::DBI::Filter::DateTime';

This approach is not really accurate, if you render this field in a form, then the defer value is evaluated by the time of rendering, which might be way eariler then the creation of record. However, it is the easiest one.

If you're using the newly recommeded JIfty::DBI::Record schema {} to declare schemas, you might find this trick not working at the moment. Please override model's before_create method instead:

    sub before_create {

        my ($self, $attr) = @_;

        $attr->{'created_on'} = DateTime->now;


Emulate 'updated_on' ?

If a lot of column could change, you can override _set method:

    sub _set {

        my $self = shift;

        my ($val, $msg) = $self->SUPER::_set(@_);

        $self->SUPER::_set(column => 'changed_on', value => defer {DateTime->now});

        $self->SUPER::_set(column => 'from', 

            value => $ENV{REMOTE_HOST}. " / ". Jifty->web->current_user->user_object->name );

        return ($val, $msg);


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(url => '/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 the Jifty::Continuation manpage for more information.

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

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

Run my Jifty app as fastcgi in Apache/Lighttpd ?

Jifty provides a really simple way to run the application as a fastcgi server. The complete instructions and examples are in 'jifty help fastcgi' for both Apache servers and Lighttpd servers. (Please cd to your app dir before running this command.)

You'll have to install CGI::Fast and FCGI module for this.

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 < <inputs >>. 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.

Perform database migration

Edit etc/config.yaml and change Database->Version to a proper value (say, 0.0.2). Then run

    jifty schema --setup

Jifty would inspect the current database and perform proper actions. You could give a --print option to see the actual SQL statements:

    jifty schema --setup --print

Use different table names than the ones Jifty automatically creates

In YourApp::Record, define a _guess_table_name sub that doesn't pluralise or pluralises differently.

Perform ajax canonicalization on a given field ?

Asking user to input something in a form is really common in a web app. For some certain form fields you want them to have a certain normalized/canonicalized form in the database, and you could do an ajax canonicalization in Jifty very easily. Let's say your User model needs a canonicalized username field to make sure those names are in lowercase. All you have to do is to define a method named canonicalize_username in your Model class, like this:

    package MyApp::Model::User;

    use base qw(MyApp::Record);

    sub canonicalize_username {

        my $class = shift;

        my $value = shift;

        return lc($value);


If the form is generated by a Jifty::Action::Record-based action (all those autogenerated CRUD actions), then this is all you need to do. And that is probably 90% of cases. Jifty::Action::Record would check if there is a method named like canonicalize_fieldname when it is rendering form fields. If found, related javascript code is generated. You do not have to modify any code in your view. Jifty does it for you.

The ajax canonicalization happens when the input focus leaves that field. You would see the effect a bit later than the value in the field is changed.

Of course, you can apply the same trick to your own Action classes.

You can use the canonicalization to change data in other fields. For example you might want to update the postcode field when the suburb field is changed.

        $self->argument_value( other_field => "new value" )

Get the ``Edit'' links to work in the ``Page info'' tool

If you click on ``Page info'', follow an ``Edit'' link for a fragment, and you get an error message saying something like

        You got to a page that we don't think exists...

then you need to ensure that the Jifty::Plugin::EditInPlace has been installed correctly. It should be in the Jifty/Plugin directory installed with the rest of the Jifty modules.

        perl -MJifty::Util -e 'print Jifty::Util->jifty_root'

will tell you where to look. If it's not there you will need to install it manually. If you still have your build files from installing Jifty you can find the module in the plugins directory.

Once you have the modules in place, or if they were already present you simply need to enable the plugin in your project config file. Edit etc/config.yml and find the ``Plugins:'' section. It will probably look like this

          Plugins: []

Change it to


            - EditInPlace: {}

Take care the indentation is significant. Use spaces, not tabs. Once you have done that you can restart your Jifty application and the edit links should then function correctly.

Use to add PNG support in IE5.5+

Jifty has included by Angus Turnbull. The HTC file will automatically add PNG support to IMG elements and also supports any element with a ``background-image'' CSS property.

If you want to use this fix, please include this one line in your CSS file, whit tag names to which you want the script applied:

    img, div { behavior: url(/static/js/ }

Alternatively, you can specify that this will apply to all tags like so:

    * { behavior: url(/static/js/ }

Check details from Angus himself. ( )

Create mutually dependent models

Sometimes you need two tables that both depend upon each other. That is, you have model A that needs to have a column pointing to Model B and a column in Model B pointing back to model A. The solution is very straight forward, just make sure you setup the base class before you load dependent model and this will just work. For example:

  package ModelA;

  use base qw/ MyApp::Record /;

  # Note that "use base..." comes first

  use ModelB;

  use Jifty::DBI::Schema;

  use MyApp::Record schema {

    column b_record => refers_to ModelB;


  package ModelB;

  use base qw/ MyApp::Record /;

  # Note that "use base..." comes first

  use ModelA;

  use Jifty::DBI::Schema;

  use MyApp::Record schema {

    column a_record => refers_to ModelA;


Otherwise, everything should work as expected.

Reuse Jifty models and actions outside of a Jifty app

    use lib '/path/to/MyApp/lib';

    use Jifty::Everything;

    BEGIN { Jifty->new; }


    use MyApp::Model::Foo;

    use MyApp::Action::FrobFoo;

From there you can use the model and action to access your data and run your actions like you normally would.

If you've actually installed your app into @INC, you can skip the use lib line.

Send out dynamically created binary data

In a Template::Declare view, do something like this:

    template 'image' => sub {

        # ...

        # create dynamic $image, for example using Chart::Clicker




Create a many-to-many relationship

You need to create two one-to-many relationships with a linking table as you normally would in pure SQL. First, create your linking table by running:

  bin/jifty model --name LinkTable

Modify the newly created MyApp::Model::LinkTable class to add new columns linking back to either side of the table:

  use MyApp::Record schema {

      column left_table =>

          refers_to MyApp::Model::LeftTable;

      column right_table =>

          refers_to MyApp::Model::RightTable;


Then create links to the linking table in MyApp::Model::LeftTable:

  use MyApp::Record schema {

      # other columns...


      column right_things =>

          refers_to MyApp::Model::LinkTableCollection by 'left_table';


Then create links to the linking table in MyApp::Model::RightTable:

  use MyApp::Record schema {

      # other columns...


      column left_things =>

          refers_to MyApp::Model::LinkTableCollection by 'right_table';


Now, add your records. To create a relationship between a row the two tables:

  my $left = MyApp::Model::LeftTable->new;


  my $right = MyApp::Model::RightTable->new;


  my $link = MyApp::Model::LinkTable->new;


      left_table  => $left,

      right_table => $right,


And to get all the ``right things'' from the left table, you need to make the extra hop in your loop:

  my $links = $left->right_things;

  while (my $link = $links->next) {

      my $right = $link->right_table;


      # Do stuff with $right


Show login box on an action submit

In app's dispatcher add the following:

    before '*' => run {

        # do nothing if user is logged in

        return if Jifty->web->current_user->id;

        # check all actions the request has. if at least one require login

        # then save them in a continuation and redirect to the login page

        tangent '/login' if

            grep $_->can('require_login') && $_->require_login,

            map $_->class, Jifty->web->request->actions;


All you have to do now is to add sub require_login { return 1 } into actions which need this functionality.

Note that you can implement complex logic in the require_login method, but it's called as class method what set a lot of limitations. That would be really cool to have access to all data of the action in this method, so you are welcome to post a better solution.

Append a new region based upon the result of the last action using AJAX

In the Administration Interface, you can create new items. You enter the information and then the newly created item is appended to the end of the list immediately without reloading the page. You can use this recipe to do something like this, or to modify the page however you need based upon the result of any server-side action.

Render your action fields as you normally would. The key to the process is in the submit button. Here's how the the Jifty::View::Declare::CRUD manpage does this, as of this writing:


      label   => 'Create',

      onclick => [

          { submit       => $create },

          { refresh_self => 1 },

          {   element =>



              append => $self->fragment_for('view'),

              args   => {

                  object_type => $object_type,

                  id => { result_of => $create, name => 'id' },





This could is embedded in a call to outs() for use with the Template::Declare manpage templating, but you could just as easily wrap the line above in <% %> for use with Mason templates. The keys is each item in the list past to onclick:

  { submit => $create },

This tells Jifty submit the form elements related to the action referenced by $create only. Any other actions in the same form will be ignored.

  { refresh_self => 1 },

This tells the browser to refresh the current region (which will be the one containing the current submit button), so that the form can be reused. You could also modify this behavior to delete the region, if you wrote:

  { delete => Jifty->web->current_region },

The most complicated part is the most important:

  {   element =>



      append => $self->fragment_for('view'),

      args   => {

          object_type => $object_type,

          id => { result_of => $create, name => 'id' },


The element parameter tells the browser where to insert the new item. By using Jifty->web->current_region->parent->get_element('div.list'), the new code will be appended to the first div tag found with a list class within the parent region. This assumes that you have added such an element to the parent region.

You could look up an arbitrary region using Jifty->web->get_region('fully-qualified-region-name') if you don't want to use the parent of the current region.

The append argument gives the path to the URL of the item to insert. By using append, you are telling Jifty to add your new code to the end of the element given in element. If you want to add it to the beginning, you can use prepend instead.

Last, but not least, you need to send arguments to the URL related to the action being performed. These can be anything you need for the your template to render the required code. In this example, two arguments are passed: object_type and id. In the case of object_type a known value is passed. In the case of id, the result of the action is passed, which is the key to the whole deal:

  id => { result_of => $create, name => 'id' },

This line tells Jifty that you want to set the ``id'' paramter sent to the URL given in append, to the ``id'' set when $create is executed. That is, after running the action, Jifty will contact the URL and effectively perform:

  set id => $create->result->content('id');

It's a lot more complicated than that in actuality, but Jifty takes care of all the nasty details.

If you want to use a custom action other than the built-in create and want to pass something back other than the ``id'', you just need to set the result into the appropriate key on the content method of the the Jifty::Result manpage.

For more details on how you can customize this further, see the Jifty::Manual::PageRegions manpage, the Jifty::Web::Form::Element manpage, the Jifty::Result manpage, the Jifty::Action manpage, the Jifty::Web::PageRegion manpage, the Jifty::Web manpage, and the Jifty::Request::Mapper manpage.