Best Practise: Perl-Programmierung im LoxBerry

[Prof.Mobilux]

Moin,

wir diskutieren ja schon länger, wie man die Einstiegshürde zur LoxBerry-Plugin-Entwicklung vereinfachen kann. Zudem sind in den bestehenden Plugins und auch im Hauptsystem noch viele "meiner" Altlasten enthalten, die dringend bereinigt gehören.

Ich habe daher als Diskussionsvorschlag mal ein "Best Practise" entworfen, wie es meiner Meinung nach sauber aufgebaut ist. Ich habe dazu folgendes zusammengepackt:

• Altlasten entfernt, insbesondere Auswertung des Query-Strings. Umgestellt auf CGI-Modul.
• Wörsty "get over post" implementiert
• Template-System umgestellt auf HTML::Template, damit auch keine Probleme mehr bei "use strict" und zudem müssen nicht mehr alle Variablen mit "our" definiert werden
• Christian Fenzl Language Phrases Routine übernommen: "Missing phrases in foreign language will fall back to English"
• Christian Fenzl Strikte Trennung zwischen Syntax und Textstrings - damit vereinfachte Übersetzungen

Das Ganze muss dann natürlich noch auf LoxBerry::System etc. umgebaut werden. Das fehlt noch komplett.

Und bei "quotemeta" bin ich mir auch unsicher - siehe hier: https://www.loxforum.com/forum/proje...s-config-datei

Was denkt ihr?

[Christian Fenzl]

Wurde leider aufgehalten, muss einen Kuchen backen... (bzw. helfen).

[svethi]

Was machst Du denn noch alles :-)
Oder heißt der Kuchen Loxberry::System? *bg*

[Christian Fenzl]

Frau war eh schon sauer, weil ich immer gefragt hab, "Sind wir jetzt fertig? Sind wir jetzt fertig?" :-)

[Christian Fenzl]

Ich würde vorschlagen, dass du das Sample bei GitHub lagerst, dann könnten wir gemeinsam das eine oder andere noch einbauen.

Ein neues Sample ist jedenfalls sehr gut, weil ich bin mit dem alten Sample damals nicht zurechtgekommen und hab dann alles Mögliche und Unmögliche zusammenkopiert :-)

[Prof.Mobilux]

Ich habe es mal auf GitHub hochgeladen - soll dann später auch gleich für dei Plugin-Schnitstelle V2.0 für die nächste LoxBerry-Generation dienen:

https://github.com/mschlenstedt/LoxBerry-Plugin-SamplePlugin-V2

[Prof.Mobilux]

Also ich habe jetzt den ganzen Abend versucht die Loop-Funktion von HTML::Template zum Laufen zu kriegen - und die Brocken frustriert in die Ecke geschmissen... Prinzipiell ist das schon geil, nur extrem kompliziert. Ich bin jetzt soweit, dass der Loop zwar durchläuft, aber immer mit den gleichen Werten :-(( Das ist alles andere als einfach zu verstehen.

Ich werde zu unserem alten Template-System zurückkehren.

[Prof.Mobilux]

Naja, prinzipiell finde ich es besser die komplette Syntax ins Template zu packen anstelle im Perlcode zusammenzubauen.

Aber die musst die einzelnen Variablen, die du im Loop brauchst, zunächst in einen Hash packen. Diese Hashes wiederum packst du in ein Array. Der Loop arbeitet dann das Array ab. Alles klar? ;-) Aus irgendeinem Grund scheinen bei mir aber alle Hashes identisch zu sein, die ich ins Array gepackt habe. Ich kriege einfach nicht raus warum...

Aber für einen Anfänger ist das mit Hashes, Arrays usw. sicherlich absolut unverständlich...

[Prof.Mobilux]

Ah, ich hab's: In einem Array kann man nur _Referenzen_ auf Hashes speichern - da ich in meiner Schleife den Hash aber immer wieder überschreibe, bleibt die Referenz dann im letzten Durchlauf auf dem letzten erzeugten Hash stehen... Wie simpel doch Perl ist! :-)

[svethi]

Das mit den Referenzen ist immer wieder und in vielen Sprachen ein Mysterium :-)

[Prof.Mobilux]

So, jetzt habe ich's. Das ist kompiziert - aber wenn man es kapiert hat ist's genial einfach - wie immer bei Perl ;-) Da mit HTML::Template beide Varianten funktionieren, also sowohl die Loop-Funktion von HTML::Template als auch das "herkömmliche" zusammenbauen im Programmcode "a la svethi", ist es vielleicht doch sinnvoll bei HTML::Template zu bleiben und dem Plugin-Ersteller die Wahl zu überlassen (je nachdem ob erfahren in perl oder nicht).

