Contao Community Documentation - Benutzerbeiträge [de]

MetaPalettes

2018-01-08T12:31:36Z

Netzmacht: Fix Pipe Problem

Mit der Erweiterung MetaPalettes lassen sich die DCA Paletten in einem Array, statt einem String definieren. Dadurch wird es einfacher die Paletten später zu verändern.
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=Contao Community Alliance
| ExtVersion=2.0.0
| Version=4.4+ (Version 1.11 ist sowohl mit Contao >= 3.5 und Contao 4.4 kompatibel)
| ERLink=http://www.contao.org/erweiterungsliste/view/metapalettes.de.html
}}

MetaPalettes generiert aus einem Mehrdimensionalen-Array das im DCA festgelegt wird die Haupt- und Unterpaletten.

=Anwendungsbeispiel=

Beispiel für eine MetaPalette aus der Erweiterung [[htaccess]]:
<source lang="php">
/**
* DCA tl_htaccess
*/
$GLOBALS['TL_DCA']['tl_htaccess'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'default' => array
(
'htaccess_settings' => array(':hide', 'htaccess_load_settings'),
'htaccess_base' => array('htaccess_template'),
'htaccess_etag' => array('htaccess_etag_disable'),
'htaccess_mime' => array('htaccess_mime_types'),
'htaccess_deflate' => array('htaccess_deflate_files'),
'htaccess_headers' => array(),
'htaccess_expires' => array('htaccess_expires_default', 'htaccess_expires'),
'htaccess_custom' => array('htaccess_custom'),
'htaccess_rewrite' => array('htaccess_rewrite_rules', 'htaccess_rewrite_prepend_www', 'htaccess_rewrite_remove_www', 'htaccess_rewrite_gzip', 'htaccess_rewrite_suffix'),
'htaccess_h5bp' => array('htaccess_h5bp_ie_x_ua_compatible', 'htaccess_h5bp_cross_domain_ajax', 'htaccess_h5bp_concatenation_include', 'htaccess_h5bp_ie_flicker_fix')
)
),
...
);
</source>

Anstelle einer <code>palette</code> wird ein Feld <code>metapalette</code> definiert. Die Schlüssel für das Array definieren wie gewohnt die Palette, jedoch werden die einzelnen Abschnitte mit den Feldern nicht als Zeichenkette, sondern als Array definiert. Der Schlüssel aus dem Meta Array beschreibt den Abschnitt, darunter kommt wiederum als Array die Felder.

=Paletten definieren=

Am besten zeigt sich der Zusammenhang an einem kleinen Beispiel:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
)
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three'
)
...
);
</source>

Der Array Key definieren jeweils die Legende für den Abschnitt, das '''_legend''' wird dabei automatisch hinzugefügt.

==:hide und andere Modifikatoren==

Eine Palette kann versteckt angezeigt werden, wie oben chapter_two: <code>{chapter_two_legend:hide}</code>.
Dazu muss einfach das Schlüsselwort <code>:hide</code> in das Felder-Array hinzugefügt werden.
MetaPalettes betrachtet alle mit ''':''' beginnenden Felder als Modifikatoren, diese werden aus der Feldliste extrahiert.
Zur Zeit wird aber nur das Schlüsselwort <code>:hide</code> unterstützt.

=Subpaletten definieren=

Auch Subpaletten lassen sich definieren:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubpalettes' => array
(
'field_three' => array('field_four', 'field_five')
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'__selector__' => array('field_three'),
...
),

'subpalettes' => array
(
'field_three' => 'field_four,field_five'
)
...
);
</source>

Das <code>__selector__</code> Array wird automatisch gefüllt, es ist also nicht mehr notwendig dieses Array von Hand zu befüllen.

=SubSelectpaletten definieren=
(seit Version 1.2.0)

Normalerweise verwendet Contao <code>select</code> Felder, die als Selectoren markiert sind dazu eine Palette auszuwählen. Das ist allerdings nicht immer sinnvoll, weil man dann viele Paletten definieren muss, die oft stark redundant sind. Mit SubSelectpaletten ist es möglich, ähnlich den Subpaletten einer Checkbox ''Untermengen'' von Feldern den einzelnen Select Werten zuzuordnen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'example' => array('subselect_field')
)
),
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
),
...
'fields' => array
(
'subselect_field' => array
(
'label' => array('SubSelect Example', 'Switch field and see how the subfields changing'),
'inputType' => 'select',
'options' => array('value1', 'value2', 'value3'),
'eval' => array('submitOnChange'=>true)
)
)
);
</source>

Um die Definition einfacher zu gestalten, kann man mit einem '''!''' (Ausrufezeichen) vor dem Wert auch Negativ-Paletten definieren. Diese werden immer dann angezeigt, wenn ein Wert nicht ausgewählt ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'!value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
)
...
);
</source>
Das Feld '''value2_subfield1''' wird immer dann angezeigt, wenn '''value1''' oder '''value3''' ausgewählt sind.

=Paletten ergänzen=

Ab Version 1.1 kann man vorhandene Paletten ganz einfach ergänzen. Dazu stehen 3 '''statische''' Methoden zur Verfügung. Ab Version 1.11 ist die Klasse unter dem Namespace "ContaoCommunityAlliance\MetaPalettes\MetaPalettes" zu finden, der auch in Version 2.0 verwendet wird. Die alten Namespaces "MetaPalettes" und "Bit3\MetaPalettes\MetaPalettes" stehen in Version 2 nicht mehr zur Verfügung!
{{Hinweis|Um möglichst mit anderen Erweiterungen kompatibel zu sein, empfiehlt es sich sowohl Version 2 und 1 zu unterstützen. Mit der Versionsanforderung "^2.0 || ^1.11" ist dies möglich. Selbstredend sollten dann nur Features verwendet werden, die in beiden Versionen funktionieren.}}

==MetaPalettes::appendTo(..)==

Fügt eine Meta Palette am Ende hinzu.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendTo('tl_settings', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendTo('tl_content', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''text''' Palette von '''tl_content''' hinzu.

==MetaPalettes::appendBefore(..) & MetaPalettes::appendAfter(..)==

Fügt eine Meta Palette vor oder nach einem Block ein.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendBefore('tl_settings', 'title', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''title_legend''' der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 3. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendBefore('tl_content', 'published', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''published_legend''' der '''text''' Palette von '''tl_content''' hinzu.

Die Methode <code>MetaPalettes::appendAfter(..)</code> verhält sich äquivalent zu <code>MetaPalettes::appendBefore(..)</code>, nur dass der Block nicht vor, sondern nach dem anderen Block eingefügt wird.
{{Hinweis|Sollte der Block vor oder nach dem eingefügt werden soll nicht gefunden werden, wird die Palette am Ende hinzugefügt (wie bei <code>MetaPalettes::appendTo(..)</code>)}}

==MetaPalettes::appendFields(..) & MetaPalettes::prependFields(..)==
(seit Version 1.2.0)

Fügt eine Felder am Anfang oder Ende eines Blocks hinzu.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendFields('tl_settings', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''default''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::prependFields('tl_content', 'text', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''text''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' am Anfang hinzu.

=Paletten vererben=
(seit Version 1.3.0)

Paletten lassen sich mit einfachen regeln vererben, die ererbten Regeln

<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three' => array('field_four', 'field_five')
)
),
...
);
</source>
{{Hinweis|Die ''_X_'' Notation mit den Unterstrichen ist '''nicht''' obligatorisch. Sie soll nur zeigen, dass diese Palette niemals direkt verwendet wird sondern nur als Basis für eine andere Palette dient!}}

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'_base_' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three',
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three;{chapter_three_legend},field_four,field_five'
)
...
);
</source>

Um eine Palette zu erben wird also die einfache Notation '''''<palette>'' extends ''<base>''''' verwendet.

==fein granulare Vererbung==

===Gruppe überschreiben===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' enthält später das Feld ''field_four''.

===Löschen von Gruppen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array()
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' wird gelöscht (leer gesetzt und damit nicht angezeigt).

===Gruppe positionieren===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three before chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_three'' wird vor der Gruppe ''chapter_two'' eingefügt. Mit dem ''after'' Schlüsselwort wird die Gruppe nach einer anderen Gruppe eingefügt.

===Einzelne Felder hinzufügen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_two' => array('field_four')
)
),
...
);
</source>
→ der Gruppe ''chapter_two'' wird das Feld ''field_four'' am Ende hinzugefügt.

===Einzelne Felder entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_two' => array('field_three')
)
),
...
);
</source>
→ aus der Gruppe ''chapter_two'' wird das Feld ''field_three'' entfernt.

===Felder an bestimmter Position hinzufügen und entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_one' => array('field_four before field_one', '-field_two')
)
),
...
);
</source>
→ fügt der Gruppe ''chapter_two'' das Feld ''field_four'' vor dem Feld ''field_one'' hinzu und entfernt das Feld ''field_two''. Mit ''after'' kann ein Feld auch nach einem anderen hinzugefügt werden.

Der Operator (+/-) im Palettennamen definiert die Operation für alle Felder ohne eigenem Operator. Die Operatoren können also auch umgekehrt werden.
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_one' => array('+field_four before field_one', 'field_two')
)
),
...
);
</source>
Hat die gleiche Bedeutung wie im vorherigen Beispiel.
{{Hinweis|Wenn einzelne Felder hinzugefügt oder entfernt werden sollen, dann ist ein Operator (+/-) im Palettenname zwingend erforderlich, weil MetaPalettes sonst annimmt das die Palette überschrieben und nicht verändert werden soll!}}

MetaPalettes

2018-01-08T12:25:33Z

Netzmacht: Wiki-Syntax

MetaPalettes

2018-01-08T12:24:18Z

Netzmacht: Hinweis zur Versionskompatibilität

Mit der Erweiterung MetaPalettes lassen sich die DCA Paletten in einem Array, statt einem String definieren. Dadurch wird es einfacher die Paletten später zu verändern.
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=Contao Community Alliance
| ExtVersion=2.0.0
| Version=4.4+ (Version 1.11 ist sowohl mit Contao >= 3.5 und Contao 4.4 kompatibel)
| ERLink=http://www.contao.org/erweiterungsliste/view/metapalettes.de.html
}}

MetaPalettes generiert aus einem Mehrdimensionalen-Array das im DCA festgelegt wird die Haupt- und Unterpaletten.

=Anwendungsbeispiel=

Beispiel für eine MetaPalette aus der Erweiterung [[htaccess]]:
<source lang="php">
/**
* DCA tl_htaccess
*/
$GLOBALS['TL_DCA']['tl_htaccess'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'default' => array
(
'htaccess_settings' => array(':hide', 'htaccess_load_settings'),
'htaccess_base' => array('htaccess_template'),
'htaccess_etag' => array('htaccess_etag_disable'),
'htaccess_mime' => array('htaccess_mime_types'),
'htaccess_deflate' => array('htaccess_deflate_files'),
'htaccess_headers' => array(),
'htaccess_expires' => array('htaccess_expires_default', 'htaccess_expires'),
'htaccess_custom' => array('htaccess_custom'),
'htaccess_rewrite' => array('htaccess_rewrite_rules', 'htaccess_rewrite_prepend_www', 'htaccess_rewrite_remove_www', 'htaccess_rewrite_gzip', 'htaccess_rewrite_suffix'),
'htaccess_h5bp' => array('htaccess_h5bp_ie_x_ua_compatible', 'htaccess_h5bp_cross_domain_ajax', 'htaccess_h5bp_concatenation_include', 'htaccess_h5bp_ie_flicker_fix')
)
),
...
);
</source>

Anstelle einer <code>palette</code> wird ein Feld <code>metapalette</code> definiert. Die Schlüssel für das Array definieren wie gewohnt die Palette, jedoch werden die einzelnen Abschnitte mit den Feldern nicht als Zeichenkette, sondern als Array definiert. Der Schlüssel aus dem Meta Array beschreibt den Abschnitt, darunter kommt wiederum als Array die Felder.

=Paletten definieren=

Am besten zeigt sich der Zusammenhang an einem kleinen Beispiel:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
)
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three'
)
...
);
</source>

Der Array Key definieren jeweils die Legende für den Abschnitt, das '''_legend''' wird dabei automatisch hinzugefügt.

==:hide und andere Modifikatoren==

Eine Palette kann versteckt angezeigt werden, wie oben chapter_two: <code>{chapter_two_legend:hide}</code>.
Dazu muss einfach das Schlüsselwort <code>:hide</code> in das Felder-Array hinzugefügt werden.
MetaPalettes betrachtet alle mit ''':''' beginnenden Felder als Modifikatoren, diese werden aus der Feldliste extrahiert.
Zur Zeit wird aber nur das Schlüsselwort <code>:hide</code> unterstützt.

=Subpaletten definieren=

Auch Subpaletten lassen sich definieren:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubpalettes' => array
(
'field_three' => array('field_four', 'field_five')
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'__selector__' => array('field_three'),
...
),

'subpalettes' => array
(
'field_three' => 'field_four,field_five'
)
...
);
</source>

Das <code>__selector__</code> Array wird automatisch gefüllt, es ist also nicht mehr notwendig dieses Array von Hand zu befüllen.

=SubSelectpaletten definieren=
(seit Version 1.2.0)

Normalerweise verwendet Contao <code>select</code> Felder, die als Selectoren markiert sind dazu eine Palette auszuwählen. Das ist allerdings nicht immer sinnvoll, weil man dann viele Paletten definieren muss, die oft stark redundant sind. Mit SubSelectpaletten ist es möglich, ähnlich den Subpaletten einer Checkbox ''Untermengen'' von Feldern den einzelnen Select Werten zuzuordnen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'example' => array('subselect_field')
)
),
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
),
...
'fields' => array
(
'subselect_field' => array
(
'label' => array('SubSelect Example', 'Switch field and see how the subfields changing'),
'inputType' => 'select',
'options' => array('value1', 'value2', 'value3'),
'eval' => array('submitOnChange'=>true)
)
)
);
</source>

Um die Definition einfacher zu gestalten, kann man mit einem '''!''' (Ausrufezeichen) vor dem Wert auch Negativ-Paletten definieren. Diese werden immer dann angezeigt, wenn ein Wert nicht ausgewählt ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'!value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
)
...
);
</source>
Das Feld '''value2_subfield1''' wird immer dann angezeigt, wenn '''value1''' oder '''value3''' ausgewählt sind.

=Paletten ergänzen=

Ab Version 1.1 kann man vorhandene Paletten ganz einfach ergänzen. Dazu stehen 3 '''statische''' Methoden zur Verfügung. Ab Version 1.11 ist die Klasse unter dem Namespace "ContaoCommunityAlliance\MetaPalettes\MetaPalettes" zu finden, der auch in Version 2.0 verwendet wird. Die alten Namespaces "MetaPalettes" und "Bit3\MetaPalettes\MetaPalettes" stehen in Version 2 nicht mehr zur Verfügung!

{Hinweis|Um möglichst mit anderen Erweiterungen kompatibel zu sein, empfiehlt es sich sowohl Version 2 und 1 zu unterstützen. Mit der Versionsanforderung "^2.0 || ^1.11" ist dies möglich. Selbstredend sollten dann nur Features verwendet werden, die in beiden Versionen funktionieren. }

==MetaPalettes::appendTo(..)==

Fügt eine Meta Palette am Ende hinzu.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendTo('tl_settings', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendTo('tl_content', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''text''' Palette von '''tl_content''' hinzu.

==MetaPalettes::appendBefore(..) & MetaPalettes::appendAfter(..)==

Fügt eine Meta Palette vor oder nach einem Block ein.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendBefore('tl_settings', 'title', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''title_legend''' der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 3. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendBefore('tl_content', 'published', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''published_legend''' der '''text''' Palette von '''tl_content''' hinzu.

Die Methode <code>MetaPalettes::appendAfter(..)</code> verhält sich äquivalent zu <code>MetaPalettes::appendBefore(..)</code>, nur dass der Block nicht vor, sondern nach dem anderen Block eingefügt wird.
{{Hinweis|Sollte der Block vor oder nach dem eingefügt werden soll nicht gefunden werden, wird die Palette am Ende hinzugefügt (wie bei <code>MetaPalettes::appendTo(..)</code>)}}

==MetaPalettes::appendFields(..) & MetaPalettes::prependFields(..)==
(seit Version 1.2.0)

Fügt eine Felder am Anfang oder Ende eines Blocks hinzu.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendFields('tl_settings', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''default''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::prependFields('tl_content', 'text', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''text''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' am Anfang hinzu.

=Paletten vererben=
(seit Version 1.3.0)

Paletten lassen sich mit einfachen regeln vererben, die ererbten Regeln

<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three' => array('field_four', 'field_five')
)
),
...
);
</source>
{{Hinweis|Die ''_X_'' Notation mit den Unterstrichen ist '''nicht''' obligatorisch. Sie soll nur zeigen, dass diese Palette niemals direkt verwendet wird sondern nur als Basis für eine andere Palette dient!}}

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'_base_' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three',
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three;{chapter_three_legend},field_four,field_five'
)
...
);
</source>

Um eine Palette zu erben wird also die einfache Notation '''''<palette>'' extends ''<base>''''' verwendet.

==fein granulare Vererbung==

===Gruppe überschreiben===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' enthält später das Feld ''field_four''.

===Löschen von Gruppen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array()
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' wird gelöscht (leer gesetzt und damit nicht angezeigt).

===Gruppe positionieren===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three before chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_three'' wird vor der Gruppe ''chapter_two'' eingefügt. Mit dem ''after'' Schlüsselwort wird die Gruppe nach einer anderen Gruppe eingefügt.

===Einzelne Felder hinzufügen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_two' => array('field_four')
)
),
...
);
</source>
→ der Gruppe ''chapter_two'' wird das Feld ''field_four'' am Ende hinzugefügt.

