Erstellt vor 8 Jahren

Zuletzt geändert vor 6 Jahren

#1011 assigned enhancement

Mehrere Konfigurationsseiten pro Paket

Erstellt von: buehmann Verantwortlicher: buehmann
Priorität: normal Meilenstein: freetz-future
Komponente: webinterface Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

Ich würde gerne das System der Konfigurationsseiten erweitern, so dass man mehrere pro Paket registrieren kann. Das ließe sich nutzen, um die ziemlich längliche Freetz-Einstellungsseite in kleinere, thematisch zusammenhängende aufzuteilen. Außerdem habe ich im Callmonitor seit längerem eine zweite Seite (Rückwärtssuche-Anbieter) "simuliert", was sich langsam rächt. ;-)

Jede Seite bearbeitet eine Teilmenge der Variablen in package.cfg

Notwendige Änderungen:

  • modreg conf ähnlich zu file/status/extra: Identifizierung über Paket + ID. modreg cgi bleibt rückwärtskompatibel, indem eine Standard-ID vergeben wird (index oder main oder ähnlich) und der bisherige Standardpfad genutzt wird.
  • Erweiterung der URL von /cgi-bin/conf/pkg auf /cgi-bin/conf/pkg/id; Erweiterung von href
  • Anpassung des WebIF: edit + save

Probleme:

  • Zurücksetzen auf Standardeinstellungen ist entweder verwirrend (alles wird zurückgesetzt, nicht nur die aktuelle Seite) oder schwer umzusetzen (was soll zurückgesetzt werden?). ⇒ Vorschaltseite mit Warnung, dass ein kompletter "Werksreset" des Pakets gemeint ist?

Anhänge (3)

spoiler.jpg (32.5 KB) - hinzugefügt von cuma vor 8 Jahren.
Spoiler-Artwork :)
Ausblenden_02.png (117.9 KB) - hinzugefügt von MaxMuster vor 8 Jahren.
Screenshot eingeblendet
skin.patch (747 Byte) - hinzugefügt von MaxMuster vor 8 Jahren.
Skin-Patch

Alle Anhänge herunterladen als: .zip

Änderungshistorie (17)

comment:1 Geändert vor 8 Jahren durch oliver

Ich nehme an, dass sowas auch für dtmfbox benötigt wird?

Bei den mod-Seiten sehe ich den Vorteil, dass man nicht immer alle Dienste neu starten müsste.

Da wäre dann auf jeder der Config-Seiten ein eigener Übernehmen-Button? Und bei einer Einstellungsänderung auf mehreren Seiten müsste man da mehrmals drauf drücken und den Dienst neu starten?

comment:2 Geändert vor 8 Jahren durch buehmann

Was für dtmfbox benötigt wird, weiß ich nicht; hab's mir noch nicht angesehen.

Zu den Diensten: Diese Änderung wäre unabhängig davon; so, wie ich mir das momentan vorstelle, würde genau so viel neu gestartet wie vorher. (Kann man mit den Einstellungen in package.save eigentlich schon irgendwie beeinflussen, was bzgl. Neustarts beim Speichern passiert?)

Ja, jede Seite hätte einen Übernehmen-Button. Und ja, jedes Übernehmen würde nach dem momentanen Modell einen Neustart auslösen.

Fazit: Die Bearbeitung der Frage, wie man die Neustarts beim Konfigurieren verfeinern kann, sollte wohl als nächstes auf die Agenda. Zunächst würde ich erst mal den Schritt zu mehreren Seiten machen, die sich so verhalten wie bisher die eine.

comment:3 Antwort: Geändert vor 8 Jahren durch cuma

Wie wäre es mit einer "Spoiler"-Funktion? Dann sind alle Einstellungen auf einer Seite, sichtbar/aufgeklappt aber nur der ausgewählte Bereich. Bei 1. Aufruf der Seite sieht man zuerst nur den obersten Bereich.
Es gibt dann keine Probleme beim partiellen Speichern, und dass "zurücksetzen" für alles gilt sollte jedem klar sein und ist unproblematisch umzusetzen.

package.save: Da kann man alles hineinpacken was einem einfällt. Jede Funktion ist überschreibbar.

PS: Sollten nicht die anderen Problem mit dem Webif zuerst gelöst sein, bevor noch etwas neues dazukommt?

Geändert vor 8 Jahren durch cuma

Spoiler-Artwork :)

comment:4 Geändert vor 8 Jahren durch buehmann

Ok, auch eine Idee; das würde dann nur die Darstellung der bisherigen einen Einstellungsseite betreffen (sobald die "Bereiche"/Tabs irgendwie ausgezeichnet sind).

package.save: Ich habe gerade mal reingeschaut: Durch die überschreibbaren Funktionen kann man Zusätzliches ausführen, aber das Neustarten der Dienste passiert immer, oder?

@PS: Welche Probleme mit dem Webif konkret? #1008, #968 (und ggf. weitere Auswirkungen von #988); welche noch?

comment:5 Geändert vor 8 Jahren durch cuma