[Prof.Mobilux]

Ich habe das neue Sample Plugin jetzt erweitert: Es wird eine Select-Liste erzeugt über die Loop-Funktion von HTML::Template und die gleiche Liste noch einmal über die "herkömmliche" Weise, indem die HTML-Syntax in eine Variable geschrieben wird. Beides geht.

[Christian Fenzl]

Wenn ich mich nicht auskenne, und ein gutes Sample habe, ist es mir egal, ob da $variable oder \&$variable oder sonstwas steht, Hauptsache es funktioniert :-)

Daher macht es schon Sinn, auch was Komplexeres mit HTML::Template zu samplen, wenn die Kommentare dazu gut sind.

Schön dass es funktioniert!

[Prof.Mobilux]

Sehe ich auch so, besonders wenn die alte "einfache" Varinate auch weiterhin funktioniert. Ich habe jetzt eine Tabelle mit einem Loop erzeugt - 3 Zeilen Code im Template. Früher hatte ich dazu 3 Templatedateien "Start", "End" und "Row". Ging auch, war aber deutlich komplizierter - auch im CGI-Script selbst.

[svethi]

Und wenn man das in Loxberry::Web kapselt? Ein makeSelect($Array) ergibt den html-Schnipsel? $Array[]['value']; $Array[]['name']; $Array[]['selected']

[Christian Fenzl]

Leider muss ich in 15 Minuten den gestern gebackenen Kuchen essen :-(

In meinem Fork von miniserverbackup (Branch LoxBerry-System) ist der letzte Stand von LoxBerry::System und ::Web, der auch funktioniert.
CloudDNS ist drin aber nicht getestet.
In webfrontemd/cgi/perllib

[svethi]

Den Kuchen essen kann er ja nebenbei, das Backen lenkt ihn so lange ab :-)

[Prof.Mobilux]

Ooch, beim Essen helfe ich Dir gerne :-)

[Christian Fenzl]

Ich hab das Sample noch nicht ausprobiert, aber was mir ins Auge sticht, wir sogar eher bräuchten und funktionieren könnte:

tie %PluginConfig, "Config::Simple", '$lbconfigdir/pluginconfig.cfg';
$maintemplate = HTML::Template->new(
    filename => "$installfolder/templates/plugins/$psubfolder/multi/main.html",
    global_vars => 1,
    loop_context_vars => 1,
    die_on_bad_params => 0,
    associate => $PluginConfig,
); 

Wenn's funktioniert, sollte im HTML dann

<TMPL_VAR NAME=MAIN_SCRIPTNAME> <!-- oder -->
<TMPL_VAR NAME=MAIN.SCRIPTNAME> 

direkt das Formular aus dem Configfile befüllen. Das brauchen wir eigentlich häufiger als die CGI-Variablen vorzubefüllen.

[Christian Fenzl]

Prof.Mobilux PS zum Lesen der Plugin-Config: Da sollte das Plugin eigentlich nie sterben, sondern eine neue Config anlegen, und ggf. Standardwerte setzen (Link)

[Christian Fenzl]

Passt, HTML::Template ist supa!

Guckst du:

#!/usr/bin/perl
use Config::Simple;
use HTML::Template;

$plugincfg = new Config::Simple('pluginconfig.cfg');

$maintemplate = HTML::Template->new(
    filename => "main.html",
    global_vars => 1,
    loop_context_vars => 1,
    die_on_bad_params => 0,
    associate => $plugincfg
);  
print $maintemplate->output;

# pluginconfig.cfg
[Instance1]
Name=Partyraum
Output=default:CARD=ALSA

# HTML Template:
<html>
<TMPL_VAR INSTANCE1.NAME>
<TMPL_VAR INSTANCE1.OUTPUT>
</html>

# HTML Output
<html>
Partyraum
default:CARD=ALSA
</html> 

[Prof.Mobilux]

Finde ich auch :-) Aber die Loops sind schräg... Ich habe jetzt einen "nested loop" gebaut (Loop im Loop). Da raucht einem vor Arrays of Hashes of Arrays of Hashes, Anonymous Hashes etc. pp. ganz schön der Kopf. Für Anfänger nicht empfehlenswert - da krieg selbst ich Perl-Phobie :-)

[svethi]

Nimmt Formen an :-)