filter_die

schema

    use Jifty::DBI::Record schema { ... };

If your application subclasses "::Record", then write this instead:

    use MyApp::Record schema { ... };

column

merge_params HASHREF HASHREF

    - Empty fields in subclasses don't override nonempty fields in superclass anymore.
    - Arrays don't merge; e.g. if parent class's valid_values is [1,2,3,4], and
      subclass's valid_values() is [1,2], they don't somehow become [1,2,3,4,1,2].

BUG: This should either be a private routine or factored out into Jifty::Util

register_types

references

referencing a record

Correct usage is "references Application::Model::OtherClass by 'column_name'", where Application::Model::OtherClass is a valid Jifty model, subclass of Jifty::Record, and 'column_name' is a distinct column of OtherClass. You can omit "by 'column_name'" and the column name 'id' will be used.

At this moment you must specify type of the column your self to match type of the column you refer to.

You can name a column as combination of 'name' and 'by', for example:

    column user_name => references App::Model::User by 'name', type is 'varchar(64)';

Then user, user_name and respective setters will be generated. user method will return object, user_name will return actual value. Note that if you're using some magic on load for user records then to get real name of loaded record you should use "$record->user->name" instead.

In the above case name of the column in the DB will be 'user_name'. If you don't like suffixes like '_id', '_name' and other in the DB then you can name column without suffix, for example:

    column user => references App::Model::User by 'name', type is 'varchar(64)';

In this case name of the column in the DB will be 'user', accessors will be the same as in above example.

referencing a collection

Correct usage is "references Application::Model::OtherCollection by 'column_name'", where Application::Model::OtherCollection is a valid Jifty model, subclass of Jifty::Collection, and 'column_name' is a column of records in OtherCollection. In this case "by 'column_name'" is not optional.

Columns that refers to a collection are virtual and can be changed. So such columns in a model doesn't create real columns in the DB, but instead it's way to name collection of records that refer to this records.

example

Simple model with users and multiple phone records per user:

    package TestApp::Model::User;
    use Jifty::DBI::Schema;
    use Jifty::DBI::Record schema {
        column name  => type is 'varchar(18)';
        ...
        column phones => references TestApp::Model::PhoneCollection by 'user';
    };

    package TestApp::Model::Phone;
    use Jifty::DBI::Schema;
    use Jifty::DBI::Record schema {
        column user  => references TestApp::Model::User by 'id',
            is mandatory;
        column type  => ...;
        column value => ...;
    };

From a user record you get his phones and do something:

    my $phones = $user->phones;
    while ( my $phone = $phones->next ) {
        ...
    }

From a phone record you can get its owner or change it:

    my $user_object = $phone->user;
    my $user_id = $phone->user_id;

    $phone->set_user( $new_owner_object );
    $phone->set_user( 123 );    # using id
    $phone->set_user_id( 123 ); # the same, but only using id

refers_to

by

type

Currently type is passed directly to the database. There is no intermediary mapping from abstract type names to database specific types.

The impact of this is that not all column types are portable between databases. For example blobs have different names between mysql and postgres.

default

literal

validator

immutable

unreadable

max_length

mandatory

not_null

autocompleted

distinct

virtual

computed

sort_order

order

input_filters

output_filters

filters

since

till

Correct usage is "till '0.2.5'". This indicates that the column is not available in version 0.2.5, but was available in 0.2.4. The value specified for "since" must be less than this version.

valid_values

If you want to display different values than are stored in the DB you can pass a list of hashrefs, each containing two keys, display and value.

 valid_values are
  { display => 'Blue', value => 'blue' },
  { display => 'Red', value => 'red' }

valid

label

hints

display_length

render_as

The values for this attribute are the same as the names of the modules under Jifty::Web::Form::Field, i.e.

• Button
• Checkbox
• Combobox
• Date
• Hidden
• InlineButton
• Password
• Radio
• Select
• Textarea
• Upload
• Unrendered

You may also use the same names with the initial character in lowercase.

The "Unrendered" may seem counter-intuitive, but is there to allow for internal fields that should not actually be displayed.

If these don't meet your needs, you can write your own subclass of Jifty::Web::Form::Field. See the documentation for that module.

render

indexed