Neuer controlfile-Befehl CRE

[OdfFhem]

Hallo,

ich fände es sehr nützlich, wenn man über das controlfile auch Dateien einmalig ausliefern könnte - soll heißen: nur, wenn noch nicht vorhanden.

Momentan ist es leider nicht möglich, Dateien auszuliefern, die vorhanden sein müssten, deren Inhalt aber anschließend in den Händen des Anwenders liegen soll.

Nach meinem jetzigen Verständnis entspricht ein CRE-Fall im update-Modul fast vollständig einem UPD-Fall; einzige Ausnahme: $fileOk ist schon alleine dann erfüllt, wenn die Datei bereits vorhanden ist - Zeitstempel bzw. Größe spielen keine Rolle.

Mit folgenden Änderungen habe ich einige Testläufe erfolgreich absolviert:

Code Auswählen Erweitern


Zeile #288
-    next if($l[0] ne "UPD");
+    next if(($l[0] ne "UPD") && ($l[0] ne "CRE"));

Zeile #325
-     next if($r[0] ne "UPD");
+     next if(($r[0] ne "UPD") && ($r[0] ne "CRE"));

Zeile #346
-                     $lh{$fName}{TS} eq $r[1] &&
-                     $lh{$fName}{LEN} eq $r[2]);
+                     (($r[0] eq "CRE")
+                      || ($lh{$fName}{TS} eq $r[1] &&
+                          $lh{$fName}{LEN} eq $r[2])));

Zeile #360
-         next if($isExcl || ($fileOk && defined($sz) && $sz eq $r[2]));
+         next if($isExcl || ($fileOk && defined($sz) && (($r[0] eq "CRE") || ($sz eq $r[2]))));


Sollte ich nichts Wesentliches übersehen haben, besteht hier Aussicht auf Übernahme?

###

Bei meinen Tests habe ich folgendes, vermutlich ungewolltes Verhalten festgestellt:

• Filename in der CRE/UPD-Zeile existiert auf der URL-Seite nicht
• Zeile 377 (my $remFile = upd_getUrl("$basePath/$fName");) liefert nicht erwartungsgemäß den leeren String
• Stattdessen geliefertes Ergebnis: 404: Not Found
• Notaustieg über:Got 15 bytes for www/tablet/css/test_test_test_user.css, expected 0
• Entspräche die erwartete Größe zufällig 15, würde es erst einmal weitergehen ...

[rudolfkoenig]

ich fände es sehr nützlich, wenn man über das controlfile auch Dateien einmalig ausliefern könnte [...]

Kannst Du uns verraten, wofuer genau?

[OdfFhem]

Kannst Du uns verraten, wofuer genau?

Ich würde es z.B. gerne im FTUI-Umfeld verwenden. Gerade dann, wenn css-Dateien im Rahmen eines Widgets geladen werden, hat der Anwender keine Möglichkeit - glaube ich zumindest bis jetzt - eine nutzerspezifische Datei einzuschleusen und zu priorisieren.

[rudolfkoenig]

hat der Anwender keine Möglichkeit - glaube ich zumindest bis jetzt - eine nutzerspezifische Datei einzuschleusen und zu priorisieren.

Ich habe Schwierigkeiten beim Verstaendnis dieser Formulierung, kannst Du es bitte auch anders versuchen?

Wenn ich Anwender durch Entwickler ersetze, dann sehe ich die Moeglichkeit eine erste Konfiguration im Modul zu speichern, und falls sie auf der Platte nicht existiert, zu erstellen.
Ich will nicht sagen, dass es nicht eleganter geht, aber "keine Moeglichkeit" ist was Anderes.
Heisst nicht, dass ich gegen deinem Vorschlag bin, will aber vor dem Einbau verstehen, wozu.

[OdfFhem]

@rudolfkoenig

Ich versuche es mal:

Bei FTUI habe ich grundsätzlich die Möglichkeit, alle möglichen css-Dateien im header-Bereich einer HTML-Datei anzugeben und zwar in der gewünschten Reihenfolge. Hier liegt die "Verantwortung" vollständig bei der Person, die eine HTML-Datei anlegt (im Folgenden HTML-Person genannt).

Neben den HTML-Dateien gibt es aber auch noch FTUI-Widget-Module, die selbstständig js- oder css-Dateien nachladen - sorgt u.a. dafür, dass solche Dateien nur geladen werden, wenn sie auch tatsächlich benötigt werden. Wer z.B. keinen Swiper einsetzt, braucht auch nicht die zugehörigen Dateien laden (spart Ladezeit, Ressourcen, ...).

Aktuell beschäftige ich mich mit einem FTUI-Widget, das von etlichen Bibliotheken abhängig ist und das Standard-Styling wird dabei während der Initialisierung als css-Datei geladen. Die Festlegungen dieser neu geladenen css-Datei können nun nicht mehr von der HTML-Person einfach überladen werden. Es sei denn, man lädt im Rahmen der Initialisierung auch noch eine (zunächst leere) nutzerspezifische css-Datei, in der die HTML-Person "alles" neu definieren könnte oder auch nur anpassen. Der CRE-Fall ist u.a. genau für solch eine nutzerspezifische Datei gedacht; deren Name wird vom Widget-Modul-Entwickler festgelegt, der Inhalt aber ausschließlich von der HTML-Person; folglich darf eine solche Datei auch niemals mehr automatisch überschrieben werden.



Ich hoffe mal, dass meine Beurteilung der Lage halbwegs mit den tatsächlichen Gegebenheiten übereinstimmt; zumindest war die geschilderte Lage die Motivation für den Änderungswunsch ...

[rudolfkoenig]

Ich habe die von Dir vorgeschlagenen Aenderungen uebernommen und eingecheckt.

[OdfFhem]

@rudolfkoenig

Zunächst einmal vielen Dank für die Übernahme des Änderungswunsches.

Nach dem heutigen Modulupdate und einem kleinen Test habe ich festgestellt, dass im offiziellen Stand die Änderung zur (ursprünglichen) Zeile #360 nicht übernommen wurde; dadurch wird im CRE-Fall ein verändertes Modul immer wieder mit dem Initialzustand überschrieben. Zur Veranschaulichung habe ich folgendes, logangereichertes "update check"-Protokoll erzeugt:

Code Auswählen Erweitern


----- www/tablet/css/test.css ----- fileOk:1   sz:11   r2:1
List of new / modified files since last update:
CRE www/tablet/css/test.css
----- www/tablet/js/widget_abc.js ----- fileOk:1   sz:9870   r2:9870
----- www/tablet/js/widget_xyz.js ----- fileOk:1   sz:7216   r2:7216

In diesem Fall wurde test.css verändert (11 bytes) und beim "update check" fälschlicherweise ausgegeben, da die erwartete Größe (1 byte) nicht übereinstimmt.

[rudolfkoenig]

Sorry fuer den Fehler, habe die letzte Zeile jetzt uebernommen.
Weiterhin auch ein Warning entfernt, die durch falsche Klammerung entstand.

[OdfFhem]

@rudolfkoenig

Heute nochmals ein Update gemacht und jetzt funktionierrt es wie erwartet - vielen Dank.

Soll ich den zugehörigen Wiki-Artikel noch entsprechend erweitern oder macht das jemand anders?