Funktioniert so nur wenn die Parameter Elemente für sich eine Tabellenspalte nutzen und die übergebenen Daten ein Array oder ein Objekt sind, wie zum Beispiel:
Code:
Array('id' => 42, 'title' => 'title', 'published' => 1);
id | title | published | ...
da hier die $table->bind(); Methode greifen kann.
Bei normaler Verwendung von Parametern werden diese allerdings als "Gruppe" gerendert. Man könnte es "Scope" nennen und sollte nicht mit der Gruppe verwechselt werden die über den group="" Switch im Manifest angegeben werden kann.
Die interne JTable::bind(); Methode weiß nicht wann es sich um Parameter handelt (die als String gespeichert werden müssen) und wann nicht. Hier würde fälschlicherweise versucht werden das Array in die "params" Spalte zu schreiben.
Abhilfe schafft JRegistry::toString();
Die Zuweisung / Umwandlung wird oft im Controller vorgenommen, angedacht war / ist dafür allerdings das Überschreiben der bind Methode in einer eigenen JTable Klasse.
Beispiel:
PHP-Code:
function bind($array, $ignore = '')
{
if (key_exists( 'params', $array ) && is_array( $array['params'] ))
{
$registry = new JRegistry();
$registry->loadArray($array['params']);
$array['params'] = $registry->toString();
}
return parent::bind($array, $ignore);
}
Keen observers might say: "Die Parameter werden automatisch gerendert und gespeichert wenn man sie über:
Code:
JToolbar::JToolBarHelper::preferences('your_component_xml_file', 'height');
aufruft."
Das ist richtig und ziemlich alle Core-Erweiterungen machen es so. Wer sich nun aber die Parameter Liste der Artikel anschaut kann sich vorstellen, dass diese Liste recht lang werden kann und es nur bedingt möglich ist diese optisch besonders anzupassen.
Ein "gutes" Beispiel ist hier die Ignite Gallery. Bei vielen Parametern tut man gut daran eine eigene View dafür einzuplanen.
http://docs.joomla.org/Component_parameters
Lesezeichen