Verwendung von javax.faces.PROJECT_STAGE
Ich wollte die Auswirkungen der 'javax.faces.PROJECT_STAGE'-Eigenschaft für eine JSF-Anwendung verstehen. Ein Nizza-Anwendungsfall wurde in den folgenden Links dargestellt
http://css.dzone.com/news/jsf-20-new-feature-preview-ser
http://www.Java-tutorial.ch/Java-server-faces/jsf-project-stage
Gibt es einen anderen Anwendungsfall, bei dem diese Eigenschaft wirklich hilfreich ist, abgesehen von der Anzeige von Überprüfungsfehlern? Ich verstehe, dass wir diese Variable überprüfen können, um die Umgebung zu identifizieren und bestimmte Funktionen zu ändern. Gibt es jedoch noch etwas, was JSF automatisch tut, um Entwicklern zu helfen? Wäre es toll, wenn Sie die Erfahrungen aus Ihrem Projekt teilen könnten?
Das Festlegen dieses Parameters auf Development ermöglicht bessere Fehlermeldungen, auch im clientseitigen JavaScript, jedoch auf Kosten der Leistung.
Wenn Sie diesen Parameter auf Production setzen, werden einige Fehlermeldungen deaktiviert und die Leistung hervorheben .
Entsprechend der comment von wutzebaer für kann dieser verknüpfte Beitrag die javax.faces.PROJECT_STAGE -Eigenschaft steuern, ob bestimmte Funktionen aktiviert sind (z. B. das Zwischenspeichern von Ressourcen).
Wenn wir PROJECT_STAGE als Produktion festlegen, erhalten wir eine bessere Fehlermeldung. Wenn wir beispielsweise das h: form-Tag um Eingabefelder verpasst haben, wird möglicherweise eine Fehlermeldung angezeigt, wenn die Stufe als Entwicklung festgelegt ist und wenn die Stufe als Produktion (oder eine beliebige) festgelegt ist anderer Wert als Entwicklung), wir erhalten keine Fehlermeldung.
Die Formularkomponente muss eine UIForm in ihrer Herkunft haben. Vorschlag: Fügt die erforderlichen Komponenten in
<h:form>ein
Cache-Busting für Ressourcen während der Entwicklung
Unter Ressourcen verweise ich auf statische Ressourcen wie Stylesheets, Javascript-Bibliotheken, Logos und Piktogramme usw.
Standardmäßig werden Ressourcen ohne Ablaufen des Caches geladen (verfällt bei maximalem Alter oder etwas mehr). Dies ist so, da Ressourcen als statisch angenommen werden, da sie sich während der Lebensdauer des Servlet-Containers nicht ändern. Wir profitieren auf diese Weise vom Caching dieser Ressourcen auf der Clientseite (Webbrowser-Caching).
Wenn Sie jedoch eine neue Version einer Bibliothek freigeben, die möglicherweise eine Gruppe von Ressourcen einschließt, möchten wir nicht, dass Benutzer mit der alten Version einer Ressource hängen bleiben. Normalerweise werden Implementierungen und gemäß der Spezifikation automatisch der Bibliotheksname und die Version als Abfrageattribute angehängt. Eine typische Ressource wird automatisch wie folgt ausgegeben:
<link type="text/css" rel="stylesheet" href="/nqp-web/javax.faces.resource/components.css.xhtml?ln=primefaces&v=6.2">
Dies wird durch Verwendung einer spezifischen Implementierung von Resource gehandhabt.
Wenn Sie also neue Versionen einer Bibliothek veröffentlichen, bleiben Ihre Benutzer nicht mehr mit alten Versionen von Ressourcen in ihrem Cache.
Während der Entwicklungsarbeit steigt die Version jedoch nicht an, Sie möchten jedoch trotzdem, dass der Cache vorzugsweise abläuft.
Die Standardimplementierung stellt normalerweise sicher, dass basierend auf dem Wert von javax.faces.PROJECT_STAGE, insbesondere mit DEVELOPMENT, das Verfallsdatum auf sofort gesetzt wird. Sie können das in Mojarras ResourceImpl zum Beispiel sehen:
long expiresTime;
if (FacesContext.getCurrentInstance().isProjectStage(Development)) {
expiresTime = new Date().getTime();
} else {
expiresTime = new Date().getTime() + maxAge;
}
Protokollierung
Wie @vrcca bereits erwähnt hat, zeigt eine Schnellsuche für Verwendungen von isProjectStage, dass dies meistens nur zusätzliche Protokollierung aktiviert, wenn DEVELOPMENT eingestellt ist.
Verweise
Eine weitere Funktion zum Festlegen von PROJECT_STAGE als Entwicklung besteht darin, dass wir auch unsere Änderungen in .xhtml-Dateien sehen können, ohne den Server neu zu starten.