Qual è la libreria di risorse JSF e come dovrebbe essere utilizzata?

I componenti JSF , e hanno un attributo di library . Cos’è questo e come dovrebbe essere usato? Ci sono molti esempi sul web che lo usano come segue con il contenuto comune / tipo di file css , js e img (o image ) come nome della libreria a seconda del tag usato:

    

Come è utile? Il valore della library in questi esempi sembra ripetere semplicemente ciò che è già stato rappresentato dal nome del tag. Per un si basa sul nome del tag già evidente che rappresenta una “libreria CSS”. Qual è la differenza con quanto segue che funziona anche allo stesso modo?

    

Inoltre, l’output HTML generato è leggermente diverso. Dato un percorso di contesto di /contextname e mapping di FacesServlet su un pattern URL di *.xhtml , il primo genera il seguente codice HTML con il nome della libreria come parametro di richiesta:

    

Mentre quest’ultimo genera il seguente codice HTML con il nome della libreria proprio nel percorso dell’URI:

    

Quest’ultimo approccio, a ben vedere, ha anche più senso del precedente approccio. Quanto è quindi utile l’attributo della library ?

In realtà, tutti quegli esempi sul web in cui il contenuto comune / tipo di file come “js”, “css”, “img”, ecc. È stato usato come nome della libreria è fuorviante .

Esempi di mondo reale

Per iniziare, diamo un’occhiata a come le implementazioni JSF esistenti come Mojarra e MyFaces e le librerie di componenti JSF come PrimeFaces e OmniFaces lo usano. Nessuno di loro utilizza le librerie di risorse in questo modo. Lo usano (sotto le copertine, da @ResourceDependency o UIViewRoot#addComponentResource() ) nel seguente modo:

         

Dovrebbe essere chiaro che rappresenta sostanzialmente la libreria / modulo / nome del tema comune a cui appartengono tutte quelle risorse.

Identificazione più facile

In questo modo è molto più facile specificare e distinguere da dove queste risorse appartengono e / o provengono. Immagina di avere una risorsa primefaces.css nella tua webapp in cui stai sovrascrivendo / ottimizzando alcuni CSS predefiniti di PrimeFaces; se PrimeFaces non usasse un nome di libreria per il suo primefaces.css , allora il suo proprietario PrimeFaces non verrebbe caricato, ma invece quello fornito da webapp, che spezzerebbe il look’n’feel.

Inoltre, quando si utilizza un ResourceHandler personalizzato, è ansible applicare un controllo più granulare più preciso sulle risorse provenienti da una libreria specifica quando la library viene utilizzata nel modo giusto. Se tutte le librerie di componenti avessero usato “js” per tutti i loro file JS, come mai ResourceHandler distinguerebbe se provenisse da una libreria di componenti specifica? Esempi sono OmniFaces CombinedResourceHandler e GraphicResourceHandler ; controllare il metodo createResource() cui la libreria viene controllata prima di debind al successivo gestore di risorse in catena. In questo modo sanno quando creare CombinedResource o GraphicResource per lo scopo.

Notato dovrebbe essere che RichFaces ha sbagliato. Non ha utilizzato alcuna library e ha creato un altro strato di gestione delle risorse su di esso ed è quindi imansible identificare a livello di programmazione le risorse RichFaces. Questo è esattamente il motivo per cui OmniFaces CombinedResourceHander dovuto introdurre un hack basato sulla riflessione per farlo funzionare comunque con le risorse RichFaces.

La tua propria webapp

La tua webapp non ha necessariamente bisogno di una libreria di risorse. Faresti meglio a ometterlo.

    

Oppure, se hai davvero bisogno di averne uno, puoi semplicemente dargli un nome comune più sensato, come “default” o il nome di qualche azienda.

    

Oppure, quando le risorse sono specifiche per un modello di Facelets principale, puoi anche dargli il nome del modello, in modo che sia più facile relazionarsi l’un l’altro. In altre parole, è più per scopi autodocumentari. Ad esempio in un file modello /WEB-INF/templates/layout.xhtml :

   

E un file modello /WEB-INF/templates/admin.xhtml :

   

Per un esempio reale, controlla il codice sorgente di OmniFaces .

Oppure, quando ti piacerebbe condividere le stesse risorse su più webapps e aver creato un progetto “comune” per quello basato sullo stesso esempio di questa risposta che a sua volta è incorporata come JAR in webapp’s /WEB-INF/lib , quindi anche riferimento come libreria (il nome è libero a tua scelta, anche le librerie di componenti come OmniFaces e PrimeFaces funzionano in questo modo):

    

Controllo delle versioni della libreria

Un altro vantaggio principale è che è ansible applicare la versione delle librerie delle risorse nel modo giusto sulle risorse fornite dalla propria webapp (questo non funziona per le risorse incorporate in un JAR). È ansible creare una sottocartella secondaria diretta nella cartella della libreria con un nome nel modello \d+(_\d+)* per indicare la versione della libreria di risorse.

 WebContent |-- resources | `-- default | `-- 1_0 | |-- css | | `-- style.css | |-- img | | `-- logo.png | `-- js | `-- script.js : 

Quando si utilizza questo markup:

    

Questo genererà il seguente codice HTML con la versione della libreria come parametro v :

    

Quindi, se hai modificato / aggiornato alcune risorse, tutto ciò che devi fare è copiare o rinominare la cartella della versione in un nuovo valore. Se si dispone di più cartelle di versione, JSF ResourceHandler servirà automaticamente la risorsa dal numero di versione più alto, in base alle regole di ordinamento numerico.

Quindi, quando copia / rinomina resources/default/1_0/* cartella in resources/default/1_1/* come segue:

 WebContent |-- resources | `-- default | |-- 1_0 | | : | | | `-- 1_1 | |-- css | | `-- style.css | |-- img | | `-- logo.png | `-- js | `-- script.js : 

Quindi l’ultimo esempio di markup genererebbe il seguente codice HTML:

    

Questo costringerà il browser a richiedere la risorsa direttamente dal server invece di mostrare quella con lo stesso nome dalla cache, quando l’URL con il parametro modificato è stato richiesto per la prima volta. In questo modo gli utenti finali non sono tenuti a eseguire un aggiornamento completo (Ctrl + F5 e così via) quando devono recuperare la risorsa CSS / JS aggiornata.

Si noti che il controllo delle versioni delle librerie non è ansible per le risorse racchiuse in un file JAR. Avresti bisogno di un ResourceHandler personalizzato. Vedi anche Come utilizzare il controllo delle versioni JSF per le risorse in jar .

Guarda anche:

  • Controllo delle versioni delle risorse JSF
  • JSF2 Memorizzazione nella cache statica
  • Struttura per più progetti JSF con codice condiviso
  • Specifiche JSF 2.0 – Capitolo 2.6 Gestione delle risorse