LoxBerry HTML Template System

**svethi** · 31.01.2017, 07:29

Das Zeug muss ich mir erst einmal ansehen :-) sooo schlimm fand ich das jetzt nicht. Ich habe bezüglich der Comboboxen die Options immer im CGI fertiggemacht und in eine Variable geschrieben und diese dann im Template nur eingefügt.

**Christian Fenzl** · 31.01.2017, 09:40

Das mit HTML::Template schau ich mir auch mal an. Ich hab als Perl-Neuling vom Guru (Michael) übernommen, ohne zu wissen, was ich da tu. Und als das Squeezelite halbwegs ein brauchbares Template hatte, war es mir zu blöd, jede Änderung in mehreren Sprach-Templates zu machen. Die Not macht erfinderisch :-)

Die "lästigen" Dinge, wo das LB-Framework helfen kann, soll so abstrahiert sein, dass ein Perl-Neuling sich nicht mit der LB-Struktur (Configfiles, Header/Footer...) befassen muss.
Oliver ist beim Sonos-Plugin genau da drüber gestolpert, und ich kann bestätigen, dass es frustrierend ist, wenn man hängt bei Sachen, die gar nicht zur eigentlichen Funktionalität gehören.

Die Mehrsprachigkeit ist auch so ein "lästiges Übel" - das muss so einfach sein, dass man als Entwickler keinen Frust bekommt, und man die Übersetzung auch auslagern kann.

Oder Logfiles. Ich selbst habe jetzt schon zwei unterschiedliche Logfile-Routinen gebaut, aber beide noch nicht durchgängig (z.B. kein Viewer). Das ist auch was, was in die LB-Basis gehört, mit allem Drum und Dran.

Mein Ziel wäre, ein neues Sample-Plugin zu machen (z.B. GPIO), dass alles LB-spezifische so versteckt, dass die Systemsachen nur wenige Zeilen Code brauchen. Und alles auf dem Weg dorthin packe ich in die Module.

Lg, Christian

**svethi** · 31.01.2017, 10:50

Genau diese Mehrsprachigkeit ist ein Übel *g* bin ich beim Fritz.Lox ja auch erst wieder drüber gestolpert ;-) Ich bin dafür das Deutsch als einzigste Sprache auf der Welt etabliert wird :-). Dann müsste sich auch Trump neu lernen auszudrücken :-) So einfach wie möglich bei der Entwicklung von Plugins, das wäre schön nicht schlecht. Man muss sich das alles mal ansehen und die Möglichkeiten abwägen. Letztlich isses ja so, dass um so einfacher es für die User ist, desto komplizierter isses ja für die Hintergrundprogrammierung. Ich bewundere Euch Beide. Ich kann nicht so viel Zeit für derartiges Abtreten. Nicht dass das Ganze ein Projekt für die Unendlichkeit wird ;-)
Wie gesagt, einfacher ist sicher besser und anhand der noch offenen Wünsche stellt sich die Frage, ob man nicht erst einmal dann den LB in Next-Level hebt bevor zum Schluss zu viel an den dann bereits bestehenden Plugins gemacht werden muss. Abwärtskompatibilität wäre hier natürlich auch schön :-)

**Christian Fenzl** · 31.01.2017, 11:21

Wenn jetzt nicht gerade die Ordnerstruktur über den Haufen geworfen wird, oder die Config sich ändert, bleibt alles abwärtskompatibel. Da würde ich nicht schrauben.

Ich finde meine Zeit aber besser investiert in Systemmodule und die zugehörige Doku, als in weiteren Plugins immer wieder alles neu zu erfinden.
Z.B. beim LMS Gateway im Squeezelite Plugin habe ich in drei Scripts die gleichen Funktionen für das UDP- und HTTP-Senden an den MS --> pack ich in LoxBerry::System (oder LoxBerry::IO?). Non-Blocking Kommunikation mit dem LMS --> LoxBerry::IO (@Prof.Mobilux apropos, wenn du dir den Squeezelite dev-Branch ziehst, da hab ich die Kommunikation nochmal verbessert - jetzt kannst in iPeng den Volume-Slider ziehen, und siehst wirklich praktisch in Echtzeit die Änderung am MS).

Ich hab die Hoffnung, dass sich diejenigen, die bisher gesagt haben, "ich kann entwickeln aber kenn micht mit Perl/LB nicht aus", sich selbst heranwagen und probieren. Dann bleibt auch nicht alles auf unserer Hand voll LB-Entwickler liegen, und Michael hat mehr Zeit, die LB-Basis zu entwickeln.

Ich brauch jedenfalls einen zusätzlichen Raspberry. Ein produktiver Pi1 hat heute den Geist aufgegeben, und Testen ist ohne zusätzlicher Hardware auch ganz schlecht.

Lg, Christian

**svethi** · 31.01.2017, 11:33

Wenn Du schon das Thema Perl ansprichst, viele, so habe ich den Eindruck, scheuen vor dem Perl zurück. Dann müsste man auch konsequent sein und ebenso PHP-Libraries zur Verfügung stellen, die die selben Funktionen haben.
Es ist genau wie Du sagst, die Wunschliste wird immer länger und nur ein paar wenige machen selbst was. Meine Hoffnung wäre auch, dass sich dann mehr beteiligen würden.

**Christian Fenzl** · 31.01.2017, 13:27