===Einzelne Felder entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_two' => array('field_three')
)
),
...
);
</source>
→ aus der Gruppe ''chapter_two'' wird das Feld ''field_three'' entfernt.

===Felder an bestimmter Position hinzufügen und entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_one' => array('field_four before field_one', '-field_two')
)
),
...
);
</source>
→ fügt der Gruppe ''chapter_two'' das Feld ''field_four'' vor dem Feld ''field_one'' hinzu und entfernt das Feld ''field_two''. Mit ''after'' kann ein Feld auch nach einem anderen hinzugefügt werden.

Der Operator (+/-) im Palettennamen definiert die Operation für alle Felder ohne eigenem Operator. Die Operatoren können also auch umgekehrt werden.
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_one' => array('+field_four before field_one', 'field_two')
)
),
...
);
</source>
Hat die gleiche Bedeutung wie im vorherigen Beispiel.
{{Hinweis|Wenn einzelne Felder hinzugefügt oder entfernt werden sollen, dann ist ein Operator (+/-) im Palettenname zwingend erforderlich, weil MetaPalettes sonst annimmt das die Palette überschrieben und nicht verändert werden soll!}}

MetaPalettes

2018-01-08T12:21:27Z

Netzmacht: Informationen zu Namespace zwischen Version 1 und 2 hinzugefügt.

Mit der Erweiterung MetaPalettes lassen sich die DCA Paletten in einem Array, statt einem String definieren. Dadurch wird es einfacher die Paletten später zu verändern.
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=Contao Community Alliance
| ExtVersion=2.0.0
| Version=4.4+ (Version 1.11 ist sowohl mit Contao >= 3.5 und Contao 4.4 kompatibel)
| ERLink=http://www.contao.org/erweiterungsliste/view/metapalettes.de.html
}}

MetaPalettes generiert aus einem Mehrdimensionalen-Array das im DCA festgelegt wird die Haupt- und Unterpaletten.

=Anwendungsbeispiel=

Beispiel für eine MetaPalette aus der Erweiterung [[htaccess]]:
<source lang="php">
/**
* DCA tl_htaccess
*/
$GLOBALS['TL_DCA']['tl_htaccess'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'default' => array
(
'htaccess_settings' => array(':hide', 'htaccess_load_settings'),
'htaccess_base' => array('htaccess_template'),
'htaccess_etag' => array('htaccess_etag_disable'),
'htaccess_mime' => array('htaccess_mime_types'),
'htaccess_deflate' => array('htaccess_deflate_files'),
'htaccess_headers' => array(),
'htaccess_expires' => array('htaccess_expires_default', 'htaccess_expires'),
'htaccess_custom' => array('htaccess_custom'),
'htaccess_rewrite' => array('htaccess_rewrite_rules', 'htaccess_rewrite_prepend_www', 'htaccess_rewrite_remove_www', 'htaccess_rewrite_gzip', 'htaccess_rewrite_suffix'),
'htaccess_h5bp' => array('htaccess_h5bp_ie_x_ua_compatible', 'htaccess_h5bp_cross_domain_ajax', 'htaccess_h5bp_concatenation_include', 'htaccess_h5bp_ie_flicker_fix')
)
),
...
);
</source>

Anstelle einer <code>palette</code> wird ein Feld <code>metapalette</code> definiert. Die Schlüssel für das Array definieren wie gewohnt die Palette, jedoch werden die einzelnen Abschnitte mit den Feldern nicht als Zeichenkette, sondern als Array definiert. Der Schlüssel aus dem Meta Array beschreibt den Abschnitt, darunter kommt wiederum als Array die Felder.

=Paletten definieren=

Am besten zeigt sich der Zusammenhang an einem kleinen Beispiel:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
)
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three'
)
...
);
</source>

Der Array Key definieren jeweils die Legende für den Abschnitt, das '''_legend''' wird dabei automatisch hinzugefügt.

==:hide und andere Modifikatoren==

Eine Palette kann versteckt angezeigt werden, wie oben chapter_two: <code>{chapter_two_legend:hide}</code>.
Dazu muss einfach das Schlüsselwort <code>:hide</code> in das Felder-Array hinzugefügt werden.
MetaPalettes betrachtet alle mit ''':''' beginnenden Felder als Modifikatoren, diese werden aus der Feldliste extrahiert.
Zur Zeit wird aber nur das Schlüsselwort <code>:hide</code> unterstützt.

=Subpaletten definieren=

Auch Subpaletten lassen sich definieren:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubpalettes' => array
(
'field_three' => array('field_four', 'field_five')
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'__selector__' => array('field_three'),
...
),

'subpalettes' => array
(
'field_three' => 'field_four,field_five'
)
...
);
</source>

Das <code>__selector__</code> Array wird automatisch gefüllt, es ist also nicht mehr notwendig dieses Array von Hand zu befüllen.

=SubSelectpaletten definieren=
(seit Version 1.2.0)

Normalerweise verwendet Contao <code>select</code> Felder, die als Selectoren markiert sind dazu eine Palette auszuwählen. Das ist allerdings nicht immer sinnvoll, weil man dann viele Paletten definieren muss, die oft stark redundant sind. Mit SubSelectpaletten ist es möglich, ähnlich den Subpaletten einer Checkbox ''Untermengen'' von Feldern den einzelnen Select Werten zuzuordnen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'example' => array('subselect_field')
)
),
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
),
...
'fields' => array
(
'subselect_field' => array
(
'label' => array('SubSelect Example', 'Switch field and see how the subfields changing'),
'inputType' => 'select',
'options' => array('value1', 'value2', 'value3'),
'eval' => array('submitOnChange'=>true)
)
)
);
</source>

Um die Definition einfacher zu gestalten, kann man mit einem '''!''' (Ausrufezeichen) vor dem Wert auch Negativ-Paletten definieren. Diese werden immer dann angezeigt, wenn ein Wert nicht ausgewählt ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'!value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
)
...
);
</source>
Das Feld '''value2_subfield1''' wird immer dann angezeigt, wenn '''value1''' oder '''value3''' ausgewählt sind.

=Paletten ergänzen=

Ab Version 1.1 kann man vorhandene Paletten ganz einfach ergänzen. Dazu stehen 3 '''statische''' Methoden zur Verfügung. Ab Version 1.11 ist die Klasse unter dem Namespace "ContaoCommunityAlliance\MetaPalettes\MetaPalettes" zu finden, der auch in Version 2.0 verwendet wird. Die alten Namespaces "MetaPalettes" und "Bit3\MetaPalettes\MetaPalettes" stehen in Version 2 nicht mehr zur Verfügung!

==MetaPalettes::appendTo(..)==

