2016-04-24 7 views
2

Je mehr ich darüber nachdenke, ich frage mich, warum sollte jemand die defaults/preferences/*. Js-Datei verwenden, um Standardwerte einzustellen, statt die Standardeinstellungen in JavaScript zu setzen?Warum Standardeinstellungen/Voreinstellungen/* .js vs Einstellung Firefox Add-on Standardeinstellungen in JavaScript?

Ich arbeite an einem älteren XUL/Overlay-basierten Add-on, das von jemand anderem erstellt wurde. Es verwendet zusätzlich eine prefs.js-Datei, um alle Standardwerte im JavaScript zu setzen (falls prefs.js fehlgeschlagen ist) ein unerklärlicher Grund?), der im Wesentlichen alle Präferenzen direkt nach der Installation in Benutzereinstellungen umwandelt. Dies verwirrte mich zunächst, da die Standardeinstellungen beim Betrachten der Einstellungen in about:config als modifiziert (benutzerdefiniert) angezeigt wurden. Dann stellte ich fest, dass es bedingungslos einige der Standardeinstellungen (sehr große Zeichenfolgen) festlegte.

So erkannte ich, nicht nur ich die gleichen prefs in 3 Standorten pflegen (prefs.js, Schnittstelle und Content-Skripte), aber die prefs.js Datei ist weitgehend redundant, die scheint, zusätzliche Wartung ohne Grund hinzuzufügen. Das scheint einfach albern zu sein, und ich suche nach einem besseren Weg, um einfach Einstellungen zu speichern und sie an einem Ort zu verwalten (was wahrscheinlich der Grund ist, warum die prefs.js exklusiv verwendet werden sollten).

Nun, ich weiß, diese Frage hat das Potenzial, als "Meinung" gekennzeichnet zu werden, und kann oder kann nicht eine spezifische "richtige" Antwort haben. Aber ich denke, es ist eine gültige Frage, und ich würde gerne mehr über die Vor- und Nachteile der Verwendung einer prefs.js-Datei erfahren, anstatt alle Einstellungen während der Initialisierung in einem gemeinsamen JS-Code festzulegen. Gibt es irgendwelche Leistungsbedenken oder eine objektive Liste von Kriterien, anhand derer ich diese Feststellung treffen könnte? Ist es möglich, dass der prefs.js-Mechanismus jemals fehlschlagen würde? Ist es sicher anzunehmen, dass es niemals scheitern wird? War es in den FF 1.0-3.5 Tagen anfälliger für Fehler?

+1

Ich persönlich benutze 'defaults/preferences' Ich halte die Standardwert in js, und wenn die Präferenz nicht vorhanden ist, verwende ich den Standardwert von meiner js. Ich habe das Gefühl, dass es keine Notwendigkeit gibt, eine Datei durcheinander zu bringen, auf die synchron zugegriffen wird, wenn die Information bereits in meinem Code ist. Es liegt also wirklich an dir. Ich persönlich finde es besser, es ohne defaults/pref/*. Js zu machen - aber der Unterschied ist unermesslich (ich habe es noch nicht einmal versucht). – Noitidart

+1

Danke für die Perspektive. Ich bin immer noch ziemlich neu in der Entwicklung von Add-Ons, und wenn ich mehr darüber lerne, scheinen manche Dinge verwirrend oder albern zu sein. Dann frage ich mich, ob ich etwas vermisse aufgrund meiner Ignoranz und Unerfahrenheit, oder ob es etwas ist, das andere besser bemerkt und behandelt haben als ich. Die Ärzte schreien alle auf und ab, "stellen Sie sicher, dass Sie alle Ihre Präferenzen dort haben, vergewissere dich, nicht wirklich, mach es, stell sicher, dass du es tust, hast du es getan, du hast es getan, oder? Dann gehst du und findest heraus, dass es genauso überflüssig ist wie du dachtest, oder etwas schlechter. Ich habe es benutzt, kann aber später zurückkehren. – user314159

+1

Das Problem mit den 'defaults/preferences' ist, dass es kein JavaScript ist. Nur eine verklärte Klartextkonfiguration, mit strenger Syntax und minimaler Typprüfung. Keine Ausführung.Wenn Sie eine Voreinstellung zur Laufzeit basierend auf Systemparametern auswählen möchten, haben Sie Präferenzcode, der sich in den Add-on-Code einschleicht und Unordnung aufbaut. Wo könnten Sie ein Modul mit allen Voreinstellungen und allen Objekten, Methoden und Eigenschaften erstellen, die für die Verwaltung benötigt werden? Das scheint einfacher zu sein, zu warten, zu debuggen und zu rezensieren usw. Jeder mit gegenteiligen Ansichten, mit guten Gründen höre ich zu. – user314159

Antwort

0

Standardeinstellungen:

  • Kann in einer neuen Version des Add-on ohne Überschreiben der Wert explizit vom Benutzer eingestellten geändert werden.
  • Ordnen Sie das Profil des Benutzers nach der Deinstallation des Add-ons nicht an.
  • Befinden sich an derselben Stelle, nicht verstreut über den Code. Es ist leicht zu sehen, welche Vorlieben es gibt. Sie erscheinen auch in "about: config", was Ihnen erlaubt, eine Benutzeroberfläche für "versteckte" Einstellungen zu haben - für Power-User.

Es ist schade, sie nicht bekommen * Pref API den Standardwert, falls der vom Benutzer eingestellten Wert ist ungültig Rückkehr gemacht haben, und ich verstehe, will nicht die Standard-an zwei Orten zu halten. Diese ganze API wurde vor langer Zeit "eingefroren", und wird schließlich mit dem Rest von XPCOM weggehen, so ist es nicht wirklich wichtig ...

+0

In meinen Fragen und Kommentaren verweise ich auf die Verwendung der Standard-Prefs-Datei, die für die Verteilung/Installation verwendet wird, und nicht auf den Laufzeitmechanismus der Standard-Prefs-Verzweigung. Ich habe festgestellt, dass sowohl der Name als auch der Typ meiner Standard-Prefs-Datei nicht verwendete oder defekte (bzw.) Benutzer-Prefs hinter sich gelassen haben, selbst nach der Deinstallation. Außerdem wurden mehr als die Hälfte der Einstellungen nie in die Standard-Prefs-Datei aufgenommen. Also war keiner Ihrer Punkte meiner Erfahrung nach gültig. Aber der letzte Punkt ist praktisch als Entwickler und Fehlerbehebung geplante Updates usw. Aber ja, es ist jetzt am Ende des Lebens. – user314159

+0

Was ich aus der Verwaltung der Einstellungen gelernt habe, war, dass es Sache des Programmierers ist, die Standardeinstellungen an einem praktischen und sichtbaren Ort zu speichern. Um Änderungen an Vornamen oder Typen vor dem Laden zu berücksichtigen. Ich bin hier vielleicht über Bord gegangen, behalte aber einen "change buffer", ein kleines Objekt, das die minimalen Details über solche Änderungen enthält, die ich an eine updatePrefs-Methode meines eigenen prefs-Objekts mit einem generischen getPref übergebe. Aber eine generische setPref ist zwecklos. Von XUL-Elementen gezogene INTs sind Zeichenfolgen. FLOATS und UNSIGNED INT (Zeitstempel) werden als STRINGS gespeichert, da Prefs INT nur signiert ist. – user314159

+0

Wenn ich also entscheide, dass ich Prefs von einem Zweig in einen anderen verschieben oder die Namen so ändern muss, dass sie selbstdokumentieren, oder den Code ändern, um einen anderen Datentyp zu benötigen, gebe ich solche Details in mein kleines Einstellungs-Prefs-Objekt ein es zu meiner Methode hinzufügen, neue Namen hinzufügen, alte Werte kopieren, Datentypen konvertieren, alte Vornamen löschen oder alte Zweige löschen. Also wird jeder Benutzer, der während meines Revivals zu diesem Add-On zurückkommt, keine merkwürdigen Fehler bekommen, basierend auf größeren Änderungen an der Art, Namen, Werten oder Methoden zum Abrufen und Festlegen von Einstellungen. Basierte Nicht-GUID-Einstellungen für den GUID-spezifischen Speicherort für SDK – user314159