Nutzt man den EP YFORM_DATA_LIST_QUERY und passt unter bestimmten Umständen (bspw. das kein sort-Param gesetzt ist) den Query an, hat man ein Problem: Der angepasst Query ändert den im Konstruktor der Klasse rex_yform_list automatisch gesetzten List-Name.
Wenn man dann auf eine Sortierspalte klickt, ist der list-Param im Link quasi falsch. Das Sorting hat dann keine Auswirkung, weil danach der Query wieder zurücksetzt wird. Das ist unglücklich und kann im aktuellen Code meines Erachtens nach nicht sinnvoll über EPs angepasst werden. Man müsste via OUPUT_FILTER die Links der sortierbaren Spaltenköpfe umschreiben - kein Spaß und wenig praktikabel.
Was da hilft ist ein Setter für den Listen-Namen, dann kann man - z.B. im EP YFORM_DATA_LIST den falschen List-Name mit dem richtigen überschreiben und löst so besagtes Problem. Außerdem ist rex_yform_list ohnehin eine ganz eigene rex_list-angelehnte Variante, wo das Erweitern wenig Potential für unvorhergesehene Seiteneffekte haben dürfte.
Das Bsp.-Szenario hier mal skizziert:
In der boot.php eines AddOns möchte ich die Standard-Sortierung - also wenn kein custom Sorting ausgeführt wurde - für eine bestimmte Tabelle überschreiben.
Wenn der BE-User dann doch umsortiert, soll diese Anpassung natürlich nicht mehr greifen (sonst wären die Sort-Links ja ohne Mehrwert an der Stelle)
nutzt neuen Setter setName()
// nur BE und nur bestimmte Table
if(rex::isBackend() && rex_request('table_name') == 'rex_companies') {
$beUser = rex::requireUser();
// change default order for BE users: own companies first, then all others
if(rex_request("sort") == "" || rex_request("sort") == "name") {
rex_extension::register('YFORM_DATA_LIST_QUERY', function(rex_extension_point $ep) use ($beUser) {
/** @var $subject rex_yform_manager_query */
$subject = $ep->getSubject();
// get list name without sql adjustments
$listBefore = rex_list::factory($subject->getQuery());
// store it here to set it back in YFORM_DATA_LIST extension point
rex::setProperty(rex_request('table_name').'_list_name_original', $listBefore->getName());
$subject->orderByRaw("
IF (
`t0`.`createuser` != 0 AND
`t0`.`createuser` IS NOT NULL AND
`t0`.`createuser` = '".$beUser->getId()."',
1,
2
) ASC,
`t0`.`name`
", rex_request('sorttype', 'string', 'ASC'));
$ep->setSubject($subject);
});
// set back correct list name
rex_extension::register('YFORM_DATA_LIST', function(rex_extension_point $ep) {
/** @var $list rex_yform_list */
$list = $ep->getSubject();
if(($originalListName = rex::getProperty(rex_request('table_name').'_list_name_original')) != null) {
$list->setName($originalListName);
}
return $list;
});
}
}
Nutzt man den EP
YFORM_DATA_LIST_QUERY
und passt unter bestimmten Umständen (bspw. das keinsort
-Param gesetzt ist) den Query an, hat man ein Problem: Der angepasst Query ändert den im Konstruktor der Klasserex_yform_list
automatisch gesetzten List-Name.Wenn man dann auf eine Sortierspalte klickt, ist der
list
-Param im Link quasi falsch. Das Sorting hat dann keine Auswirkung, weil danach der Query wieder zurücksetzt wird. Das ist unglücklich und kann im aktuellen Code meines Erachtens nach nicht sinnvoll über EPs angepasst werden. Man müsste via OUPUT_FILTER die Links der sortierbaren Spaltenköpfe umschreiben - kein Spaß und wenig praktikabel.Was da hilft ist ein Setter für den Listen-Namen, dann kann man - z.B. im EP
YFORM_DATA_LIST
den falschen List-Name mit dem richtigen überschreiben und löst so besagtes Problem. Außerdem ist rex_yform_list ohnehin eine ganz eigene rex_list-angelehnte Variante, wo das Erweitern wenig Potential für unvorhergesehene Seiteneffekte haben dürfte.Das Bsp.-Szenario hier mal skizziert:
setName()