Fügt eine Meta Palette am Ende hinzu.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendTo('tl_settings', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendTo('tl_content', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''text''' Palette von '''tl_content''' hinzu.

==MetaPalettes::appendBefore(..) & MetaPalettes::appendAfter(..)==

Fügt eine Meta Palette vor oder nach einem Block ein.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendBefore('tl_settings', 'title', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''title_legend''' der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 3. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendBefore('tl_content', 'published', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''published_legend''' der '''text''' Palette von '''tl_content''' hinzu.

Die Methode <code>MetaPalettes::appendAfter(..)</code> verhält sich äquivalent zu <code>MetaPalettes::appendBefore(..)</code>, nur dass der Block nicht vor, sondern nach dem anderen Block eingefügt wird.
{{Hinweis|Sollte der Block vor oder nach dem eingefügt werden soll nicht gefunden werden, wird die Palette am Ende hinzugefügt (wie bei <code>MetaPalettes::appendTo(..)</code>)}}

==MetaPalettes::appendFields(..) & MetaPalettes::prependFields(..)==
(seit Version 1.2.0)

Fügt eine Felder am Anfang oder Ende eines Blocks hinzu.

<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::appendFields('tl_settings', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''default''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
\ContaoCommunityAlliance\MetaPalettes\MetaPalettes::prependFields('tl_content', 'text', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''text''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' am Anfang hinzu.

=Paletten vererben=
(seit Version 1.3.0)

Paletten lassen sich mit einfachen regeln vererben, die ererbten Regeln

<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three' => array('field_four', 'field_five')
)
),
...
);
</source>
{{Hinweis|Die ''_X_'' Notation mit den Unterstrichen ist '''nicht''' obligatorisch. Sie soll nur zeigen, dass diese Palette niemals direkt verwendet wird sondern nur als Basis für eine andere Palette dient!}}

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'_base_' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three',
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three;{chapter_three_legend},field_four,field_five'
)
...
);
</source>

Um eine Palette zu erben wird also die einfache Notation '''''<palette>'' extends ''<base>''''' verwendet.

==fein granulare Vererbung==

===Gruppe überschreiben===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' enthält später das Feld ''field_four''.

===Löschen von Gruppen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array()
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' wird gelöscht (leer gesetzt und damit nicht angezeigt).

===Gruppe positionieren===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three before chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_three'' wird vor der Gruppe ''chapter_two'' eingefügt. Mit dem ''after'' Schlüsselwort wird die Gruppe nach einer anderen Gruppe eingefügt.

===Einzelne Felder hinzufügen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_two' => array('field_four')
)
),
...
);
</source>
→ der Gruppe ''chapter_two'' wird das Feld ''field_four'' am Ende hinzugefügt.

===Einzelne Felder entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_two' => array('field_three')
)
),
...
);
</source>
→ aus der Gruppe ''chapter_two'' wird das Feld ''field_three'' entfernt.

===Felder an bestimmter Position hinzufügen und entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_one' => array('field_four before field_one', '-field_two')
)
),
...
);
</source>
→ fügt der Gruppe ''chapter_two'' das Feld ''field_four'' vor dem Feld ''field_one'' hinzu und entfernt das Feld ''field_two''. Mit ''after'' kann ein Feld auch nach einem anderen hinzugefügt werden.

Der Operator (+/-) im Palettennamen definiert die Operation für alle Felder ohne eigenem Operator. Die Operatoren können also auch umgekehrt werden.
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_one' => array('+field_four before field_one', 'field_two')
)
),
...
);
</source>
Hat die gleiche Bedeutung wie im vorherigen Beispiel.
{{Hinweis|Wenn einzelne Felder hinzugefügt oder entfernt werden sollen, dann ist ein Operator (+/-) im Palettenname zwingend erforderlich, weil MetaPalettes sonst annimmt das die Palette überschrieben und nicht verändert werden soll!}}

MetaPalettes

2018-01-08T12:17:36Z

Netzmacht: Entwicklerinformationen aktualisiert

Mit der Erweiterung MetaPalettes lassen sich die DCA Paletten in einem Array, statt einem String definieren. Dadurch wird es einfacher die Paletten später zu verändern.
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=Contao Community Alliance
| ExtVersion=2.0.0
| Version=4.4+ (Version 1.11 ist sowohl mit Contao >= 3.5 und Contao 4.4 kompatibel)
| ERLink=http://www.contao.org/erweiterungsliste/view/metapalettes.de.html
}}

MetaPalettes generiert aus einem Mehrdimensionalen-Array das im DCA festgelegt wird die Haupt- und Unterpaletten.

=Anwendungsbeispiel=

Beispiel für eine MetaPalette aus der Erweiterung [[htaccess]]:
<source lang="php">
/**
* DCA tl_htaccess
*/
$GLOBALS['TL_DCA']['tl_htaccess'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'default' => array
(
'htaccess_settings' => array(':hide', 'htaccess_load_settings'),
'htaccess_base' => array('htaccess_template'),
'htaccess_etag' => array('htaccess_etag_disable'),
'htaccess_mime' => array('htaccess_mime_types'),
'htaccess_deflate' => array('htaccess_deflate_files'),
'htaccess_headers' => array(),
'htaccess_expires' => array('htaccess_expires_default', 'htaccess_expires'),
'htaccess_custom' => array('htaccess_custom'),
'htaccess_rewrite' => array('htaccess_rewrite_rules', 'htaccess_rewrite_prepend_www', 'htaccess_rewrite_remove_www', 'htaccess_rewrite_gzip', 'htaccess_rewrite_suffix'),
'htaccess_h5bp' => array('htaccess_h5bp_ie_x_ua_compatible', 'htaccess_h5bp_cross_domain_ajax', 'htaccess_h5bp_concatenation_include', 'htaccess_h5bp_ie_flicker_fix')
)
),
...
);
</source>

Anstelle einer <code>palette</code> wird ein Feld <code>metapalette</code> definiert. Die Schlüssel für das Array definieren wie gewohnt die Palette, jedoch werden die einzelnen Abschnitte mit den Feldern nicht als Zeichenkette, sondern als Array definiert. Der Schlüssel aus dem Meta Array beschreibt den Abschnitt, darunter kommt wiederum als Array die Felder.

=Paletten definieren=

Am besten zeigt sich der Zusammenhang an einem kleinen Beispiel:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
)
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three'
)
...
);
</source>

Der Array Key definieren jeweils die Legende für den Abschnitt, das '''_legend''' wird dabei automatisch hinzugefügt.

==:hide und andere Modifikatoren==

Eine Palette kann versteckt angezeigt werden, wie oben chapter_two: <code>{chapter_two_legend:hide}</code>.
Dazu muss einfach das Schlüsselwort <code>:hide</code> in das Felder-Array hinzugefügt werden.
MetaPalettes betrachtet alle mit ''':''' beginnenden Felder als Modifikatoren, diese werden aus der Feldliste extrahiert.
Zur Zeit wird aber nur das Schlüsselwort <code>:hide</code> unterstützt.

=Subpaletten definieren=

Auch Subpaletten lassen sich definieren:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubpalettes' => array
(
'field_three' => array('field_four', 'field_five')
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'__selector__' => array('field_three'),
...
),

'subpalettes' => array
(
'field_three' => 'field_four,field_five'
)
...
);
</source>

Das <code>__selector__</code> Array wird automatisch gefüllt, es ist also nicht mehr notwendig dieses Array von Hand zu befüllen.

=SubSelectpaletten definieren=
(seit Version 1.2.0)

Normalerweise verwendet Contao <code>select</code> Felder, die als Selectoren markiert sind dazu eine Palette auszuwählen. Das ist allerdings nicht immer sinnvoll, weil man dann viele Paletten definieren muss, die oft stark redundant sind. Mit SubSelectpaletten ist es möglich, ähnlich den Subpaletten einer Checkbox ''Untermengen'' von Feldern den einzelnen Select Werten zuzuordnen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'example' => array('subselect_field')
)
),
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
),
...
'fields' => array
(
'subselect_field' => array
(
'label' => array('SubSelect Example', 'Switch field and see how the subfields changing'),
'inputType' => 'select',
'options' => array('value1', 'value2', 'value3'),
'eval' => array('submitOnChange'=>true)
)
)
);
</source>

Um die Definition einfacher zu gestalten, kann man mit einem '''!''' (Ausrufezeichen) vor dem Wert auch Negativ-Paletten definieren. Diese werden immer dann angezeigt, wenn ein Wert nicht ausgewählt ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'!value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
)
...
);
</source>
Das Feld '''value2_subfield1''' wird immer dann angezeigt, wenn '''value1''' oder '''value3''' ausgewählt sind.

=Paletten ergänzen=

Ab Version 1.1 kann man vorhandene Paletten ganz einfach ergänzen. Dazu stehen 3 '''statische''' Methoden zur Verfügung.

==MetaPalettes::appendTo(..)==

Fügt eine Meta Palette am Ende hinzu.

<source lang="php">
MetaPalettes::appendTo('tl_settings', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
MetaPalettes::appendTo('tl_content', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''text''' Palette von '''tl_content''' hinzu.

==MetaPalettes::appendBefore(..) & MetaPalettes::appendAfter(..)==

Fügt eine Meta Palette vor oder nach einem Block ein.

<source lang="php">
MetaPalettes::appendBefore('tl_settings', 'title', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''title_legend''' der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 3. Parameter angegeben werden.
<source lang="php">
MetaPalettes::appendBefore('tl_content', 'published', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''published_legend''' der '''text''' Palette von '''tl_content''' hinzu.

Die Methode <code>MetaPalettes::appendAfter(..)</code> verhält sich äquivalent zu <code>MetaPalettes::appendBefore(..)</code>, nur dass der Block nicht vor, sondern nach dem anderen Block eingefügt wird.
{{Hinweis|Sollte der Block vor oder nach dem eingefügt werden soll nicht gefunden werden, wird die Palette am Ende hinzugefügt (wie bei <code>MetaPalettes::appendTo(..)</code>)}}

==MetaPalettes::appendFields(..) & MetaPalettes::prependFields(..)==
(seit Version 1.2.0)

Fügt eine Felder am Anfang oder Ende eines Blocks hinzu.

<source lang="php">
MetaPalettes::appendFields('tl_settings', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''default''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
MetaPalettes::prependFields('tl_content', 'text', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''text''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' am Anfang hinzu.

=Paletten vererben=
(seit Version 1.3.0)

Paletten lassen sich mit einfachen regeln vererben, die ererbten Regeln

<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three' => array('field_four', 'field_five')
)
),
...
);
</source>
{{Hinweis|Die ''_X_'' Notation mit den Unterstrichen ist '''nicht''' obligatorisch. Sie soll nur zeigen, dass diese Palette niemals direkt verwendet wird sondern nur als Basis für eine andere Palette dient!}}

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'_base_' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three',
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three;{chapter_three_legend},field_four,field_five'
)
...
);
</source>

Um eine Palette zu erben wird also die einfache Notation '''''<palette>'' extends ''<base>''''' verwendet.

==fein granulare Vererbung==

===Gruppe überschreiben===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' enthält später das Feld ''field_four''.

===Löschen von Gruppen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array()
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' wird gelöscht (leer gesetzt und damit nicht angezeigt).

===Gruppe positionieren===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three before chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_three'' wird vor der Gruppe ''chapter_two'' eingefügt. Mit dem ''after'' Schlüsselwort wird die Gruppe nach einer anderen Gruppe eingefügt.

===Einzelne Felder hinzufügen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_two' => array('field_four')
)
),
...
);
</source>
→ der Gruppe ''chapter_two'' wird das Feld ''field_four'' am Ende hinzugefügt.

===Einzelne Felder entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_two' => array('field_three')
)
),
...
);
</source>
→ aus der Gruppe ''chapter_two'' wird das Feld ''field_three'' entfernt.

===Felder an bestimmter Position hinzufügen und entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_one' => array('field_four before field_one', '-field_two')
)
),
...
);
</source>
→ fügt der Gruppe ''chapter_two'' das Feld ''field_four'' vor dem Feld ''field_one'' hinzu und entfernt das Feld ''field_two''. Mit ''after'' kann ein Feld auch nach einem anderen hinzugefügt werden.

Der Operator (+/-) im Palettennamen definiert die Operation für alle Felder ohne eigenem Operator. Die Operatoren können also auch umgekehrt werden.
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_one' => array('+field_four before field_one', 'field_two')
)
),
...
);
</source>
Hat die gleiche Bedeutung wie im vorherigen Beispiel.
{{Hinweis|Wenn einzelne Felder hinzugefügt oder entfernt werden sollen, dann ist ein Operator (+/-) im Palettenname zwingend erforderlich, weil MetaPalettes sonst annimmt das die Palette überschrieben und nicht verändert werden soll!}}

MetaPalettes

2018-01-08T12:16:48Z

Netzmacht:

Mit der Erweiterung MetaPalettes lassen sich die DCA Paletten in einem Array, statt einem String definieren. Dadurch wird es einfacher die Paletten später zu verändern.
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=Tristan Lins
| ExtVersion=2.0.0
| Version=4.4+ (Version 1.11 ist sowohl mit Contao >= 3.5 und Contao 4.4 kompatibel)
| ERLink=http://www.contao.org/erweiterungsliste/view/metapalettes.de.html
}}

MetaPalettes generiert aus einem Mehrdimensionalen-Array das im DCA festgelegt wird die Haupt- und Unterpaletten.

=Anwendungsbeispiel=

