GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  JIFTY::DBI::RECORD::PLUGIN (3)

.ds Aq ’

NAME

Jifty::DBI::Record::Plugin - Record model mixins for Jifty::DBI

CONTENTS

SYNOPSIS



  # Define a mixin
  package MyApp::FavoriteColor;
  use base qw/ Jifty::DBI::Record::Plugin /;

  # Define which methods you want to put in the host model
  our @EXPORT = qw(
      favorite_complementary_color
  );

  use Jifty::DBI::Schema;
  use Jifty::DBI::Record schema {
      column favorite_color =>
          type is text,
          label is Favorite Color,
          valid_values are qw/ red green blue yellow /;
  };

  sub favorite_complementary_color {
      my $self = shift; # whatever host object thing weve mixed with
      my $color = $self->favorite_color;
      return $color eq red    ? green
           : $color eq green  ? red
           : $color eq blue   ? orange
           : $color eq yellow ? purple
           :                      undef;
  }

  # Use the mixin
  package MyApp::Model::User;

  use Jifty::DBI::Schema;
  use Jifty::DBI::Record schema {
      column name =>
          type is text,
          label is Name;
  };

  # Mixins
  use MyApp::FavoriteColor;

  sub name_and_color {
      my $self  = shift;
      my $name  = $self->name;
      my $color = $self->favorite_color;

      return "The favorite color of $name is $color.";
  }

  sub name_and_complementary_color {
      my $self  = shift;
      my $name  = $self->name;
      my $color = $self->favorite_complementary_color;

      return "The complement of $names favorite color is $color.";
  }



DESCRIPTION

By using this package you may provide models that are built from one or more mixins. In fact, your whole table could be defined in the mixins without a single column declared within the model class itself.

    MODEL MIXINS

To build a mixin, just create a model that inherits from this package, Jifty::DBI::Record::Plugin. Then, add the schema definitions you want inherited.



  package MyApp::FasterSwallow;
  use base qw/ Jifty::DBI::Record::Plugin /;
 
  use Jifty::DBI::Schema;
  use Jifty::DBI::Record schema {
      column swallow_type =>
          type is text,
          valid are qw/ african european /,
          default is african;
  };



@EXPORT

A mixin may define an @EXPORT variable, which works exactly as advertised in Exporter. That is, given the name of any methods or variable names in the mixin, the host model will gain those methods.



  our @EXPORT = qw( autocomplete_swallow_type );

  sub autocomplete_swallow_type {
      my $self  = shift;
      my $value = quotemeta(shift);

      # You should probably find a better way than actually doing this...

      my @values;
      push @values, african  if african  =~ /$value/;
      push @values, european if european =~ /$value/;

      return @values;
  }



That way if you have any custom methods you want to throw into the host model, just define them in the mixin and add them to the @EXPORT variable.

register_triggers

Your mixin may also want to register triggers for the records to which it will be added. You can do this by defining a method named register_triggers:



  sub register_triggers {
      my $self = shift;
      $self->add_trigger(
          name      => before_create,
          callback  => \&before_create,
          abortable => 1,
      );
  }

  sub before_create {
      # do something...
  }



See Class::Trigger.

register_triggers_for_column

In addition to the general register_triggers method described above, the mixin may also implement a register_triggers_for_column method. This is called for each column in the table. This is primarily helpful for registering the after_set_* and before_set_* columns.

For example:



  sub register_triggers_for_column {
      my $self   = shift;
      my $column = shift;

      return unless $column ne updated_on;

      $self->add_trigger(
          name      => after_set_.$column,
          callback  => \&touch_update_time,
          abortable => 1,
      );
  }

  sub touch_update_time {
      my $self = shift;
      $self->set_updated_on(DateTime->now);
  }



This has the additional advantage of being callable when new columns are added to a table while the application is running. This can happen when using database-backed models in Jifty (which, as of this writing, has not been released or made part of the development trunk of Jifty, but is part of the virtual-models branch).

See Class::Trigger.

    MODELS USING MIXINS

To use your model plugin, just use the mixins you want to get columns from. You should still include a schema definition, even if it’s empty:



  package MyApp::Model::User;

  use Jifty::DBI::Schema;
  use MyApp::Record schema {
  };

  # Mixins
  use MyApp::FavoriteColor;
  use MyApp::FasterSwallow;
  use Jifty::Plugin::User::Mixin::Model::User;
  use Jifty::Plugin::Authentication::Password::Mixin::Model::User;



SEE ALSO

Jifty::DBI::Record, Class::Trigger

LICENSE

Jifty::DBI is Copyright 2005-2007 Best Practical Solutions, LLC. Jifty is distributed under the same terms as Perl itself.
Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 JIFTY::DBI::RECORD::PLUGIN (3) 2014-05-29

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.