Skip to content

Latest commit

 

History

History
212 lines (152 loc) · 6.73 KB

general-params.md

File metadata and controls

212 lines (152 loc) · 6.73 KB

General builder params

go back to Table of contents

The default params for a new generator are as follows:

generator: {{ generator }}
params:
    model: {{ namespace }}\{{ model_folder }}\{{ model_name }}
    namespace_prefix: {{ namespace_prefix }}
    bundle_name: {{ bundle_name }}
    concurrency_lock: ~
    i18n_catalog: Admin
    credentials: ~
    pk_requirement: ~
    custom_blocks: ~
    fields: ~
    object_actions:
        delete: ~
    batch_actions:
        delete: ~
    actions: ~

They can be customized on a per admin basis, according to your needs.

If you want to see the actual list/excel/new/edit builder documentation, check this documentation.

Generator

generator default: admingenerator.generator.{{generator}} type: string

The generator is the most important part of the general config. It indicates the service that needs to be used for generator this particular admin page. By default, it is the generator service provided by this bundle for the model manager entered during admin creation.

Model

model default: {{ namespace }}\{{ model_folder }}\{{ model_name }} type: string

The model that this admin manages. Use the fully qualified model name.

Bundle

namespace_prefix default: {{ namespace_prefix }} type: string bundle_name default: {{ bundle_name }} type: string

The namespace_prefix and bundle_name together form the fully qualified bundle name. For example, in the case of the bundle Acme/AdminBundle, the namespace_prefix would be Acme and the bundle_name would be AdminBundle.

Concurrency lock

concurrency_lock default: false type: boolean

To protect your models edit action against concurrent modifications during long-running business transactions this parameter can be used. If enabled, before updating actually updating the object, this bundle will check if there were any modifications by comparing object versions. Simply set it to true and make sure that your model contains a version field.

Version field for Doctrine ORM/ODM

Add the version property to your model, with the correct annotation.

class Article
{
    /**
     * @ORM\Version()
     * @ORM\Column(type="integer")
     */
    private $version;

    public function getVersion()
	{
        return $this->version;
    }
}
Version field for Propel

In the schema.xml, use the <behavior> tag to add the versionable behavior to a table:

<table name="article">
    <column name="id" required="true" primaryKey="true" autoIncrement="true" type="INTEGER" />
    <column name="title" type="VARCHAR" required="true" />
    <behavior name="versionable" />
</table>

Translation domain

i18n_catalog default: Admin type: string

Provide the tranlation catalogue that needs to be used to translate the text.

Credentials

credentials default: ~ type: string

By default, there are no credentials required to view every page of this particular admin. To check for a specific credential, just enter it here. For more documentation about credentials, check our security documentation.

NOTE Credentials given here are valid for the whole admin, but can be overridden in specific builders or even specific fields.

Primary key requirement

pk_requirement default: ~ type: string

By default the generated routes are quite greedy, which can be solved by adding primary key requirements to those routes. Simply add the requirements as wanted by the normal convention. Set it for example to \d+ to only allow numeric primary key values in every generated route using a primary key.

Custom show blocks

custom_blocks default: ~ type: string

For displaying values (such as in the list view or simply the show view) by default this bundle uses the database type to find a suiting show format. Currently, the following types are supported by default (in this order):

  • custom: Custom view block as specified in the customView yaml field configuration.
  • boolean: Shows a cross (false) or check (true).
  • date: Prints the date. Will be formatted according to your field configuration.
  • datetime: Prints the date & time. Again according to your field configuration.
  • decimal: Prints the number in decimal notation
  • money: Prints the number with a currency sign
  • collection: Prints the collection
  • other: Simply prints the value as returned by the getter method.
Custom views

When you want to use a custom show block, the value of this parameter must be set to the twig file containing the block you want to use. For example:

#example for the show and list builder
params:
  custom_blocks: AcmeDemoBundle:Form:custom_blocks.html.twig
#example for just the show builder
builder:
  show:
    params:
      custom_blocks: Acme:Form:custom_blocks.html.twig

In the field configuration itself you will need to specify the block you want to use, for example:

fields:
  gender:
    customView: gender

In this example, the custom blocks template must contain the following block:

{% block column_gender %}
  {% apply spaceless %}
    {% if(field_value == 'm') %}
      <i class="glyphicon glyphicon-male"></i>
    {% elseif(field_value == 'f') %}
      <i class="glyphicon glyphicon-female"></i>
    {% else %}
      <i class="glyphicon glyphicon-unknown"></i>
    {% endif %}
  {% endapply %}
{% endblock %}

Note You will need to specify a block with column_+customView value in the given custom_blocks twig file.

Note The custom_blocks file can contain multiple blocks.

Fields

fields default: ~ type: array

The fields parameter can be used to configure the fields on a global level. The configuration entered here will be used by the builders, which can overwrite specific parts.

For more information about configuring field, see our field configuration documentation.

Actions

object_actions default: ~ type: array batch_actions default: ~ type: array actions default: ~ type: array

This bundle provides some configurable default actions, but custom actions can also be defined. There are three types of actions:

  1. Object actions: Actions which are applied to a specific object, identified by a primary key
  2. Batch actions: Actions which are applied on a selection of object.
  3. Actions: Actions applying globally (not to a specific object).

More information on actions can be found in the action configuration documentation.