Beispiel für eine MetaPalette aus der Erweiterung [[htaccess]]:
<source lang="php">
/**
* DCA tl_htaccess
*/
$GLOBALS['TL_DCA']['tl_htaccess'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'default' => array
(
'htaccess_settings' => array(':hide', 'htaccess_load_settings'),
'htaccess_base' => array('htaccess_template'),
'htaccess_etag' => array('htaccess_etag_disable'),
'htaccess_mime' => array('htaccess_mime_types'),
'htaccess_deflate' => array('htaccess_deflate_files'),
'htaccess_headers' => array(),
'htaccess_expires' => array('htaccess_expires_default', 'htaccess_expires'),
'htaccess_custom' => array('htaccess_custom'),
'htaccess_rewrite' => array('htaccess_rewrite_rules', 'htaccess_rewrite_prepend_www', 'htaccess_rewrite_remove_www', 'htaccess_rewrite_gzip', 'htaccess_rewrite_suffix'),
'htaccess_h5bp' => array('htaccess_h5bp_ie_x_ua_compatible', 'htaccess_h5bp_cross_domain_ajax', 'htaccess_h5bp_concatenation_include', 'htaccess_h5bp_ie_flicker_fix')
)
),
...
);
</source>

Anstelle einer <code>palette</code> wird ein Feld <code>metapalette</code> definiert. Die Schlüssel für das Array definieren wie gewohnt die Palette, jedoch werden die einzelnen Abschnitte mit den Feldern nicht als Zeichenkette, sondern als Array definiert. Der Schlüssel aus dem Meta Array beschreibt den Abschnitt, darunter kommt wiederum als Array die Felder.

=Paletten definieren=

Am besten zeigt sich der Zusammenhang an einem kleinen Beispiel:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
)
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three'
)
...
);
</source>

Der Array Key definieren jeweils die Legende für den Abschnitt, das '''_legend''' wird dabei automatisch hinzugefügt.

==:hide und andere Modifikatoren==

Eine Palette kann versteckt angezeigt werden, wie oben chapter_two: <code>{chapter_two_legend:hide}</code>.
Dazu muss einfach das Schlüsselwort <code>:hide</code> in das Felder-Array hinzugefügt werden.
MetaPalettes betrachtet alle mit ''':''' beginnenden Felder als Modifikatoren, diese werden aus der Feldliste extrahiert.
Zur Zeit wird aber nur das Schlüsselwort <code>:hide</code> unterstützt.

=Subpaletten definieren=

Auch Subpaletten lassen sich definieren:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubpalettes' => array
(
'field_three' => array('field_four', 'field_five')
)
...
);
</source>

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'__selector__' => array('field_three'),
...
),

'subpalettes' => array
(
'field_three' => 'field_four,field_five'
)
...
);
</source>

Das <code>__selector__</code> Array wird automatisch gefüllt, es ist also nicht mehr notwendig dieses Array von Hand zu befüllen.

=SubSelectpaletten definieren=
(seit Version 1.2.0)

Normalerweise verwendet Contao <code>select</code> Felder, die als Selectoren markiert sind dazu eine Palette auszuwählen. Das ist allerdings nicht immer sinnvoll, weil man dann viele Paletten definieren muss, die oft stark redundant sind. Mit SubSelectpaletten ist es möglich, ähnlich den Subpaletten einer Checkbox ''Untermengen'' von Feldern den einzelnen Select Werten zuzuordnen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metapalettes' => array
(
'default' => array
(
'example' => array('subselect_field')
)
),
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
),
...
'fields' => array
(
'subselect_field' => array
(
'label' => array('SubSelect Example', 'Switch field and see how the subfields changing'),
'inputType' => 'select',
'options' => array('value1', 'value2', 'value3'),
'eval' => array('submitOnChange'=>true)
)
)
);
</source>

Um die Definition einfacher zu gestalten, kann man mit einem '''!''' (Ausrufezeichen) vor dem Wert auch Negativ-Paletten definieren. Diese werden immer dann angezeigt, wenn ein Wert nicht ausgewählt ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'metasubselectpalettes' => array
(
'subselect_field' => array
(
'value1' => array('value1_subfield1', 'value1_subfield2'),
'!value2' => array('value2_subfield1'),
'value3' => array('value3_subfield1', 'value3_subfield2', 'value3_subfield3')
)
)
...
);
</source>
Das Feld '''value2_subfield1''' wird immer dann angezeigt, wenn '''value1''' oder '''value3''' ausgewählt sind.

=Paletten ergänzen=

Ab Version 1.1 kann man vorhandene Paletten ganz einfach ergänzen. Dazu stehen 3 '''statische''' Methoden zur Verfügung.

==MetaPalettes::appendTo(..)==

Fügt eine Meta Palette am Ende hinzu.