Ich könnte mir sowas noch für andere Pakete mit langen Konfigurationsseiten vorstellen, zB tor, rrdstats, Freetz, lighttpd, vsftpd

aber das Neustarten der Dienste passiert immer, oder?

"Müsste" so sein, hab noch nichts anderes festgestellt…

Webif

Ja, die genannten und dann noch die Breite von internen Seiten, wie zB wenn man in "System" auf "Reboot" klickt kommt man danach auf eine zu schmale Seite (vermutlich gleiches wie Seiten mit eigenem httpd).
EDIT: Mit r5651 gelöst
Und dann sind da noch viel überflüssige Links auf ehemalige "files"

comment:6 Geändert vor 8 Jahren durch buehmann

Richtig, der letzte Punkte (die schwankende Breite) war mir auch schon aufgefallen …

comment:7 Geändert vor 8 Jahren durch schlimmchen

(die schwankende Breite)

Ja das war wohl mein Denkfehler und bringt cuma auch wie erwünscht das alte Verhalten wieder bzgl. rrdstats, richtig? Cuma und mein Disput wäre damit wohl gefixed ;)

Bezüglich dieses Tickets:

Wäre es möglich, pro Paket mehrere Daemons zu haben (und dann mehrere Konfigurationsseiten, eine für jeden) und jeder Daemon hätte eine eigene rc und diese wäre dann auch spezifisch für die Konfigurationsseite? Ich denke da natürlich an vnstat/rrdstats. Konfigurationsseite für vnstat selbst und eine andere im gleichen Paket für httpd-vns. Das wäre eine tolle Sache in Richtung modhttpd/libmobrc-httpd, so wie ich es mir gerade vorstelle.

comment:8 Geändert vor 8 Jahren durch buehmann

Mehrere Dämonen pro Paket haben wir schon (auch mit mehreren RC-Skripten), Beispiel ist Samba.

Eine 1:1-Zuordnung von Dämonen zu Konfigurationsseiten scheint mir zu strikt zu sein; dann lieber n:m.

comment:9 Geändert vor 8 Jahren durch cuma

(die schwankende Breite)

ich habe darauf in Ticket #988 geantwortet, passt da besser

pro Paket mehrere Daemons

Das würde an vielen Stellen Änderungen nach sich ziehen, so wird (fast?) überall von etc/init.d/rc.$PACKAGE ausgegangen. Die Funktion zum Speichern müsste man dann auch überarbeiten und ein Package könnte dann mehrere .cfg-Dateien haben. Glaube der Aufwand lohnt sich nicht, da dies nur 2 Packages nutzen würden. Falls wirklich nötig, evtl wie bei Samba eine Wrapper-rc.? Ich denke dass man das am besten nach dem httpd-Wrapper-Ticket beurteilen kann

Bei Samba ist die Besonderheit, dass es zwar 2 Daemons hat, beide aber die gleiche Konfigurationsdatei und somit einfach auch die gleich Freetz-.cfg nutzen können. Da wären mehrere .cfg hinderlich, da manches doppelt nötig wäre

comment:10 Geändert vor 8 Jahren durch buehmann

  • Status von new nach assigned geändert
  • Verantwortlicher auf buehmann gesetzt

comment:11 Geändert vor 8 Jahren durch buehmann

(In [5672]) Basic support for multiple config pages per package; refs #1011.
(Test case: Freetz/Web interface)

comment:12 Geändert vor 8 Jahren durch buehmann

  • Meilenstein von freetz-1.2 nach freetz-1.3 geändert

comment:13 als Antwort auf: ↑ 3 Geändert vor 8 Jahren durch MaxMuster

Replying to cuma:

Wie wäre es mit einer "Spoiler"-Funktion? Dann sind alle Einstellungen auf einer Seite, sichtbar/aufgeklappt aber nur der ausgewählte Bereich. Bei 1. Aufruf der Seite sieht man zuerst nur den obersten Bereich.
Es gibt dann keine Probleme beim partiellen Speichern, und dass "zurücksetzen" für alles gilt sollte jedem klar sein und ist unproblematisch umzusetzen.

Da das Thema hier schonmal angesprochen war, schiebe ich dank des Hinweises von cuma meinen Vorschlag vom #1116, der mit "gleichen Argumenten" in die gleiche Richtung geht, mal nach hier:

[…] Meine Idee/Frage wäre, ob man nicht Sektionen ein- und ausblendbar machen sollte? Ich wollte das erst mit einem (+) oder (-) nach dem Titel zum Klicken, dazu fiel mir aber auf die Schnelle nix ein, deshalb mal ein anderer Ansatz, nur mal als "Anregung", vermutlich können die HTML/CSS - Experten was besseres bieten…

Im Anhang mal ein Screenshot und ein Patch, so ging das recht einfach und die Idee sollte klar werden…

Das andere Ticket mache ich dann mal zu.

Geändert vor 8 Jahren durch MaxMuster

Screenshot eingeblendet

Geändert vor 8 Jahren durch MaxMuster

Skin-Patch

comment:14 Geändert vor 6 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.