Listview Objekte Datumsvergleich

[apollo23]

Hallo,

ist es möglich über we:conditionAdd, we:conditionAnd in einer listview-Ausgabe nur diejenigen Objekte anzeigen zu lassen, welche sagen wir mal, nicht älter als 10 Wochen sind?

Man müsste, meiner Idee nach das aktuelle Datum auslesen können und dieses mit dem CreationDate $GLOBALS['we_doc']->CreationDate; des Objektes vergleichen können. Könnte man so eine listview mit webEdition Bordmitteln umsetzen?

Wenn ja, könnte man beim Aufruf solch einer listview gleichzeitig alle Objekte der betreffenden listview Parken, die sich außerhalb der zehn Wochen befinden?

[WBTMagnum]

ist es möglich über we:conditionAdd, we:conditionAnd in einer listview-Ausgabe nur diejenigen Objekte anzeigen zu lassen, welche sagen wir mal, nicht älter als 10 Wochen sind?

Man müsste, meiner Idee nach das aktuelle Datum auslesen können und dieses mit dem CreationDate $GLOBALS['we_doc']->CreationDate; des Objektes vergleichen können. Könnte man so eine listview mit webEdition Bordmitteln umsetzen?

Ich denke schon, dass das möglich ist. Nachdem die Zeitangaben als timestamp gespeichert werden, sollte sich das mit einem einfachen Integer-Vergleich machen lassen. Fertige Lösung habe ich jetzt leider nicht bei der Hand.

Wenn ja, könnte man beim Aufruf solch einer listview gleichzeitig alle Objekte der betreffenden listview Parken, die sich außerhalb der zehn Wochen befinden?

Mit der oben beschriebenen Listview+Condition Lösung ist das nicht möglich, da damit veraltete Einträge ausgeschlossen sind.

Ich sehe hier zwei Alternativen:

1. Eine zweite Listview mit Condition für die veralteten Einträge.
2. Eine Listview ohne Condition. Innerhalb der Listview erfolgt der Datumsvergleich und veraltete Einträge werden geparkt. Hinweis: Hier kann es allerdings zu Problemen mit der Paginierung kommen (sofern du eine verwendest).

HTH,
Sascha

[Carrear]

Hinterliegen Datumsangaben in der DB tatsächlich immernoch als Timestamp? Wirft das keine Probleme bzgl. Daten vor dem 01.01.1970 auf? Ich dachte, das wäre mittlerweile umgestellt.

[WBTMagnum]

Hey Carrear,

Ich habe mir das kurz in der DB angeschaut. Die Daten werden als Unix Timestamp, und somit als leicht vergleichbare Integer-Werte, abgelegt.

Anm.: Technisch gesehen werden die Daten als LONGTEXT gespeichert. Das sollte hier aber nicht relevant sein.

Liebe Grüße,
Sascha

[Carrear]

Und das ist kein Nachteil? Die neuen Date-Funktionen bieten doch ebenfalls eine ganz einfache Vergleichbarkeit von Datumsangaben und man hat nicht die Einschränkung, historische Daten nicht abspeichern zu können.

[WBTMagnum]

Und das ist kein Nachteil? Die neuen Date-Funktionen bieten doch ebenfalls eine ganz einfache Vergleichbarkeit von Datumsangaben und man hat nicht die Einschränkung, historische Daten nicht abspeichern zu können.

Ich habe das Gefühl wir reden hier aneinander vorbei. Von welcher Date-Funktion sprichst du konkret?

LG,
Sascha

[Carrear]

In erster Linie geht es mal darum, dass sich in dieser Form doch keine Daten vor dem 1.1.1970 abspeichern lassen. Richtig oder Falsch?

Darüber hinaus rede ich von allem rund um die DateTime Klasse. Ich kann zwar den Timestamp nehmen und in DateTime konvertieren, aber umgekehrt wirds doch schwierig, wenn ich einen UnixTimestamp habe. Warum sind die Felder in der DB nicht einfach als DateTime angelegt?

[ThomasGoebe]

Warum sind die Felder in der DB nicht einfach als DateTime angelegt?

Weil es ein paar tausend Installationen gibt, die sich noch darauf verlassen (eigener PHP-Code, eigene SQL Abfragen, eigene APIs etc.), dass dort ein Timestamp steht.

Das ist also ein Problem der abwärtskompatibilität.

[Carrear]

Da müssen wir sowieso irgendwann durch. Aufgeschoben ist nicht aufgehoben. Jetzt müssen wir halt fortlaufend mit UnixTimestamps klarkommen und Entwickeln. Das ist ja auch nicht so schön. Aber ich sehe das Problem.

[WBTMagnum]

In erster Linie geht es mal darum, dass sich in dieser Form doch keine Daten vor dem 1.1.1970 abspeichern lassen. Richtig oder Falsch?

Falsch! Mit Unix Timestamps lassen sich sehr wohl auch Daten vor dem 1.1.1970 abbilden. Hier wird der Timestamp einfach negativ (sh. https://de.wikipedia.org/wiki/Unixzeit). Problematisch wird es nur, wenn ein 32bit Timestamp verwendet wird.

Ein weiteres Problem ist, dass <we:input type="date" /> tatsächlich nur die Eingabe von Daten ab 1970 erlaubt. Dh. hier muss man ggf. eine eigene/andere Lösung für die Eingabe anbieten.


Liebe Grüße,
Sascha

[ThomasGoebe]

Ein weiteres Problem ist, dass <we:input type="date" /> tatsächlich nur die Eingabe von Daten ab 1970 erlaubt. Dh. hier muss man ggf. eine eigene/andere Lösung für die Eingabe anbieten.

Oder <we:input type="date" /> überarbeiten.. Aber auch wenn Daten vor 1970 im Timestamp grundsätzlich möglich sind, so bin ich in den letzten Jahren mehrfach in wE an diese Grenze gestossen. Daran hat damals mal wieder niemand gedacht ;.) Inzwischen ist das glaube ich aber besser (z.B. in Klassen).

[mokraemer]

An einigen Stellen haben wir bereits auf "normale Zeitstempel" umgestellt.
Zum <we:input date> könnte ja jemand einfach einen FR schreiben.
Problematisch ist die Umstellung eigentlich v.a. wg. dem ganzen Altkode, der an WE vorbei in Conditions etc. UNIX-TimeStamps voraussetzt, sonst wäre das schon an einigen anderen Stellen ein "echtes Datum"

[Carrear]

Aber man kann doch bei der Ausgabe ein Format angeben. Dann müssen die eben angepasst werden, dass es eben im UnixTimestamp-Format ausgegeben wird?

[ThomasGoebe]

Du verstehst das falsch:

Code: Alles auswählen

<?php 
$myCondition = "Zeitfeld >= 1234567";
?>
<we:listview condition="mycondition">
</we:listview>

sind leider sehr oft genutzte Dinge. Natürlich deutlich komplexer als dieses Beispiel. Ich selbst habe zig Projekte, in denen ich umfangreiche Abfragen und auch Schreiboperationen direkt in der DB machen muss, da webEdition das früher mal nicht konnte. Bisher galt die Maxime: möglichst abwärtskompatibel sein.

Das kann sich aber auch noch mal ändern.

[mokraemer]

@Thomas: ich denke auch langfristig muß dies geändert werden.

Bei den Conditions könnten wir das noch teilweise intern umschreiben. Problematisch blieben eigene Abfragen und eigene Feldzuweisungen.

Das ist ja der Grund, warum wir hier noch nichts gemacht haben. Die Auswirkungen sind derzeit schwer absehbar.