<source lang="php">
MetaPalettes::appendTo('tl_settings', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
MetaPalettes::appendTo('tl_content', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' am Ende der '''text''' Palette von '''tl_content''' hinzu.

==MetaPalettes::appendBefore(..) & MetaPalettes::appendAfter(..)==

Fügt eine Meta Palette vor oder nach einem Block ein.

<source lang="php">
MetaPalettes::appendBefore('tl_settings', 'title', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''title_legend''' der '''default''' Palette von '''tl_settings''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 3. Parameter angegeben werden.
<source lang="php">
MetaPalettes::appendBefore('tl_content', 'published', 'text', array(
'my_custom_settings' => array(':hide', 'my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt den Block '''my_custom_settings''' vor den Block '''published_legend''' der '''text''' Palette von '''tl_content''' hinzu.

Die Methode <code>MetaPalettes::appendAfter(..)</code> verhält sich äquivalent zu <code>MetaPalettes::appendBefore(..)</code>, nur dass der Block nicht vor, sondern nach dem anderen Block eingefügt wird.
{{Hinweis|Sollte der Block vor oder nach dem eingefügt werden soll nicht gefunden werden, wird die Palette am Ende hinzugefügt (wie bei <code>MetaPalettes::appendTo(..)</code>)}}

==MetaPalettes::appendFields(..) & MetaPalettes::prependFields(..)==
(seit Version 1.2.0)

Fügt eine Felder am Anfang oder Ende eines Blocks hinzu.

<source lang="php">
MetaPalettes::appendFields('tl_settings', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''default''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' hinzu.

Wenn eine andere Palette gewünscht ist, kann diese als 2. Parameter angegeben werden.
<source lang="php">
MetaPalettes::prependFields('tl_content', 'text', 'title', array(
array('my_custom_field1', 'my_custom_field2', 'my_custom_field3')
));
</source>
Fügt dem Block '''title_legend''' der '''text''' Palette die Felder '''my_custom_field1''', '''my_custom_field2''' und '''my_custom_field3''' am Anfang hinzu.

=Paletten vererben=
(seit Version 1.3.0)

Paletten lassen sich mit einfachen regeln vererben, die ererbten Regeln

<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three' => array('field_four', 'field_five')
)
),
...
);
</source>
{{Hinweis|Die ''_X_'' Notation mit den Unterstrichen ist '''nicht''' obligatorisch. Sie soll nur zeigen, dass diese Palette niemals direkt verwendet wird sondern nur als Basis für eine andere Palette dient!}}

Daraus wird:
<source lang="php">
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
'palettes' => array
(
'_base_' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three',
'default' => '{chapter_one_legend},field_one,field_two;{chapter_two_legend:hide},field_three;{chapter_three_legend},field_four,field_five'
)
...
);
</source>

Um eine Palette zu erben wird also die einfache Notation '''''<palette>'' extends ''<base>''''' verwendet.

==fein granulare Vererbung==

===Gruppe überschreiben===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' enthält später das Feld ''field_four''.

===Löschen von Gruppen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_two' => array()
)
),
...
);
</source>
→ die Gruppe ''chapter_two'' wird gelöscht (leer gesetzt und damit nicht angezeigt).

===Gruppe positionieren===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'chapter_three before chapter_two' => array('field_four')
)
),
...
);
</source>
→ die Gruppe ''chapter_three'' wird vor der Gruppe ''chapter_two'' eingefügt. Mit dem ''after'' Schlüsselwort wird die Gruppe nach einer anderen Gruppe eingefügt.

===Einzelne Felder hinzufügen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_two' => array('field_four')
)
),
...
);
</source>
→ der Gruppe ''chapter_two'' wird das Feld ''field_four'' am Ende hinzugefügt.

===Einzelne Felder entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_two' => array('field_three')
)
),
...
);
</source>
→ aus der Gruppe ''chapter_two'' wird das Feld ''field_three'' entfernt.

===Felder an bestimmter Position hinzufügen und entfernen===
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'+chapter_one' => array('field_four before field_one', '-field_two')
)
),
...
);
</source>
→ fügt der Gruppe ''chapter_two'' das Feld ''field_four'' vor dem Feld ''field_one'' hinzu und entfernt das Feld ''field_two''. Mit ''after'' kann ein Feld auch nach einem anderen hinzugefügt werden.

Der Operator (+/-) im Palettennamen definiert die Operation für alle Felder ohne eigenem Operator. Die Operatoren können also auch umgekehrt werden.
<source lang="php">
/**
* DCA tl_example
*/
$GLOBALS['TL_DCA']['tl_example'] = array
(
...
// meta pallettes
'metapalettes' => array
(
'_base_' => array
(
'chapter_one' => array('field_one', 'field_two'),
'chapter_two' => array(':hide', 'field_three')
),
'default extends _base_' => array
(
'-chapter_one' => array('+field_four before field_one', 'field_two')
)
),
...
);
</source>
Hat die gleiche Bedeutung wie im vorherigen Beispiel.
{{Hinweis|Wenn einzelne Felder hinzugefügt oder entfernt werden sollen, dann ist ein Operator (+/-) im Palettenname zwingend erforderlich, weil MetaPalettes sonst annimmt das die Palette überschrieben und nicht verändert werden soll!}}

Contao-Bootstrap

2015-03-02T18:04:27Z

Netzmacht:

[[Category:Extensions]]
{{ExtInfo
| Dev=David Molineus
| DevSite=http://www.netzmacht.de/
| ExtVersion=1.0
| Version=3.2 - 3.4
| VCSLink=https://github.com/contao-bootstrap
}}

=Contao-Bootstrap=

Die Erweiterung erleichtert die Verwendung von Bootstrap 3 innherhalb von Contao. Als modular aufgebaute Erweiterung bringt sie verschiedene Komponenten mit, die als [https://github.com/contao-bootstrap/bundle Bundle] oder als einzelne Pakete installiert werden können.

==Komponenten==

Die einzelnen Komponenten bringen Inhaltselemente, Frontend-Module und weitere Hilfmittel wie einen Grid-Editor und angepasste Templates mit.

* [https://github.com/contao-bootstrap/bundle Bundle]
* [https://github.com/contao-bootstrap/core Core]
* [https://github.com/contao-bootstrap/buttons Core]
* [https://github.com/contao-bootstrap/carousel Carousel]
* [https://github.com/contao-bootstrap/form Formular]
* [https://github.com/contao-bootstrap/grid-editor Grid-Editor]
* [https://github.com/contao-bootstrap/layout Layout]
* [https://github.com/contao-bootstrap/modal Modal]
* [https://github.com/contao-bootstrap/navigation Navigation]
* [https://github.com/contao-bootstrap/panel Panel]
* [https://github.com/contao-bootstrap/tab Tab]
* [https://github.com/contao-bootstrap/templates Templates]

==Dokunmentation & Support==

Contao-Bootstrap unterstützt nur die Installation über [[Composer/Client|Composer]]. Details und Dokumentation finden sich auf der Projektseite bzw. der Dokumentation auf readthedocs.org

* [https://contao-bootstrap.netzmacht.de Projektseite]
* [https://contao-bootstrap.readthedocs.org Dokumentation]
* [https://community.contao.org/de/forumdisplay.php?169-contao-bootstrap Support-Forum]

Contao-Bootstrap

2015-03-02T18:03:35Z

Netzmacht:

[[Category:Extensions]]
{{ExtInfo
| Dev=David Molineus
| DevSite=http://www.netzmacht.de/
| ExtVersion=1.0
| Version=3.2-3.4
| VCSLink=https://github.com/contao-bootstrap
}}

=Contao-Bootstrap=

Die Erweiterung erleichtert die Verwendung von Bootstrap 3 innherhalb von Contao. Als modular aufgebaute Erweiterung bringt sie verschiedene Komponenten mit, die als [https://github.com/contao-bootstrap/bundle Bundle] oder als einzelne Pakete installiert werden können.

==Komponenten==

Die einzelnen Komponenten bringen Inhaltselemente, Frontend-Module und weitere Hilfmittel wie einen Grid-Editor und angepasste Templates mit.

* [https://github.com/contao-bootstrap/bundle Bundle]
* [https://github.com/contao-bootstrap/core Core]
* [https://github.com/contao-bootstrap/buttons Core]
* [https://github.com/contao-bootstrap/carousel Carousel]
* [https://github.com/contao-bootstrap/form Formular]
* [https://github.com/contao-bootstrap/grid-editor Grid-Editor]
* [https://github.com/contao-bootstrap/layout Layout]
* [https://github.com/contao-bootstrap/modal Modal]
* [https://github.com/contao-bootstrap/navigation Navigation]
* [https://github.com/contao-bootstrap/panel Panel]
* [https://github.com/contao-bootstrap/tab Tab]
* [https://github.com/contao-bootstrap/templates Templates]

==Dokunmentation & Support==

Contao-Bootstrap unterstützt nur die Installation über [[Composer/Client|Composer]]. Details und Dokumentation finden sich auf der Projektseite bzw. der Dokumentation auf readthedocs.org

* [https://contao-bootstrap.netzmacht.de Projektseite]
* [https://contao-bootstrap.readthedocs.org Dokumentation]
* [https://community.contao.org/de/forumdisplay.php?169-contao-bootstrap Support-Forum]

Contao-Bootstrap

2015-03-02T17:58:14Z

Netzmacht: Die Seite wurde neu angelegt: „Category:Extensions {{ExtInfo | Dev=David Molineus | DevSite=http://www.netzmacht.de/ | ExtVersion=1.0 | Version=3.2-3.4 | VCSLink=https://github.com/conta…“

DC General

2013-04-16T12:08:43Z

Netzmacht: Rechtschreibfehler behoben

[[Category:Extensions]]
Der '''DC_General''' ist als allgemeingültiger, umfassender Treiber für das gesamte Contao-Backend konzipiert.
{{ExtInfo
| DevSite=http://www.men-at-work.de
| ExtVersion=0.9.0 beta1
| Version=2.11
| TrackerLink=https://github.com/MetaModels/DC_General/issues
}}

== Was ist ein DC_General? ==

DC_General entstand auf der Basis von dem DC_Table Treiber. Allerdings wurden einige Sachen verändert. Zum einem wurde der Treiber auf eine MVC (Model View Controller) Basis umgebaut. Dadurch entstehen folgende Vorteile:
* Der Datenprovider ist austauschbar, somit ist es möglich, die Daten von jedem beliebigen Ort zu laden bzw. zu speichern. Nachfolgend einige Aufzählungen für DatenProvider
** Datenbanken (MySql, PostgresSql etc.)
** XML Dateien
** Email (pop3, imap)
** API Schnittstellen
** RPC
** usw.
* Die Daten werden innerhalb des DC_General in Models und Collections gespeichert
* Die Views bzw. Controller sind austauschbar.

Weiter Eigenschaften:
* Eigene Templates für alle Ansichten, kein Inline HTML mehr.
* In memory editing - Daten werden erst in die Datenbank gespeichert, wenn auch Speichern gedrückt wurde.
* Multilanguage Support - Elemente zum Wechseln der Sprache sind schon von Haus aus eingebaut.

== Tabellenkonfiguration ==

{| cellpadding="20" cellspacing="0"
|-
| '''Schlüssel''' || '''Wert''' || '''Beschreibung'''
|-
| onload_callback || Callback-Funktion ''array'' || Ruft eine Callback-Funktion beim Initialisieren des Data Containers auf und übergibt das DataContainer-Objekt als Argument.
|-
| onsubmit_callback || Callback-Funktion ''array'' || Ruft eine Callback-Funktion nach der Aktualisierung eines Datensatzes auf und übergibt das DataContainer-Objekt als Argument.
|-
|}

== Was ist DC_General nicht? ==

DC_General ist zwar auf der Basis vom DC_Table entstanden, allerdings wurden viele Kernelemente umgebaut. Somit ist es nicht möglich das DC_Table und die anderen Contao Core Treiber einfach mit dem DC_General ersetzt werden.

Vielmehr war der Gedanke das DC_General ein Treiber darstellt, der es erlaubt, mit mehr und weniger Aufwand, ein eigenes Backend ohne Contao-Core-Hacking zu erstellen.

Button Regeln

2012-12-20T14:26:47Z

Netzmacht: /* Beispiele */

[[Kategorie:Dcarules]]
{{stub}}
=Button Regeln verwenden=

Auf dieser Seite werden die Button Regeln von [[dca-rules]] beschrieben. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generate=

Dient zur Ausgabe des Buttons. Solange keine andere Ausgaberoutine verwendet wird muss sie mit angegeben werden.

==Mögliche Parameter==
* '''plain''' ''bool'', optional Verwendet nur das Href Attribut des Buttons als Link. Normalerweise wird dies mit addToHref() an den Link angefügt
* '''disable''' ''bool'', optional Gibt ein Icon als Bild und nicht als Link aus (nur bei normalen Operationen)
* '''noTable''' ''bool'', optional Ist plain nicht gesetzt, wird standardmäßig die Tabelle an den Link angehangen. Mit dieser Option wird es unterbunden
* '''noId''' ''bool'', optional Ist plain nicht gesetzt, wird standardmäßig die ID an den Link angehangen. Mit dieser Option wird es unterbunden

==Beispiele==

<source lang="php">
// erstellt einen Button zu Google
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['google']['href'] = 'http://www.google.com';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['google']['button_rules'] = array('generate:plain');

// erzeugt einen Link zur Kindertabelle ohne die aktuelle Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['ctable']['href'] = 'table=ctable';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['ctable']['button_rules'] = array('generate:noTable');

// ezeugt Link zum Modul files ohne Tabelle und ID
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['file']['href'] = 'do=files';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['files']['button_rules'] = array('generate:noTable:noId');
</source>

=Regel disableIcon=

Mit dieser Regel ist es möglich einen Button mit einem deaktivierten Icon auszugeben. Dabei wird eine andere Regel angegeben, die bestimmt welcher Zustand angezeigt wird. Diese Regel wirkt sich nur auf normale Operationen aus.

==Mögliche Parameter==
* '''rule''' ''string'', Name der Regel, die den Zustand bestimmt
* '''icon''' ''string'', optional Das Icon, das den inaktiven Zustand anzeigen soll. Standardmäßig wird der Wert des normalen Icons genommen und mit einem Unterstrich verlängert (edit.gif -> edit_.gif)

==Beispiele==

<source lang="php">
// Zeigt anstelle von Button wakeup nur ein deaktiviertes Icon an
$GLOBALS['TL_DCA']['tl_feedback']['operations']['wakeup']['button_rules'] = array('disableIcon:rule=notOnSunday:icon=snore.png', 'generate');

// liefert falsch, damit der button deaktiviert wird
protected function buttonRuleNotOnSunday(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
return (date('N') != 7);
}

</source>

=Regel referer=
=Regel hasAccess=
=Regel isAdmin=
=Regel isAllowed=
=Regel toggleIcon=

Button Regeln

2012-12-20T14:23:44Z

Netzmacht:

[[Kategorie:Dcarules]]
{{stub}}
=Button Regeln verwenden=

Auf dieser Seite werden die Button Regeln von [[dca-rules]] beschrieben. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generate=

Dient zur Ausgabe des Buttons. Solange keine andere Ausgaberoutine verwendet wird muss sie mit angegeben werden.

==Mögliche Parameter==
* '''plain''' ''bool'', optional Verwendet nur das Href Attribut des Buttons als Link. Normalerweise wird dies mit addToHref() an den Link angefügt
* '''disable''' ''bool'', optional Gibt ein Icon als Bild und nicht als Link aus (nur bei normalen Operationen)
* '''noTable''' ''bool'', optional Ist plain nicht gesetzt, wird standardmäßig die Tabelle an den Link angehangen. Mit dieser Option wird es unterbunden
* '''noId''' ''bool'', optional Ist plain nicht gesetzt, wird standardmäßig die ID an den Link angehangen. Mit dieser Option wird es unterbunden

==Beispiele==

<source lang="php">
// erstellt einen Button zu Google
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['google']['href'] = 'http://www.google.com';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['google']['button_rules'] = array('generate:plain');

// erzeugt einen Link zur Kindertabelle ohne die aktuelle Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['ctable']['href'] = 'table=ctable';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['ctable']['button_rules'] = array('generate:noTable');

// ezeugt Link zum Modul files ohne Tabelle und ID
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['file']['href'] = 'do=files';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['files']['button_rules'] = array('generate:noTable:noId');
</source>

=Regel disableIcon=

Mit dieser Regel ist es möglich einen Button mit einem deaktivierten Icon auszugeben. Dabei wird eine andere Regel angegeben, die bestimmt welcher Zustand angezeigt wird. Diese Regel wirkt sich nur auf normale Operationen aus.

==Mögliche Parameter==
* '''rule''' ''string'', Name der Regel, die den Zustand bestimmt
* '''icon''' ''string'', optional Das Icon, das den inaktiven Zustand anzeigen soll. Standardmäßig wird der Wert des normalen Icons genommen und mit einem Unterstrich verlängert (edit.gif -> edit_.gif)

==Beispiele==

<source lang="php">
// Zeigt anstelle von Button wakeup nur ein deaktiviertes Icon an
$GLOBALS['TL_DCA']['tl_feedback']['operations']['wakeup']['button_rules'] = array('disableIcon:rule=notOnSunday:icon=snore.png', 'generate');

// liefert falsch, damit der button deaktiviert wird
protected function buttonRuleNotOnSunday(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
return (date('N') == 7);
}

</source>

=Regel referer=
=Regel hasAccess=
=Regel isAdmin=
=Regel isAllowed=
=Regel toggleIcon=

Button Regeln

2012-12-20T14:22:10Z

Netzmacht: Die Seite wurde neu angelegt: „Kategorie:Dcarules =Button Regeln verwenden= Auf dieser Seite werden die Button Regeln von dca-rules beschrieben. Bei dca-rules handelt es sich um eine …“

[[Kategorie:Dcarules]]

=Button Regeln verwenden=

Auf dieser Seite werden die Button Regeln von [[dca-rules]] beschrieben. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generate=

Dient zur Ausgabe des Buttons. Solange keine andere Ausgaberoutine verwendet wird muss sie mit angegeben werden.

==Mögliche Parameter==
* '''plain''' ''bool'', optional Verwendet nur das Href Attribut des Buttons als Link. Normalerweise wird dies mit addToHref() an den Link angefügt
* '''disable''' ''bool'', optional Gibt ein Icon als Bild und nicht als Link aus (nur bei normalen Operationen)
* '''noTable''' ''bool'', optional Ist plain nicht gesetzt, wird standardmäßig die Tabelle an den Link angehangen. Mit dieser Option wird es unterbunden
* '''noId''' ''bool'', optional Ist plain nicht gesetzt, wird standardmäßig die ID an den Link angehangen. Mit dieser Option wird es unterbunden

==Beispiele==

<source lang="php">
// erstellt einen Button zu Google
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['google']['href'] = 'http://www.google.com';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['google']['button_rules'] = array('generate:plain');

// erzeugt einen Link zur Kindertabelle ohne die aktuelle Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['ctable']['href'] = 'table=ctable';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['ctable']['button_rules'] = array('generate:noTable');

// ezeugt Link zum Modul files ohne Tabelle und ID
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['file']['href'] = 'do=files';
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['files']['button_rules'] = array('generate:noTable:noId');
</source>

=Regel disableIcon=

Mit dieser Regel ist es möglich einen Button mit einem deaktivierten Icon auszugeben. Dabei wird eine andere Regel angegeben, die bestimmt welcher Zustand angezeigt wird. Diese Regel wirkt sich nur auf normale Operationen aus.

==Mögliche Parameter==
* '''rule''' ''string'', Name der Regel, die den Zustand bestimmt
* '''icon''' ''string'', optional Das Icon, das den inaktiven Zustand anzeigen soll. Standardmäßig wird der Wert des normalen Icons genommen und mit einem Unterstrich verlängert (edit.gif -> edit_.gif)

==Beispiele==

<source lang="php">
// Zeigt anstelle von Button wakeup nur ein deaktiviertes Icon an
$GLOBALS['TL_DCA']['tl_feedback']['operations']['wakeup']['button_rules'] = array('disableIcon:rule=notOnSunday:icon=snore.png', 'generate');

// liefert falsch, damit der button deaktiviert wird
protected function buttonRuleNotOnSunday(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
return (date('N') == 7);
}

</source>

Permission Regeln

2012-12-20T10:17:15Z

Netzmacht: /* Beispiele */

[[Kategorie:Dcarules]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''key''' ''array/string'', optional definiert die angegebenen Aktionen, die über den GET Pataremter key definiert werden und von der Regel betroffen sind
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''array'', optional Namen der Get Parameter, mit in der Fehlermeldung ausgegeben werden sollen. Außerdem kann der Platzhalter %user für den Benutzernamen angegeben werden.

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus show und edit sowie auf custom erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]:key=custom');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=show');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Permission Regeln

