Auf Anraten Iflands erstellen ich hiermit einen neuen Fred, in dem es um die Entwicklung des WebIFs gehen soll.
OK, es gibt einen neuen Prototypen.
Habe einige Varianten durchprobiert, von denen mich letztlich keine so richtig überzeugt hat. Dann habe ich den "komplizierten" Weg in Angriff genommen und plötzlich fügte sich ein Puzzleteil zum anderen
Aus rein ästhetischen Gründen habe ich mich für die Beibehaltung des Frames (und der JS-Links) entschieden.
Funktional bin ich mit dem Jetztigen wesentlich glücklicher.
Was nicht geht, ist der Refresh der Seiten per F5 oder Refresh-Icon des Browsers. Da ich aber selbst jemand bin, der sehr häufig die refresh-Funktion des Browsers verwendet, habe ich das Freetz-Icon so gestaltet, dass eine Aktivierung des Icons dem Refresh des Browsers nachkommt und eben funktioniert (hat damit zu tun, dass ich die Session-Prüfung gesalzen habe).
Zuviel Salz in der Suppe ist eben auch nicht das wahre.
Naja - ich persönlich kann mit dem Ergebnis gut leben und hoffe, dass es dem einen oder anderen auch gefällt.
Den jetzigen Prototyp habe ich auf, bzw. mit der FB entwickelt. Danke nomml an Ralf Friedl für den Tip bzgl. nfs
Das Archiv enthält die Verzeichnisse wie sie im Freetz-Buildsystem verwendet werden (also root, source, etc.).
Da ich haserl gepanscht habe, verwende ich das aktuelle Paket (0.9.26), das aber auch mit dem freetz 1.1.3 problemlos zusammenspielt. Haserl und getText muss mit in die Firmware aufgenommen werden.
Das Verzeichnis /usr/mww habe ich manuell per nfs auf der FB eingebunden. Dazu habe ich mir ein Script startWork geschnitzt:
Damit der webserver beim Neustart auch die Konfiguration des Prototypen verwendet, habe ich folgende Links auf der FB gesetzt:
Das conf-Verzeichnis wird vom WebIF nicht verwendet und ist per Kennwort geschützt. In dem conf-Verzeichnis liegt auch die Datei mit den Sprachtexten, die mit dem beiliegenden Script ins Binärformat übersetzt werden kann.
Dazu muss vom Paket htmltext das Tuhl createDB (auf dem PC) übersetzt und nach /usr/local/bin kopiert werden.
Was tut:
- Login + Layout-Wechsel (admin und rednose)
- die Layouts unterscheiden sich nicht nur in Farben, sondern auch in Seitenverhalten und -Inhalt
- Statusseite (mit echten Daten)
- Netzwerk -> Dienste (echter Status)
- System -> Logausgaben (nur admin)
Jetzt hoffe ich, dass ich nix Wichtiges vergessen habe und wünsche viel Spaß beim Ausprobieren.
Gruß Gero
P.S.: Ackso: admin hat das Kennwort Freetz, der Benutzer "rednose" keines.
P.P.S: Noch ne Info zu den Änderungen/Erweiterungen:
haserl hat ein neues Sprach-Kürzel bekommen: <%m Schlüssel %> kann verwendet werden, um Texte aus der Sprachdatenbank zu lesen. Der aktuelle Stand erlaubt Schlüssel mit einer Länge von bis zu 5 Zeichen. Ich denke, das ist ein akzeptabler Kompromiss zwischen Lesbarkeit und Dateigröße.
Ich vermute mal, dass AVM die Schlüsseltabelle in den webcm kompiliert hat, sodass andere Schlüsselvarianten möglich sind.
Um die gleiche Funktionalität in haserl-Scripten und CGI-Shellscripten zu erreichen, gibt es das Paket htmltext, welches das kleine Werkzeug getText liefert. <%m Schlüssel %> entspricht einem "getText Schlüssel", wobei als Standard die Datenbank /var/htmltext.fa verwendet wird. Eine andere Datei kann über Parameter angegeben werden.
Messungen zum Seitenaufbau haben ergeben, dass die Unterschiede zwischen statischen Texten und Texten aus der Datenbank unterhalb der Messgenauigkeit liegen.
Vom Paket htmltext ist getText vorgesehen, in die Firmware gepackt zu werden, während createDB nur für die Verwendung am PC vorgesehen ist.
Zu den Bildern (von links nach rechts):
- Einstiegseite des WebIF
- Statusseite (Benutzer rednose)
- Statusseite (Benutzer admin)
Vorschau:
- Logausgaben (Benutzer rednose)
- Logausgaben (Benutzer admin)
- Übersicht der Netzwerk-Clients / Kindersicherung
Änderungen gegenüber dem bisherigen WebIF:
abgesehen von dem offensichtlichen, gibt es auch funktionale Unterschiede:
Beim Freetz-WebIF geht jedes CGI-Script davon aus, dass es die ganze Seite im Browser darstellt. Dafür gibt es dann ja auch libmodcgi, bzw. cgi_begin und sec_begin.
Dieser Ansatz entstammt dem üblichen Schnellschuss und ist leider sehr weit verbreitet (ich habe es in meinem ersten Prototypen ja genausso gemacht). Echte Layout-Unterstützung lässt sich aber nur durch IOC (inversion of control) erreichen. Das ist etwas aufwändiger im Konzept, dafür erreicht man alle Freiheiten in der Gestaltung.
Der jetzige Prototyp funktioniert so. Haserl ist der "Einstiegskontroller", sodass die Verarbeitung der CGI-Variablen schon erfolgte und diese einfach dem Environment entnommen werden können. Die eigentlichen CGI-Scripte können Shell- und/oder Haserl-Scripte sein. Wer die Statusseite anschaut, wird feststellen, dass die Inhalte unterschiedlich sind, je nach Layout. Gemeinsame Bereiche werden gemeinsam verwendet, eigene Bereiche einfach ergänzt. Ein Hoch auf die Links im Unix-Dateisystem
Für die Seiten bedeutet dies, dass sie keine Annahmen über das machen dürfen, was sie umgibt. Sie müssen davon ausgehen, dass sie einen Bereich zur Verfügung gestellt bekommen, in dem sie sich darstellen können.
Habe mir noch Gedanken über eine mögliche Migration gemacht. Ich denke, wenn man cgi_begin und Co zu Nops ändert, sollte das meiste schon funktionieren. Vielleicht müsste ich noch ein paar Anpassungen machen, um exec-Scripte vor der Anzeige zu ermöglichen.
Ich denke, das technische Fundament ist da, sodass ich mir eine Diskussion über das weitere Vorgehen wünsche.
Was ich nicht möchte, ist eine one-man-show - aber das sagte ich ja bereits an anderer Stelle.
OK, es gibt einen neuen Prototypen.
Habe einige Varianten durchprobiert, von denen mich letztlich keine so richtig überzeugt hat. Dann habe ich den "komplizierten" Weg in Angriff genommen und plötzlich fügte sich ein Puzzleteil zum anderen
Aus rein ästhetischen Gründen habe ich mich für die Beibehaltung des Frames (und der JS-Links) entschieden.
Funktional bin ich mit dem Jetztigen wesentlich glücklicher.
Was nicht geht, ist der Refresh der Seiten per F5 oder Refresh-Icon des Browsers. Da ich aber selbst jemand bin, der sehr häufig die refresh-Funktion des Browsers verwendet, habe ich das Freetz-Icon so gestaltet, dass eine Aktivierung des Icons dem Refresh des Browsers nachkommt und eben funktioniert (hat damit zu tun, dass ich die Session-Prüfung gesalzen habe).
Zuviel Salz in der Suppe ist eben auch nicht das wahre.
Naja - ich persönlich kann mit dem Ergebnis gut leben und hoffe, dass es dem einen oder anderen auch gefällt.
Den jetzigen Prototyp habe ich auf, bzw. mit der FB entwickelt. Danke nomml an Ralf Friedl für den Tip bzgl. nfs
Das Archiv enthält die Verzeichnisse wie sie im Freetz-Buildsystem verwendet werden (also root, source, etc.).
Da ich haserl gepanscht habe, verwende ich das aktuelle Paket (0.9.26), das aber auch mit dem freetz 1.1.3 problemlos zusammenspielt. Haserl und getText muss mit in die Firmware aufgenommen werden.
Das Verzeichnis /usr/mww habe ich manuell per nfs auf der FB eingebunden. Dazu habe ich mir ein Script startWork geschnitzt:
Code:
#!/bin/sh
/etc/init.d/rc.webcfg stop
modprobe nfs
mount <server-ip>:/proto-II/root/usr/mww /usr/mww -t nfs -o timeo=14,intr
/etc/init.d/rc.webcfg start
Damit der webserver beim Neustart auch die Konfiguration des Prototypen verwendet, habe ich folgende Links auf der FB gesetzt:
Code:
ln -s /usr/mww/conf/htmltext_de.fa /var/htmltext.fa
ln -s /usr/mww/conf/fapasswd /var/mod/etc/fapasswd
ln -s /usr/mww/conf/httpd_conf /var/tmp/flash/httpd_conf
Das conf-Verzeichnis wird vom WebIF nicht verwendet und ist per Kennwort geschützt. In dem conf-Verzeichnis liegt auch die Datei mit den Sprachtexten, die mit dem beiliegenden Script ins Binärformat übersetzt werden kann.
Dazu muss vom Paket htmltext das Tuhl createDB (auf dem PC) übersetzt und nach /usr/local/bin kopiert werden.
Was tut:
- Login + Layout-Wechsel (admin und rednose)
- die Layouts unterscheiden sich nicht nur in Farben, sondern auch in Seitenverhalten und -Inhalt
- Statusseite (mit echten Daten)
- Netzwerk -> Dienste (echter Status)
- System -> Logausgaben (nur admin)
Jetzt hoffe ich, dass ich nix Wichtiges vergessen habe und wünsche viel Spaß beim Ausprobieren.
Gruß Gero
P.S.: Ackso: admin hat das Kennwort Freetz, der Benutzer "rednose" keines.
P.P.S: Noch ne Info zu den Änderungen/Erweiterungen:
haserl hat ein neues Sprach-Kürzel bekommen: <%m Schlüssel %> kann verwendet werden, um Texte aus der Sprachdatenbank zu lesen. Der aktuelle Stand erlaubt Schlüssel mit einer Länge von bis zu 5 Zeichen. Ich denke, das ist ein akzeptabler Kompromiss zwischen Lesbarkeit und Dateigröße.
Ich vermute mal, dass AVM die Schlüsseltabelle in den webcm kompiliert hat, sodass andere Schlüsselvarianten möglich sind.
Um die gleiche Funktionalität in haserl-Scripten und CGI-Shellscripten zu erreichen, gibt es das Paket htmltext, welches das kleine Werkzeug getText liefert. <%m Schlüssel %> entspricht einem "getText Schlüssel", wobei als Standard die Datenbank /var/htmltext.fa verwendet wird. Eine andere Datei kann über Parameter angegeben werden.
Messungen zum Seitenaufbau haben ergeben, dass die Unterschiede zwischen statischen Texten und Texten aus der Datenbank unterhalb der Messgenauigkeit liegen.
Vom Paket htmltext ist getText vorgesehen, in die Firmware gepackt zu werden, während createDB nur für die Verwendung am PC vorgesehen ist.
Zu den Bildern (von links nach rechts):
- Einstiegseite des WebIF
- Statusseite (Benutzer rednose)
- Statusseite (Benutzer admin)
Vorschau:
- Logausgaben (Benutzer rednose)
- Logausgaben (Benutzer admin)
- Übersicht der Netzwerk-Clients / Kindersicherung
Änderungen gegenüber dem bisherigen WebIF:
abgesehen von dem offensichtlichen, gibt es auch funktionale Unterschiede:
Beim Freetz-WebIF geht jedes CGI-Script davon aus, dass es die ganze Seite im Browser darstellt. Dafür gibt es dann ja auch libmodcgi, bzw. cgi_begin und sec_begin.
Dieser Ansatz entstammt dem üblichen Schnellschuss und ist leider sehr weit verbreitet (ich habe es in meinem ersten Prototypen ja genausso gemacht). Echte Layout-Unterstützung lässt sich aber nur durch IOC (inversion of control) erreichen. Das ist etwas aufwändiger im Konzept, dafür erreicht man alle Freiheiten in der Gestaltung.
Der jetzige Prototyp funktioniert so. Haserl ist der "Einstiegskontroller", sodass die Verarbeitung der CGI-Variablen schon erfolgte und diese einfach dem Environment entnommen werden können. Die eigentlichen CGI-Scripte können Shell- und/oder Haserl-Scripte sein. Wer die Statusseite anschaut, wird feststellen, dass die Inhalte unterschiedlich sind, je nach Layout. Gemeinsame Bereiche werden gemeinsam verwendet, eigene Bereiche einfach ergänzt. Ein Hoch auf die Links im Unix-Dateisystem
Für die Seiten bedeutet dies, dass sie keine Annahmen über das machen dürfen, was sie umgibt. Sie müssen davon ausgehen, dass sie einen Bereich zur Verfügung gestellt bekommen, in dem sie sich darstellen können.
Habe mir noch Gedanken über eine mögliche Migration gemacht. Ich denke, wenn man cgi_begin und Co zu Nops ändert, sollte das meiste schon funktionieren. Vielleicht müsste ich noch ein paar Anpassungen machen, um exec-Scripte vor der Anzeige zu ermöglichen.
Ich denke, das technische Fundament ist da, sodass ich mir eine Diskussion über das weitere Vorgehen wünsche.
Was ich nicht möchte, ist eine one-man-show - aber das sagte ich ja bereits an anderer Stelle.
Anhänge
Zuletzt bearbeitet: