<div dir="ltr">Hallo Florian,<br><div class="gmail_extra"><br><div class="gmail_quote">2014-05-26 15:57 GMT+02:00 Florian Knodt <span dir="ltr"><<a href="mailto:f.knodt@yotaweb.de" target="_blank">f.knodt@yotaweb.de</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mahlzeit,<br>
<br>
ich habe vor kurzem eine Steuerungsanlage aus den frühen 90ern per<br>
Volkszähler "Web-fähig" gebastelt. Leider war der CSV-Export noch nicht<br>
ganz das, was die hiesigen Prüfer als brauchbar empfanden. Anbei ein<br>
paar Anregungen, vielleicht kann es dem ein oder anderen als Startpunkt<br>
dienen.<br>
<br>
Disclaimer: Anlage musste schnell online gehen, daher eher quick&dirty.<br></blockquote><div><br></div><div>Man sieht es ;)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


001_default_tsfmt.patch<br></blockquote><div><br></div><div>Scherz beiseite- die Änderungen an View.php verstehe ich nicht- ihr habt einfach tsfmt=sql auf relativ komplizierte Weise gesetzt, oder?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Erlaubt Exportmodulen das standardmäßige Datumsformat vorzugeben. Als<br>
Beispiel verwendet CSV nun - sofern nichts anderes geforders - sql<br>
(YYYY-mm-dd HH:MM:SS) statt timestamp. Da CSV nach meiner Erfahrung in<br>
den meisten Fällen in Excel o.Ä. zur menschengestützten Ansicht landet<br>
ist dieses Zeitformat imo sinnvoller.<br></blockquote><div><br></div><div>Absolut. Ich denke für's Frontend würde ich das eher in das ins Frontend/JS verlagern- dann brauchts keine Viewanpassungen.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


CSV.php<br>
<br>
Ist eine alternative^wzurechtgebastelte Implementierung des originalen<br>
CSV-Export. Statt alle Kanäle untereinander zu schreiben werden die<br>
Daten gesammelt und in eine Tabelle (uuid;timestamp) umgebogen.<br>
<br>
- Da die Daten im RAM gesammelt werden eher nicht für große Datenmengen.<br></blockquote><div><br></div><div>Auf das Problem bin ich auch gestossen. Aktuell exportiert das Frontend darüber hinaus _alle_ Daten ohne from/to- damit kann man sich einen kleinen Raspi schnell abschießen.<br>

<br></div><div>Eine (elegante) Lösung könnte so aussehen, dass der Controller alle Interpreter instanziiert und diese vom View erst bei Bedarf abgerufen werden ("streaming"). Dann könnte der View entscheiden ob er erst sammeln will ("en bloc"- schlecht für den Speicher) oder "on the fly" einliest. Leider gibt es fälle wo es "en bloc" sein muss, z.B. beim JSON export da die PHP-interne Funktion einfach Welten schnell ist.<br>

<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Da keine Zusammenfassung stattfindet für Kanäle mit unterschiedlichen<br>
  Timestamps nur mäßig brauchbar<br>
<br>
Meine Daten kommen nur 1x am Tag rein und werden entsprechend mit einem<br>
Timestamp von Punkt 0 Uhr an die Middleware verfüttert, daher für meinen<br>
Zweck noch passend. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
Florian<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">vg<br></div><div class="gmail_extra">Andreas<br></div></div>