2012-12-20T10:16:18Z

Netzmacht: /* Mögliche Parameter */

[[Kategorie:Dcarules]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''key''' ''array/string'', optional definiert die angegebenen Aktionen, die über den GET Pataremter key definiert werden und von der Regel betroffen sind
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''array'', optional Namen der Get Parameter, mit in der Fehlermeldung ausgegeben werden sollen. Außerdem kann der Platzhalter %user für den Benutzernamen angegeben werden.

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=show');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Dca-rules

2012-12-20T10:15:14Z

Netzmacht:

[[Category:Dcarules]]
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc3
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung. Bei den Button Callbacks handelt es sich um magische Callbacks, die um den Buttonnamen ergänzt werden müssen. Dies ist erforderlich, damit der allgemeine Callback nur bei dem entsprechenden Button ausgeführt wird.

* checkPermission
* generateButton*
* generateGlobalButton*
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
$rule = array('rule:error=&.errors.1'); // accessing language vars of current table
$rule = array('rule:error=&MSC.yes'); // accessing language var $GLOBALS['TL_LANG']['MSC']['yes']
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array
(
'isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit'
);
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonEdit'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonMember'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonDelete'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der vordefinierten Regeln. Auf den jeweiligen Unterseiten ist die Verwendungsweise der Regeln näher erläutert:

'''[[Permission Regeln]]'''
* generic
* hasAccess
* isAllowed
* isAdmin
* forbidden

'''[[Button Regeln]]'''
* disableIcon
* toggleIcon
* referer
* hasAccess
* isAllowed
* isAdmin

'''[[Label Regeln]]'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

Da die Variablen per Referenz übergeben werden, können sie so von einer Regel zur nächsten weitergereicht werden. Möchte eine Regel beispielsweise das Icon ersetzen, so muss lediglich die icon Variable neu gesetzt werden.

<source lang="php">
protected function buttonRuleChangeIcon(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
$strIcon = (isset($arrAttribute['icon']) ? $arrAttribute['icon'] : 'change.gif';
}
</source>

Sollen Attribute weitergereicht werden, so ist es erforderlich, diese als solche zu kennzeichnen. Damit wird verhindert, dass sich die einzelnen Regeln ungewollt gegenseitig beinflussen, aber dennoch Anweisungen an nächste Regeln gesetzt werden können. Dazu muss unter $arrAttributes['__set__'] das entsprechende Feld hinzugefügt werden. Sinnvoll ist dies beispielsweise, wenn eine Regel die Ausgabe beeinflussen möchte:

<source lang="php">
protected function buttonRuleReferer(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
$strHref = $this->getReferer(true);

// do not use addToUrl() instead use plain href
$arrAttributes['plain'] = true;
$arrAttributes['__set__'][] = 'plain';

return true;
}
</source>

Dca-rules

2012-12-20T09:10:58Z

Netzmacht: /* Eigene Regeln definieren */

[[Category:Dcarules]]
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc2
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung. Bei den Button Callbacks handelt es sich um magische Callbacks, die um den Buttonnamen ergänzt werden müssen. Dies ist erforderlich, damit der allgemeine Callback nur bei dem entsprechenden Button ausgeführt wird.

* checkPermission
* generateButton*
* generateGlobalButton*
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
$rule = array('rule:error=&.errors.1'); // accessing language vars of current table
$rule = array('rule:error=&MSC.yes'); // accessing language var $GLOBALS['TL_LANG']['MSC']['yes']
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array
(
'isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit'
);
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonEdit'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonMember'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonDelete'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben. Über die Überschriften ist die Verwendung der entsprechenden Regeln dokumentiert:

'''[[Permission Regeln]]'''
* generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
* hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
* forbidden ''(act,error,params)'' Zugriff generell verbieten

'''[[Button Regeln]]'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''[[Label Regeln]]'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

Da die Variablen per Referenz übergeben werden, können sie so von einer Regel zur nächsten weitergereicht werden. Möchte eine Regel beispielsweise das Icon ersetzen, so muss lediglich die icon Variable neu gesetzt werden.

<source lang="php">
protected function buttonRuleChangeIcon(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
$strIcon = (isset($arrAttribute['icon']) ? $arrAttribute['icon'] : 'change.gif';
}
</source>

Sollen Attribute weitergereicht werden, so ist es erforderlich, diese als solche zu kennzeichnen. Damit wird verhindert, dass sich die einzelnen Regeln ungewollt gegenseitig beinflussen, aber dennoch Anweisungen an nächste Regeln gesetzt werden können. Dazu muss unter $arrAttributes['__set__'] das entsprechende Feld hinzugefügt werden. Sinnvoll ist dies beispielsweise, wenn eine Regel die Ausgabe beeinflussen möchte:

<source lang="php">
protected function buttonRuleReferer(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null)
{
$strHref = $this->getReferer(true);

// do not use addToUrl() instead use plain href
$arrAttributes['plain'] = true;
$arrAttributes['__set__'][] = 'plain';

return true;
}
</source>

Permission Regeln

2012-12-19T16:46:38Z

Netzmacht: /* Mögliche Parameter */

[[Kategorie:Dcarules]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''array'', optional Namen der Get Parameter, mit in der Fehlermeldung ausgegeben werden sollen. Außerdem kann der Platzhalter %user für den Benutzernamen angegeben werden.

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=show');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Permission Regeln

2012-12-19T16:46:11Z

Netzmacht: /* Mögliche Parameter */

[[Kategorie:Dcarules]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''string'', optional Namen der Get Parameter, mit in der Fehlermeldung ausgegeben werden sollen. Außerdem kann der Platzhalter %user für den Benutzernamen angegeben werden.

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=show');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Dca-rules

2012-12-19T14:42:14Z

Netzmacht:

Permission Regeln

2012-12-19T14:35:54Z

Netzmacht: /* Beispiele */

[[Kategorie:Dcarules]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''string'', optional Werte die in der Fehlermeldung ersetzt werden sollen

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=show');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Permission Regeln

2012-12-19T13:41:53Z

Netzmacht:

[[Kategorie:Dcarules]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''string'', optional Werte die in der Fehlermeldung ersetzt werden sollen

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=['show']');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Permission Regeln

2012-12-19T13:37:17Z

Netzmacht: /* Permission Regeln verwenden */

[[Category:Dca-rules]]
[[Kategorie:Extensions]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''string'', optional Werte die in der Fehlermeldung ersetzt werden sollen

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=['show']');
</source>

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Permission Regeln

2012-12-19T13:35:12Z

Netzmacht: Die Seite wurde neu angelegt: „Category:Dca-rules Kategorie:Extensions =Permission Regeln verwenden= Auf dieser Seite werden die Permission Regeln von dca-rules dokumentiert. Bei …“

[[Category:Dca-rules]]
[[Kategorie:Extensions]]

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel generic=

Diese Regel dient als Basis aller weiteren Permission-Regeln. Ihr Hauptaufgabe ist den Zugriff der Aktionen zu beschränken. Dabei sind die angegebenen Aktionen als Whitelist zu verstehen. Sie kann daher auch als eigenständige Regel verwendet werden. Außerdem besteht die Möglichkeit bei einer fehlgeschlagenen Überprüfung eine angepasste Fehlermeldung zu erstellen, die im Systemlog erscheint.

==Mögliche Parameter==
* '''act''' ''array/string'', optional definiert die angegebenen Aktionen des DataContainers, auf die die Regel angewendet wird
* '''error''' ''string'', optional die Fehlermeldung für die Logdatei
* '''params''' ''string'', optional Werte die in der Fehlermeldung ersetzt werden sollen

==Beispiele==

<source lang="php">
// Zugriff aus show erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=show');

// Zugriff aus Löschen sowie show und edit erlauben
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show,edit]');

// benutzerdefinierte Fehlermeldung
$GLOBALS['TL_LANG']['tl_feedback']['errors'][4] = 'Hacking attempt on tl_feedback. Only action "%s" allowed';
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('generic:act=[show]:error=&.errors.4:params=['show']');
</source>

=Permission Regeln verwenden=

Auf dieser Seite werden die Permission Regeln von [[dca-rules]] dokumentiert. Bei dca-rules handelt es sich um eine Erweiterung, mit deren hilfe wiederkehrende Bedingungen für DataContainer innerhalb von DCA-Dateien angegeben werden können ohne extra Callbacks zu definieren.

=Regel hasAccess=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::hasAccess zu überprüfen. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

==Mögliche Parameter==
* '''module''' ''array/string'', optional Überprüft den Zugriff auf Module
* '''permission''' ''string'', optional Definiert eine beliebige Zugriffsart für BackendUser::hasAccess(action, permission)
* '''action''' ''array/string'', optional Definiert eine beliebige Aktion für BackendUser::hasAccess(action, permission)
* '''alexf''' ''string'', optional Kurzform um Zugriff auf Feld zu überprüfen BackendUser::hasAccess(alexf, 'alexf')
* '''table''' ''string'', optional in Verbindung mit alexf oder action möglich die Tabelle zu bestimmen
* '''fop''' ''string'', optional Kurzform zur Überprüfung für BackendUser::hasAccess(fop, 'fop')

==Beispiele==

<source lang="php">
// Modulzugriff überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=tl_article');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:module=[tl_article,tl_news]');

// Zugriffsüberprüfung per permission und action
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=newp:action=create');

// Zugriff auf Feld der DCA-Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status');

// Zugriff auf Feld einer anderen Tabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:permission=alefx:action=status:table=tl_news');
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:alexf=status:table=tl:news');

// Zugriff auf Dateioperation
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:fop=5');

// Zugriff nur bei Bearbeiten überprüfen
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('hasAccess:act=[edit,editAll]:alexf=status');
</source>

=Regel isAllowed=

Diese Regel dient dazu Zugriffsbeschränkungen über die BackendUser::isAllowed zu überprüfen. Damit kann der Zugriff auf eine Seite überprüft werden. Sie besitzt neben den hier aufgelisteten Parameter die der Regel ''generic''. Allerdings dient hierbei der Parameter als Begrenzung der Regel. Sie wird also nur dann ausgeführt, wenn die Aktion auch aufgerufen wurde.

Diese Erweiterung erlaubt es neben der Überprüfung der aktuellen Datenreihe auch eine beliebige andere Tabelle als Grundlage der Überprüfung zu nehmen. Beispielsweise, wenn man auf der Ebene der tl_content die Rechte überprüfen will.

==Mögliche Parameter==
* '''operation''' ''int'', erforderlich prüft ob die Aktion auf die aktuelle Seite auszuführen ist
* '''ptable''' ''bool/string'', optional wahr, wenn die Elterntabelle als Grundlage genommen werden soll. alternativ einen Tabellenname
* '''pid''' ''string'', optional Die Spalte der aktuellen Zeile, die zum Laden der ptable als ID genommen soll, standard ist pid
* '''value''' ''int'', optional Alternativ einen Wert zur Überprüfung auf id=value, nur im Zusammenhang mit ptable

==Beispiele==

<source lang="php">
// Zugriff auf der Basis der aktuellen Datenzeile
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5');

// Zugriff auf der Basis der Elterntabelle
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable');

// Zugriff auf der Basis einer beliebigen Elterntabelle mit einer beliebigen ID Spalte
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable=tl_subcontent:pid=pageid');

// Zugriff auf eine bestimmte Zeile der ID 3
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAllowed:operation=5:ptable:value=3');
</source>

=Regeln isAdmin und forbidden=

Die Regel isAdmin dient dazu Zugriff auf den Administrator zu beschränken. Sie besitzt keine weiteren Parameter als die von der Regel generic. Die Regel forbidden verbietet den Zugriff auf die angebenen Aktionen:

<source lang="php">
// Bearbeiten nur für Admin, Löschen verbieten
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[edit,editAll]', 'forbidden:act=[delete,deleteAll]');
</source>

Dca-rules

2012-12-19T13:34:31Z

Netzmacht: Änderung 5678 von Netzmacht (Diskussion) wurde rückgängig gemacht.

[[Category:Dca-rules]]
[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc2
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung. Bei den Button Callbacks handelt es sich um magische Callbacks, die um den Buttonnamen ergänzt werden müssen. Dies ist erforderlich, damit der allgemeine Callback nur bei dem entsprechenden Button ausgeführt wird.

* checkPermission
* generateButton*
* generateGlobalButton*
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
$rule = array('rule:error=&.errors.1'); // accessing language vars of current table
$rule = array('rule:error=&MSC.yes'); // accessing language var $GLOBALS['TL_LANG']['MSC']['yes']
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array
(
'isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit'
);
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonEdit'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonMember'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonDelete'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben. Über die Überschriften ist die Verwendung der entsprechenden Regeln dokumentiert:

'''[[Permission Regeln]]'''
* generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
* hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
* forbidden ''(act,error,params)'' Zugriff generell verbieten

'''[[Button Regeln]]'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''[[Label Regeln]]'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

Dca-rules

2012-12-19T13:34:03Z

Netzmacht: Änderung 5679 von Netzmacht (Diskussion) wurde rückgängig gemacht.

Dca-rules

2012-12-19T13:32:19Z

Netzmacht:

Dca-rules

2012-12-19T13:01:42Z

Netzmacht:

Dca-rules

2012-12-19T12:22:00Z

Netzmacht:

Dca-rules

2012-12-19T12:18:48Z

Netzmacht: /* Vorhandene Regeln */

[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc2
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung. Bei den Button Callbacks handelt es sich um magische Callbacks, die um den Buttonnamen ergänzt werden müssen. Dies ist erforderlich, damit der allgemeine Callback nur bei dem entsprechenden Button ausgeführt wird.

* checkPermission
* generateButton*
* generateGlobalButton*
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
$rule = array('rule:error=&.errors.1'); // accessing language vars of current table
$rule = array('rule:error=&MSC.yes'); // accessing language var $GLOBALS['TL_LANG']['MSC']['yes']
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array
(
'isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit'
);
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonEdit'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonMember'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonDelete'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben. Über die Überschriften ist die Verwendung der entsprechenden Regeln dokumentiert:

'''[[Permission Regeln]]'''
* generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
* hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
* forbidden ''(act,error,params)'' Zugriff generell verbieten

'''[[Button Regeln]]'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''[[Label Regeln]]'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

Font-awesome

2012-12-19T08:24:23Z

Netzmacht: Die Seite wurde neu angelegt: „Kategorie:Extensions {{ExtInfo | Dev=David Molineus http://www.netzmacht.de | ExtVersion=2.1.0-rc3 | Version=3.0.0 - 3.0.1 | ERLink=https://contao.org/de/exte…“

[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=2.1.0-rc3
| Version=3.0.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/font-awesome.html
| TrackerLink=https://github.com/dmolineus/contao-font-awesome
}}

=Allgemeines=
Die Erweiterung font-awesome bindet die Iconschriftart Font-Awesome[http://fortawesome.github.com/Font-Awesome/] in Contao ein. Nach der Installation befindet sich unter /assets/ der Ordner font-awesome. Die grundsätzlichen Vorteile von Iconschriftarten sind unter anderen hier[http://die-netzialisten.de/webdesign/klein-und-scharf-iconfonts/] beschrieben.

Außerdem integriert diese Erweiterung die Icons in das Backend von Contao. Dazu muss dies entweder unter System -> Einstellungen -> Backendeinstellungen "Font Awesome systemweit verwenden" aktiviert werden. Ist dies nicht systemweit aktiviert, so kann dies unter den Benutzereinstellungen unter Backend-Theme individuell aktiviert werden.

Die Ersetzung der Standardicons arbeitet sowohl im serverseitig als auch clientseitig mit Javascript. Aktuell werden lediglich die Navigationsicons serverseitig ersetzt.

=Font-Awesome in eigenen Erweiterungen=

==Icons registrieren==
Die Erweiterung bietet eine allgemeine Schnittstelle, sodass andere Erweiterungen ihre Icons registrieren können. Diese werden in der Konfigurationsvariable $GLOBALS['ICON_REPLACER'] gespeichert. Es werden fünf verschiedene Bereiche definiert, in denen Icons ersetzt werden können:

<source lang="php">
$GLOBALS['ICON_REPLACER']['header'] = array(); // Icons im Header, wie das Refresh oder User Icon
$GLOBALS['ICON_REPLACER']['buttons'] = array(); // Icons innerhalb von .tl_buttons (globale Operationen)
$GLOBALS['ICON_REPLACER']['context'] = array(); // Icons die zeilenweise ausgegeben werden (innerhalb von .tl_*_right*)
$GLOBALS['ICON_REPLACER']['pushided'] = array(); // Navigationsicons
$GLOBALS['ICON_REPLACER']['navigation'] = array(); // Icons der Backendmodule in der linken Navigation
</source>

Da Contao Icons entweder als CSS-Klasse definiert oder als Bilddatei lädt, existieren zwei Möglichkeiten die zu ersetzenden Icons zu definieren. In einem Array wird dann das neue Icon (Font-Awesome verwendet die Syntax icon-name, wobei lediglich name angegeben werden muss) und die zu ersetzende CSS-Klasse bzw. der zu ersetzende Dateiname:

<source lang="php">
$GLOBALS['ICON_REPLACER']['context']['imageIcons'][] = array('pencil', 'edit.gif');
$GLOBALS['ICON_REPLACER']['navigation']['styleIcons'][] = array('pencil', 'article');
</source>

An einem konkreten Beispiel der Cloud API Erweiterung sieht dies dann folgendermaßen in der config.php aus:

<source lang="php">
$GLOBALS['ICON_REPLACER']['navigation']['styleIcons'][] = array('cloud', 'cloudapi');
$GLOBALS['ICON_REPLACER']['context']['imageIcons'][] = array('refresh', 'sync.gif');
$GLOBALS['ICON_REPLACER']['buttons']['styleIcons'][] = array('retweet', 'header_mount');
$GLOBALS['ICON_REPLACER']['context']['imageIcons'][] = array('folder-open', 'mount.png');
</source>

==Font-Awesome erzwingen==

Neben der nutzerseitigen Konfiguration kann eine Erweiterung auch die Verwendung von Font-Awesome erzwingen. Dies ist beispielsweise bei einer Backend-Theme sinnvoll, das auf dem Iconset basiert. Dazu muss in der config.php der Erweiterung lediglich die entsprechende Variable konfiguriert werden. Die Benutzer- und Systemeinstellungen werden dann ignoriert. Die Benutzereinstellungen werden dann außerdem versteckt:

<source lang="php">
$GLOBALS['TL_CONFIG']['forceFontAwesome'] = true;
</source>

Dca-rules

2012-12-19T07:53:19Z

Netzmacht: Anpassungen für Version 1.0.0-rc2

[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc2
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung. Bei den Button Callbacks handelt es sich um magische Callbacks, die um den Buttonnamen ergänzt werden müssen. Dies ist erforderlich, damit der allgemeine Callback nur bei dem entsprechenden Button ausgeführt wird.

* checkPermission
* generateButton*
* generateGlobalButton*
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
$rule = array('rule:error=&.errors.1'); // accessing language vars of current table
$rule = array('rule:error=&MSC.yes'); // accessing language var $GLOBALS['TL_LANG']['MSC']['yes']
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array
(
'isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit'
);
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonEdit'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonMember'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButtonDelete'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben:

'''Permission Regeln'''
* generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
* hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
* forbidden ''(act,error,params)'' Zugriff generell verbieten

'''Button Regeln'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''Label Regeln'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

Dca-rules

2012-12-18T15:34:03Z

Netzmacht: /* Button Regeln */

[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc1
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung:

* checkPermission
* generateButton
* generateGlobalButton
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array
(
'isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit'
);
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben:

'''Permission Regeln'''
* generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
* hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
* forbidden ''(act,error,params)'' Zugriff generell verbieten

'''Button Regeln'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''Label Regeln'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

=Identifizierung von Buttons=

Zu guter Letzt noch ein Hinweis zur Identifizierung der Buttons. Damit die Regeln nur bei dem entsprechenden Button ausgeführt werden, muss dieser identifiziert werden. Normalerweise wird dafür das icon Attribute verwendet. Kommt es vor, dass mehrere Buttons (der jeweiligen Kategorie operations bzw. global_operations) das gleiche icon verwenden, muss zusätzlich eine id zugewiesen werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['edit']['id'] = 'edit';
</source>

Dca-rules

2012-12-18T15:32:29Z

Netzmacht: /* Label Regeln */

Dca-rules

2012-12-18T15:28:58Z

Netzmacht: /* Label Regeln */

Dca-rules

2012-12-18T15:28:16Z

Netzmacht: /* Permission Regeln */

Dca-rules

2012-12-18T15:26:45Z

Netzmacht: Formatierungen

[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc1
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

=Vorgehensweise ohne dca-rules=

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

==Aufbau der tl_feedback==

Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

==Benötigte Operationen==

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

==DataContainer Klasse==

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>

=Vorgehensweise mit dca-rules=

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

==Verwendung der vordefinierten Callbacks==
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung:

* checkPermission
* generateButton
* generateGlobalButton
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

==Verwendung von Regeln==

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
</source>

==Permission Regeln==

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit');
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

==Button Regeln==

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

==Label Regeln==

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

=Vorhandene Regeln=
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben:

'''Permission Regeln'''
* generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
* hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
* forbidden ''(act,error,params)'' Zugriff generell verbieten

'''Button Regeln'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''Label Regeln'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

=Eigene Regeln definieren=

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

=Identifizierung von Buttons=

Zu guter Letzt noch ein Hinweis zur Identifizierung der Buttons. Damit die Regeln nur bei dem entsprechenden Button ausgeführt werden, muss dieser identifiziert werden. Normalerweise wird dafür das icon Attribute verwendet. Kommt es vor, dass mehrere Buttons (der jeweiligen Kategorie operations bzw. global_operations) das gleiche icon verwenden, muss zusätzlich eine id zugewiesen werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['edit']['id'] = 'edit';
</source>

Dca-rules

2012-12-18T13:48:42Z

Netzmacht: Die Seite wurde neu angelegt: „Kategorie:Extensions {{ExtInfo | Dev=David Molineus http://www.netzmacht.de | ExtVersion=1.0.0-rc1 | Version=2.11.0 - 3.0.1 | ERLink=https://contao.org/de/ext…“

[[Kategorie:Extensions]]
{{ExtInfo
| Dev=David Molineus http://www.netzmacht.de
| ExtVersion=1.0.0-rc1
| Version=2.11.0 - 3.0.1
| ERLink=https://contao.org/de/extension-list/view/dca-rules.html
| TrackerLink=https://github.com/dmolineus/dca-rules/
}}

=Allgemeines=

Die Erweiterung '''dca-rules''' ist als Hilfswerkzeug für die Entwicklung von DataContainern konzipiert. Es stellt allgemeine Callbacks für die Generierung von Operationen, Global Operationen, für die Rechteüberprüfung sowie der Ausgabe der Labeln in der Listenansicht. Diese können mit Regeln konfiguriert werden, sodass diese über die DCA-Dateien erstellt werden können ohne neue Callbacks zu definieren. Damit wird die Erzeugung redundanter Callbacks bei der Entwicklung von DataContainern reduziert.

==Vorgehensweise ohne dca-rules==

Um den Einsatz von den DCA-Regeln zu verdeutlichen, soll hier ein Beispiel erläutert werden. Es ist eine Erweiterung geplant, die es angemeldeten Benutzern im Frontend ermöglicht, Artikel mit Rückmeldungen zu versehen, z.B. dass sie eine Überarbeitung benötigen. Diese sollen dem Nutzer zugeordnet werden und von Redakteuren im Backend bearbeitet werden können. Backend-Redakteure ohne Bearbeitungsrechte sollen, die Feedbacks einsehen können. Hat der Benutzer Zugriff aus das Member Modul, soll außerdem ein Button zum entsprechenden Benutzer angezeigt werden. Gelöscht werden sollen die Feedbacks hingegen nur vom Administrator.

===Aufbau der tl_feedback===
Man erstellt also einen DataContainer ''tl_feedback.php'', der die entsprechenden Felder ''id, pid, tstamp, created, memberid, userid, status, type, message'' beinhaltet. Pid ist hierbei die ID der Artikel, memberid die ID des Nutzers, der das Feedback abgegeben hat, userid die ID des bearbeiteten Benutzers. Außerdem wird in created die Timestamp gespeichert, als das Feedback abgegeben wurde, während tstamp bei jeder Änderung aktualisiert wird.

===Benötigte Operationen===

Nach den Anforderungen, müssen folgende Operationen erstellt werden:

* Feedback bearbeiten (wenn Rechte vorhanden)
* Benutzer anzeigen (wenn Zugriff aus Modul member)
* Feedback löschen (nur Admin)
* Feedback anzeigen (alle Benutzer mit Zugriff auf Modul)

Dies bedeutet außerdem, dass die Zugriffsrechte überprüft werden müssen:

* Bearbeiten nur Redakteure mit Lösch-Rechten
* Löschen Aktion nur Administrator

===DataContainer Klasse===

Nach dem gewöhnlichen Weg, würde man jetzt für die Buttons edit, member, delete Callbacks definieren, sowie einen onload_callback checkPermission, welches die Zugriffsrechte überprüft. Im unten dargestellten Code-Beispiel ist dies kurz verdeutlicht. Das Problem hierbei ist, dass man immer wieder die gleichen Callbacks definiert, sobald die Zugriffsrechte mal eingeschränkt sind.

<source lang="php">
class Feedback extends Backend
{
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function checkPermission()
{
$act = \Input::get('act');
if(($act == 'delete' || $act == 'deletAll') && !$this->user->isAdmin)
{
$this->log('Hacking attempt');
$this->redirect('contao/main.php?act=error');
}

// check user permission ...
}

public function generateDeleteButton($arrRow, $strHref, $strLabel, $strTitle, $strIcon, $strAttributes)
{
if(!$this->User->isAdmin)
{
return '';
}

return '<a href="">....</a>';
}
}
</source>
==Vorgehensweise mit dca-rules==

An dieser Stelle setzt '''dca-rules''' an und bietet eine leicht zu konfigurierbare Schnittstelle, die solche Aufgaben löst. Außerdem ist sie leicht erweiterbar, sodass selbst bei komplexeren Beispielen immer noch auf die Regeln zurückgegriffen werden kann.

===Verwendung der vordefinierten Callbacks===
Daher bietet die Erweiterung vordefinierte Callbacks, die anstelle der neu entwickelten aufgerufen werden. Zusätzlich werden diese noch mit Regeln definiert. Zur Zeit stehen folgende Callbacks zur Verfügung:

* checkPermission
* generateButton
* generateGlobalButton
* generateLabel

Damit diese verwendet werden können, muss die DataContainer Klasse die mitgelieferte Klasse Netzmacht\Utils\DataContainer erweitern. Diese basiert selbst auf der Backend Klasse. Außerdem benötigt sie den Namen der Tabelle. Dieser kann automatisch generiert werden, wenn die erstellte Klassen der Namenskonvention folgt. Aus der Tabelle tl_feedback wird der DataContainer Feedback. Entscheidet man sich für einen anderen Namen, muss lediglich die Variable $strTable definiert werden:

<source lang="php">
class Feedback extends Netzmacht\Utils\DataContainer
{
// protected $strTable = 'tl_feedback';
}
</source>

Wird nun der DataContainer verwendet, können die mitgelieferten Callbacks wie gewohnt in der DCA-Datei definiert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['onload_callback'][] = array('Feedback', 'checkPermission');
</source>

===Verwendung von Regeln===

Neben den Callbacks werden nun die Regeln definiert. Diese werden in folgenden Variablen gespeichert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array(); // Regeln für checkPermission
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['button']['button_rules'] = array(); // Regeln für generateButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['gobal_operation']['button']['button_rules'] = array(); // Regeln für generateGlobalButton
$GLOBALS['TL_DCA']['tl_feedback']['list']['label']['label_rules'] = array(); // Regeln für generateLabel
</source>

Anhand des oben genannten Beispiels definieren wir zwei Regeln zur Rechteüberprüfung. Zum einem verwenden wir hasAccess um den Zugriffsrechte für die Bearbeiten Funktion zu überprüfen, sowie isAdmin um die LöschFunktionen einzugrenzen.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin', 'hasAccess');
</source>

Dies würde allerdings dazu führen, dass die isAdmin Regel auf alle Aktionen angewandt wird. Sprich das Modul wäre nur für Administratoren nutzbar. Daher bietet dca-rules eine Möglichkeit Attribute zu definieren. Dabei wird folgende Syntax verwendet:

<source lang="php">
$rule = array('rule:attribute'); // setzt attribute=true
$rule = array('rule:attribute=2'); // setzt attribute=2. Boolean und Numeric werden entsprechend konvertiert
$rule = array('rule:attribute=$value'); // Zugriff auf eine in der Feedback definierte Variable $this->value
$rule = array('rule:attribute=[one,two,three]'); // Ein Array array('one', 'two', 'three')
$rule = array('rule:attribute=[true,2,false,$value,2.3, 'hallo']'); // Werte des Array werden ebenso konvertiert: array(true, 2, false, $this->value, 2.3, 'hallo');
$rule = array('rule:a=2:b=3:c:4'); // Mehrere Attribute können durch einen Doppelpunkt getrennt werden
</source>

===Permission Regeln===

Die Permission Rules bieten alle die Möglichkeit über das act Attribute die Regel nur auf die definierten Aktionen anzuwenden. Dabei können diese als Arrray definiert werden. Demzufolge erweitert man das obige Beispiel. Außerdem soll überorpft werden, ob der Benutzer Zugriff aus das Modul hat. Daher übergeben wir den Modulnamen:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback');
</source>

Dadurch sind die Einschränkungen schon recht weit umgesetzt. Allerdings bekämen jetzt alle Redakteure Zugriff die Beabeiten-Funktion. Um diese einzuschränken, wendet man nochmals die Regel hasAccess die mit den Attributen permission und action beliebige BackendUser::hasAccess(action, permission)
Überprüfungen machen kann. Diese nuss natürlich vorher auch in der tl_user(_group) und über TL_PERMISSION definiert werden. Das soll an dieser Stelle nicht näher behandelt werden. Es wird davon ausgegangen, dass der Zugriff feedback mit dem Wert edit definiert ist. Die Regel hasAccess wird nun nur auf die Aktionen edit und editAll angewandt:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['config']['permission_rules'] = array('isAdmin:act=[delete,deleteAll]', 'hasAccess:module=feedback', 'hasAccess:act=[edit,editAll]:permission=feedback:action=edit');
</source>

Das ist alles! Damit hat man in einer Zeile in der DCA-Datei die Rechteüberprüfung vorgenommen.

===Button Regeln===

Das gleiche Prinzip wird bei den Button-Regeln angewandt. Diese folgen der gleichen Syntax und dem gleichen Prinzip wie die Permission Regeln. Allerdings benötigen sie noch die Regel generate, die zur Ausgabe dient. Diese muss mit angegeben werden, was den Vorteil hat, das man auch nach der Ausgabe noch Manipulationen vornehmen kann. Doch weiter an dem genannten Beispiel mit den Buttons edit,member,delete,show.

Wie bei der Rechteübergabe, werden die Regeln nun definiert. Wichtigste Helfer, sind hierbei auch wieder die Regeln isAdmin sowie hasAccess. Die Konfigurationen de Buttons sind unten aufgeführt. den show Button muss man nicht definieren, da ja die Zugriffsbeschränkung mit dem Zugriff des Modules bereits erreicht ist.

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['edit'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('hasAccess:permission=feedback:action=edit', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['member'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('hasAccess:module=member', 'generate'),
);

$GLOBALS['TL_DCA']['tl_feedback']['list']['operations']['delete'] = array
(
// normale button konfiguration, zusätzlich
'button_callback' => array('Feedback', 'generateButton'),
'button_rules' => array('isAdmin', 'generate'),
);
</source>

===Label Regeln===

Die Label Regeln dienen dazu die Aufgabe der einzelnen Felder zu bestimmen. Sie dienen dazu einzelne Werte der Ausgabe anders zu formatieren. An dem oben genannten Beispiel gibt es die Spalte created. Die Übersicht soll im mode=1 erfolgen. Dabei wird der Timestamp nicht konvertiert. Dies erledigt Contao nur bei der tstamp Spalte automatisch. Außerdem soll ausgegeben werden, ob das Feedback bereits einem bearbeitenden Nutzer zugewiesen wurde. Hierbei soll lediglich ja/nein und nicht der Beutzername ausgegeben werden. Für beide Fälle bringt dca-rules wieder Regeln mit. Während alle anderen Regeln immer einen Abbruch der Überprüfung erreichen können, werden die LabelRegeln immer durchgeführt.

Diese werden folgendermaßen konfiguriert:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'fields' => array('id', 'created', 'userid'),
'showColumns' => true,
'label_callback' => array('Feedback', 'generateLabel'),
'label_rules' => array(),
);
</source>

Wir erzeugen also eine Listenansicht, die tabellarisch ausgegeben wird mit den Spalten id, created und userid. Statt der Userid werden wir eine ja/nein ausgabe machen. Auch hier wird der bereits vorhandene Callback aufgerufen.

Was man bei den Regeln für Label beachten muss, dass die Werte von Contao in einem Array $values nach dem Index der oben aufgelisteten Felder überliefert bekommt. in $vlaues[0] steht also die ID, nd $values[1] der Timestamp usw. Dazu gibt es auch ein Array mit den unbearbeiten Werten $row['id']. Manchmal konvertiert Contao den Wert bereits in eine Ausgabe. Beispielsweise bei einen Boolean Wert. So wird hier entweder ein - für eine leere Angabe, oder die Spaltenbezeichnung angegeben. Aus diesem Grund verwenden die Label Regeln sowohl ein Attribute index wie auch field, um zwischen den beiden Werten wählen zu können. Der Index ist immer erforderlich, da er die Position der Ausgabe entscheidet.

Für den hier beschriebenen Fall stehen zwei Regeln zur Verfügung: parseDate und yesNo. Dabei wird der yesNo Regel sowohl der Index als auch das Feld übergeben. Das Feld wird dann anhand des Attributes condition überprüft. Da "ja" ausgeben werden soll, wenn der Wert > 0 ist, muss die Überprüfung noch auf false gesetzt werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['label'] = array
(
'label_rules' => array('parseDate:index=1', 'yesNo:index=2:field=created:condition=0:is=false'),
);
</source>

Dadurch könenn wir so gut wie alle Aktionen der Tabelle lösen '''ohne''' einen einzigen Callback geschrieben zu haben!

==Vorhandene Regeln==
Nachdem anhand des Beispiels die Funktionsweise erläutert wurde, gibt es hier eine Übersicht der bereits vordefinierten Regeln. Dabei sind in der Klammer die möglichen Attribute angegeben:

'''Permission Regeln'''
generic ''(act,error,params)'' Als Basis aller anderen Regeln, erlaubt Einschränkung auf params und individuelle Logmeldungen
hasAccess ''(isAdmin,module,permission,action,alexf,fop,act,error,params)'' Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
isAllowed ''(operation,table,closed,ptable,pid,where,value,act,error,params)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
isAdmin ''(act,error,params)'' überprüft ob Benuter Admin ist
forbidden ''(act,error,params)'' Zugriff generell verbieten

'''Button Regeln'''
* toggleIcon ''(table, field, icon)'': erzeugt ein Icon zum Aktivieren/Deaktivieren
* referer: erzeugt ein Zurück Link
* hasAccess ''(isAdmin,module,permission,action,alexf,fop): Zur Überprüfung der Berechtigungen mittels BckendUser::hasAccess
* isAllowed ''(operation,table,closed,ptable,pid,where,value)'' Zur Überprüfung von Aktionen mittels BackendUser::isAllowed
* isAdmin: überprüft ob Benuter Admin ist

'''Label Regeln'''
* parseDate ''(index,field,format='' einen Timestamp parsen
* yesNo ''(index,field,codition,is)'' ja/nein ausgeben

==Eigene Regeln definieren==

Neben den vordefinierten Regeln können auch eigene Regeln definiert werden. Diese werden als Methoden in dem DataContainer definiert und folgen folgenden Konventionen. Die Button Regeln werden sowohl für die globale als auch lokale Buttons verwendet. Bei globalen ist $arrRow=null.

<source lang="php">
protected function permissionRule*($objDc, &$arrAttributes, &$strError);
protected function buttonRule*(&$strButton, &$strHref, &$strLabel, &$strTitle, &$strIcon, &$strAttributes, &$arrAttributes, $arrRow=null);
protected function labelRule*(&$arrRow, &$strLabel, &$objDc, &$arrValues, &$arrAttributes);
</source>

==Identifizierung von Buttons==

Zu guter Letzt noch ein Hinweis zur Identifizierung der Buttons. Damit die Regeln nur bei dem entsprechenden Button ausgeführt werden, muss dieser identifiziert werden. Normalerweise wird dafür das icon Attribute verwendet. Kommt es vor, dass mehrere Buttons (der jeweiligen Kategorie operations bzw. global_operations) das gleiche icon verwenden, muss zusätzlich eine id zugewiesen werden:

<source lang="php">
$GLOBALS['TL_DCA']['tl_feedback']['list']['operation']['edit']['id'] = 'edit';
</source>