PHP macht auch Sinn. Erst Perl halbwegs fertig machen, und dann die PHP-API aufrufsgleich für PHP, würd ich sagen.
Obwohl, wenn man die Regex-Sachen von Perl nicht betrachtet, es nicht so viel anders wie PHP ist.

**Prof.Mobilux** · 01.02.2017, 08:57

Die LoxBerry-Module finde ich eine super Idee, das wird auf jeden Fall die Einstiegshürde nehmen und auch uns "erfahrenen" Pluginentwicklern sehr viel Standardwork abnehmen. Ich glaube aber, dass unabhängig davon PHP bei den meisten Leuten bevorzugt wird (auch wenn es sich vielleicht nicht großartig unterscheidet). Es ist einfach die bekanntere Scriptsprache und verzeiht vermutlich auch mehr "unsaubere" Programmierung als Perl das tut. Daher finde ich die Idee super, die Module dann später auch auf PHP zu portieren. Und ich habe mir sowieso schon vorgenommen, dass in der nächsten LoxBerry-Version PHP ebenbürtig zu Perl verwendet werden kann. Etwas umständlich geht das heute schon, aber richtig smart wird es, wenn die PHP-Skripte auch ins CGI-Verzeichnis abgelegt werden können und man sich aussuchen kann, ob beim Klick im Hauptmenü nun index.cgi oder index.php aufgerufen wird. Das wird definitiv kommen.

Unabhängig davon glaube ich, dass wir mit HTML::Template in Kombination mit Christian Fenzl Multilanguage-Konzept ganz gut bedient sind. Ich bin mir nicht sicher, ob es uns gelingt diese "selected=selected"-Geschichte in ein Modul auszulagern (wüsste im Moment noch nicht, wie das allgemeingültig funktionieren kann). Und da bietet HTML::Template eine sehr einfache Möglichkeit (glaube ich

). Es gibt dazu im Übrigen auch eine PHP-Version mit exakt gleicher Syntax (was zu prüfen wäre): https://sourceforge.net/projects/phphtmltemplate/

Ich werde das jetzt bei der Grafikengine im Stats4Lox mal testen.

**svethi** · 01.02.2017, 17:24

Hmm, ich habe mir mal das HTML::Template angesehen. Ich weiß nicht ob ich etwas übersehen habe, für mich stellt sich das doch genauso dar wie das, was wir eh schon machen. Du musst ein HTML-File bauen, musst dort spezielle Tags hinterlegen, die dann ersetzt werden und bei den Loops musst Du auch im CGI erst ein Array füllen um dieses dann an das konfigurierte Loop zu übergeben. Ich dachte eher, dass da sowas dabei ist wie hier hast Du ein Array, baue mir davon ein Select und wähle das erste aus. Irgendwie sieht das für mich genauso kryptisch aus.Christian Fenzl sag Du doch auch mal was ;-)

**Christian Fenzl** · 01.02.2017, 17:58

svethi Ich hab's mir noch nicht angesehen! :-)

**Prof.Mobilux** · 01.02.2017, 18:28

Es müsste doch gehen die Werte in ein Array zu packen und mit Loop durchzuarbeiten. Innerhalb vom Loop dann mit if-then das selected=selected zu setzen. Oder so ähnlich :-)

**svethi** · 01.02.2017, 18:55

Hmm, also ich mache das zur Zeit ja so.
...
<select>

</select>

das sieht für mich einfacher aus als Loop- und Variablendefinitionen.

**Christian Fenzl** · 01.02.2017, 19:42

In der PHP-Welt macht man's mit Schleife und die Bedingung ist direkt an der entsprechenden Stelle. Da ist es halt anders, weil man bei PHP praktisch schon im Template sitzt.

Hmm.

Code:

<option value="Verbrauchszähler" selected="selected">Verbrauchszähler</option>

Drei Variablen:

Code:

<option value="<--$value[$nr]-->" <!--$selected[$nr]-->><!--$val_language[$nr]--></option>

Mit'n Perl-Hash?

**svethi** · 01.02.2017, 20:18

Hast Du, glaube ich, falsch verstanden. Ist ein Auszug aus einem Template. $options stellt einen Variable im Perlscript dar, die mit den options gefüllt ist und durch das perlscript ersetzt wird

**Christian Fenzl** · 01.02.2017, 20:50

Hab dich schon verstanden. Das entledigt dich ja nicht, das $options zusammenzubauen. Darüber denk ich nach.

Hab jetzt ein Tutorial für HTML::Template gelesen. Ähnlich, und die Stärke spielt es aus, wenn's komplex wird. Wenn's um Loops oder Array-Listen die auf Hashes zeigen, da steig ich und jeder aus.

PHP-Code:

# prepare the DS for the rows
my $i;
my $rows = [
   map {
      my $row = $_;
      (++$i % 2)
         ? { ODD  => [ map { {VALUE => $_} } @{$row} ] }
         : { EVEN => [ map { {VALUE => $_} } @{$row} ] }
   } @{$data}
];
# remove excess blood from ears after that last expression

Der Autor hat's eh ganz gut zusammengefasst.

Ist natürlich cool, wenn man's dann so ausgeben kann:

PHP-Code:

$template->param(
   ROWS    => $rows,
);
print $template->output();

Ist ein Extrembeispiel - aber es bringt schon eine Datenkomplexität (Array mit Hashes) hinein, damit's gut funktioniert.
Dass Felder in Zusammenarbeit mit CGI automatisch wieder vorbefüllt werden, ist dafür auch eine riesen Stärke!

LoxBerry HTML Template System

LoxBerry HTML Template System

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar