Berechnung eines Tagespreises für das Sortieren einer Angebotsliste

[eblick]

Für ein Listenmodul wird eine Sortierung nach Tagespreis benötigt. Dieser Tagespreis wird allerdings nicht im Katalog erfasst sondern soll berechnet werden:

Gegeben:
- Angebotspreis für mehrere Tage
- Anzahl Tage

Der Tagespreis (Angebotspreis ./. Tage) soll beispielsweise für die Sortierung genutzt werden.
Wie kann dieser zum Inhaltselement als automatisch berechnendes Feld hinzugefügt werden oder alternativ auch im Modul über die SQL-Bedingung berechnetet werden?

[Tim]

Nagut, per SQL Bedingung kannst du natürlich im SQL Handbuch mal die mathematischen Möglichkeiten nachschlagen. Selbst im ORDER BY geht ein SELECT und damit auch auch math. Berechnungen.

Im Backend kann man sowas über den save_callback eines Feldes realisieren. Darin würde man halt aus den anderen zwei Feldern die Summe bilden.

[eblick]

Über SQL-Bedingung funktioniert es tadellos.

Einziges Problem: Wenn ich auf der Seite einen Filter mit [mehreren] Sortieroptionen für den Benutzer anlege, funktioniert dieser (wohl aufgrund der SQL-Default Sortierung) nicht.
Es scheint, dass sich grundsätzlich mehrere Sortieroptionen untereinander ausschließen.
Beispiel:

Default Sortierung -> Angebotspreis pro Tag

Option für Benutzer:

1. Sortierung nach Gesamtpreis
2. Sortierung nach Anzahl Tage

Im Frontend wird nur sortiert, wenn es lediglich ein einziges Sortierfeld gibt.

Kann das jemand verifizieren und bestätigen?

[Tim]

die SQL Sortierung hat die oberste Macht, die killt wirklich alle anderen Sortierungen.
Sortierungen, die über einen Filter kommen, werden quasi addiert.

Wenn es richtig komplex werden soll, gibts auch hier genug Hooks um noch vor der Ausgabe den SQL Query komplett zu manipulieren. Dann geht imgrunde alles

[eblick]

die SQL Sortierung hat die oberste Macht, die killt wirklich alle anderen Sortierungen.
Sortierungen, die über einen Filter kommen, werden quasi addiert.

Das erklärt aber noch nicht, warum nicht mehr als eine Sortieroption im FE funktioniert.
Der Besucher soll auswählen zwischen dem Sortieren nach Preis oder nach Anzahl Tage. Diese Sortierfilter sind in einem Filterset zusammen. Es funktioniert aber nur das erste.

Wenn es richtig komplex werden soll, gibts auch hier genug Hooks um noch vor der Ausgabe den SQL Query komplett zu manipulieren. Dann geht imgrunde alles

So richtig "komplex" ist doch die Anforderung nicht?!

Eine Liste muss eine initiale Sortierreihenfolge haben (vom Redakteur festgelegt).

Anschließend soll der Besucher diese durch seine eigene Sortierauswahl überschreiben können (auch eine etwaige SQL-Sortierung).
Ich bin der Ansicht, dass dies über die Modul-Konfiguration des CC möglich sein sollte, ohne Hooks und dergleichen, da dies einen wesentlichen Use Case darstellt.

[Tim]

Anschließend soll der Besucher diese durch seine eigene Sortierauswahl überschreiben können (auch eine etwaige SQL-Sortierung).
Ich bin der Ansicht, dass dies über die Modul-Konfiguration des CC möglich sein sollte, ohne Hooks und dergleichen, da dies einen wesentlichen Use Case darstellt.

So ist es, dafür gibt es Sortierungsfilter.


ps. die Standardsortierung wird zurückgesetzt, wenn ein aktiver Sortierungsfilter läuft und greift dann wieder, wenn keiner da ist.

[Tim]

Nachtrag
Ich musste jetzt selbst im Code blättern. Also, das Feld tl_module.customcatalog_sqlSorting wird als Sorting addiert. Es überschreibt also nicht die anderen Sortings.
Das Feld tl_module.customcatalog_sqlWhere, wird ebenfalls hinzugefügt. Es überschreibt also auch nicht etwailige WHERE Bedingungen.
Doppelte Sortierungen, Sortierungen gleichen Feldes werden allerdings aufgelöst.

Hat man also eine Sorting auf feldA als Standard oder Custom Sortierung und sortiert später über einen Filter, gilt der Filter. Sonst würde man keine Änderungen sehen.
Das Sorting wird nur strikt gesetzt, wenn es von ausserhalb strikt gesetzt wird über die CC->setSorting(...) Methode zum Beispiel. Dann ist davon auszugehen, dass dieses Sorting absoluten Vorrang haben soll.
CC->addSorting(...) ergänzt Sortings.

[eblick]

Ok, und nun nochmal bitte für die Pragmatiker unter uns...

Ist die Konfiguration, die ich oben beschrieben habe nun richtig und sollte funktionieren oder nicht??

Default Sortierung -> über SQL Filter bei Seitenaufruf.

Änderung der Sortierung im Frontend über zwei Filter:
Frontend Sortierungsoptionen -> Entweder Feld A oder Feld B

[Tim]

Alles wird ergänzt.
Lass Dir den SQL Query deines CC mal loggen. Dann siehst du genau wie der finale Orderby Bereich ausschaut:

localconfig.php:
$GLOBALS['PCT_CUSTOMCATALOG']['debug'] = true;

Damit werden die sql queries im Systemlog ausgeschrieben beim Aufruf eines CC.

Haste Dir das mal durchgelesen: http://forum.premium-contao-themes.c...end-sortierung

[Tim]

So, habe es jetzt nach gebaut. CC ergänzt. Damit bleiben Sortierungen jedweder Art erhalten.
Da hast du schon recht, jetzt bleibt halt jede Sortierung erhalten und es wird ergänzt. Das kann ungewünscht sein (aber eben auch nicht )

Jetzt wird es aber sehr projektspezifisch.
Der eine will, dass seine eigene SQL Sortierung oder Sortierfeld existent bleibt und FE Sortierungen per Filter ergänzt werden. Der andere (Dein Projekt gerade) will das nicht.

Ich kann hier maximal eine Globale ergänzen, die strikt sagt: Wenn FE Sortierungen, dann kille alle Standards / manuelle Sortierungen.

Andere Wege sind über das eigene Template Filterungen "resetten". Siehe den Post oben zwischen Tim und mir. Er resettet quasi über setGet bzw. setzt erst eine Standardsortierung, wenn keine Sortierung aktiv ist.

Der nächste alternative Weg ist in der Tat sich einen kleinen Hook ergänzen, der vor dem sql Query gefeuert wird. Das wäre der:

prepareCatalogHook

Darin wird das gesamte SQL Builder Array übergeben, ausdem sich die SQL Abfrage aufbaut.

--
Ich gebe das mal noch hier zu Diskussion. Das Theme ist ja interessant.
https://github.com/premiumcontaothem...talog/issues/9

[eblick]

Ja es ist wie oben beschrieben.
Wenn die Default Sortierung über das vorhandene Sortierfeld erstellt wird, funktioniert das überschreiben, auch durch mehrere Sortieroptionen.

Die SQL-Sortierung bleibt in meinen Fall immer bestehen und weitere Sortierung wird ergänzt.
Damit eignet sich die SQL-Default Methode nicht, wenn man später den Besucher eigene Sortierung anbieten will.

SELECT kk_angebote.* FROM kk_angebote WHERE kk_angebote.veroeffentlichen='1' ORDER BY (angebotspreis/anzahl_uebernachtungen) ,kk_angebote.angebotspreis+0 DESC LIMIT 0,10

Daher wird wohl ein automatisch erzeugtes Feld per save_callback für diesen Fall erforderlich um das Feld anschließend im Modul über das Sortfield zu verwenden.

[Tim]

Ein gesetztes Sortierfeld bleibt ebenfalls existend. Es kann lediglich dann durch einen eigenen FE-Sortierungsfilter umgesetzt werden. Da hast du recht.

Aber einen save_callback setzen ist aus meiner Sicht fehlerbehafter als CC vor dem sql query zu modifizieren per Hook. (save_callback und Hook ist imgrunde das gleiche vom Aufwand)
-> das ist auch sehr projektspezifisch und erforder halt ein neues Feld in der DB. Eigentlich bissel overkill.

[Tim]

Ich würds so machen, wenn ich es für ein Projekt brauche:

Hier wird im Hook die manuellen Sortierungen ausradiert, wenn Filter aktiv sind.

/**
     * Reset my custom sortings when a fe sorting filter is active
     * called by: $GLOBALS['CUSTOMCATALOG_HOOKS']['prepareCatalog'] Hook
     * @param array        Current SQL Builder array
     * @param object    Current CustomCatalog object
     * @return array    SQL Builder array
     */
    public function resetMyCustomSortings($arrOptions,$objCC)
    {
        $arrActiveFilters = $objCC->getActiveFilters();
        if(count($arrActiveFilters) < 1 && $arrOptions['order'] != '')
        {
            return $arrOptions;
        }
        
        // module (list or reader)
        $objModule = $objCC->getModel();
        
        $strOrder = $arrOptions['order'];
        
        // strip default sorting
        if($objModule->customcatalog_sortField)
        {
            $strSortField = $objCC->getTable().'.'.$objModule->customcatalog_sortField.' '. strtoupper($objModule->customcatalog_sorting);
            
            $strOrder = str_replace($strSortField,'',$strOrder);
        }
        
        // strip custom sql Sortings
        $strOrder = str_replace($objCC->getTable().'.'.\String::decodeEntities($objModule->customcatalog_sqlSorting),'',$strOrder);
        
        // rebuild order string
        $arrOrder = array_filter(array_map('trim',explode(',', $strOrder)),'strlen');
        
        $arrOptions['order'] = implode(',', $arrOrder);
        
        return $arrOptions;
    } 

[eblick]

hot stuff, werd's testen!