CURARE LA UI CON BOOTSTRAP E FONTAWESOME
Per migliorare la UI quello che possiamo fare come sviluppatori è quello di procurarci librerie lato client come Bootstrap e Fontawesome per migliorare la parte grafica del sito web.
Bootstrap mette a disposizione una griglia di dodici colonne. Se prendiamo la classe .col-xl-4 la sua larghezza sarà di 1/3 della griglia se lo schermo dell’utente è xl, cioè extra large.
Se la finestra del browser dovesse ridursi gli elementi verranno organizzati uno sotto l’altro.
Per utilizzare Bootstrap occorre scaricare un file CSS e le librerie Javascript che danno regole stilistiche. Normalmente vengono scaricati da una CDN (Content Delivery Network), il vantaggio è che questi server contenenti i file sono utilizzati moltissimo quindi è facile che nella cache del Browser siano già memorizzati. Andiamo a copiare i file dal seguente link: https://getbootstrap.com/docs/5.3/getting-started/introduction/ Copiare i file nella View di Layout in quanto vogliamo che questi file siano presenti in tutte le pagine. Inseriamo una navbar, per ulteriori informazioni guarda il mio corso su Bootstrap 5. La stessa cosa fatta per Bootstrap la possiamo fare per Fontawesome che sono essenzialmente dei font web e delle icone da inserire nei pulsanti per meglio comprenderne il ruolo.
I TAG HELPER
I tag Helper vengono elaborati dal View Engine Razor e sono arricchiti di altri attributi che non abbiamo in HTML come ASP-ACTION e ASP-CONTROLLER del tag Anchor. Uno dei vantaggi nell’usare questi tag è che la View rimane estremamente leggibile.
Vediamo il tag Anchor. Questo tag genera un indirizzo dinamico in base ai parametri forniti.
Vediamo la variante per le Razor pages.
Prima di usare i Tag Helper dobbiamo creare una View chiamata _ViewImports.cshtml, vediamo la suddivisione in directory.
Questo è un altro Tag, Environment molto importante.
Vediamo la controparte exclude.
CREARE LA VIEW DEL CATALOGO DEI CORSI
Vediamo un’immagine riepilogativa di ciò che andremo a realizzare. Al momento non attingendo ancora i dati da un database utilizzeremo dati fittizi.
Se vogliamo che la View sia responsive dobbiamo usare il grid system di Bootstrap.
RIEPILOGO DELLA SEZIONE
Nel pattern MVC, le view hanno la responsabilità di presentare in HTML i dati che vengono forniti dal controller. Oltre al codice HTML, le view possono contenere codice C# a supporto della presentazione dei dati (cicli for per scorrere una lista, blocchi if per mostrare/nascondere una porzione di markup, e così via).
In ASP.NET Core MVC, le view sono dei file che hanno un’estensione .cshtml che indica per l’appunto che in esse possiamo inserire sia codice HTML che codice C#.
Le view devono essere “stupide”. Per nessun motivo dovrebbero contenere codice di accesso al database, di invio e-mail, o di qualsiasi altra attività che richiede la comunicazione con il mondo esterno perché queste sono responsabilità del model. Inoltre, sarà il controller che, in qualità di coordinatore, dovrà sfruttare il model per fornire alla view tutti i dati che le servono, né più, né meno.
Razor è il nome del view engine di ASP.NET Core MVC, cioè del componente che si occupa di elaborare il file .cshtml per generare il contenuto finale della pagina.
View di contenuto e view di layout
Le view si trovano all’interno della directory /Views del progetto. Servono a due scopi principali:
- Le view di contenuto sono create per aiutare le singole action a produrre dinamicamente del contenuto HTML. Per questo, se vogliamo seguire la convenzione di nomi di ASP.NET Core MVC, dovremmo dare alla view lo stesso nome dell’action e inserirla in una sottodirectory che si chiama come il controller. Ad esempio, la view relativa all’action Index del CoursesController è preferibile che sia creata in /Views/Courses/Index.cshtml;
- Le view di layout sono anch’esse dei file con estensione .cshtml e contengono gli elementi comuni dell’applicazione web come l’header, il menu di navigazione, footer e così via. Per rispettare la convenzione di nomi, è preferibile creare una view di layout in /Views/Shared/_Layout.cshtml. Possiamo avere più di una view di layout, quindi non è obbligatorio rispettare questo nome. Anche l’uso dell’underscore è consigliato (ma non obbligatorio) e serve soltanto a far capire che il contenuto di questa view è riutilizzato e condiviso da altre view, come indica anche la directory Shared in cui si trova.
Ogni view di contenuto può scegliere quale view di layout usare. È sufficiente mettere in cima al file questa istruzione.
- @{
- Layout = “_Layout”;
- }
Per evitare di ripetere questa istruzione in tutte le view di contenuto, la possiamo spostare all’interno di un file /Views/_ViewStart.cshtml, che verrà eseguito prima che ogni view di contenuto sia elaborata.
All’interno della view di layout, aggiungiamo invece un’istruzione @RenderBody() per indicare il punto in cui sarà incastonato l’output HTML prodotto dalla view di contenuto.
Sezioni aggiuntive nella view di layout
Una view di layout può anche definire delle sezioni aggiuntive. Un esempio tipico è quello di una sezione chiamata “Scripts” in cui la view di contenuto potrà inserire del codice JavaScript, che è buona pratica inserire subito prima del tag di chiusura </body>. Ecco un esempio: nella view di layout usiamo @RenderSection(“Scripts”, required: false) per indicare che lì saranno incastonati i contenuti della sezione “Scripts”.
Possiamo definire quante sezioni preferiamo, con nomi qualsiasi.
I tag Helper
I tag helper sono all’apparenza dei normalissimi tag come a, form o input ma possiedono degli attributi aggiuntivi che ci aiutano a produrre il contenuto HTML nella view. Ad esempio, con il tag helper a (anche chiamato tag helper anchor) possiamo usare gli attributi asp-action, asp-controller o asp-page per creare un link indicando il nome dell’action, del controller o della Razor Page, anziché andare a valorizzare il suo attributo href. In questo modo riusciamo a esprimere meglio il nostro intento.
I tag helper riducono l’uso del codice C# nella view e questo migliora la leggibilità del codice HTML. Così possiamo anche coinvolgere i nostri colleghi designer che, pur non avendo competenze in C#, magari sono molto abili a impaginare in HTML e perciò ci possono dare una mano. Dovremo giusto chiedergli di fare attenzione a non eliminare gli attributi che hanno il prefisso asp-.
Nel corso delle lezioni incontreremo vari tag helper e scopriremo i vantaggi che offrono. Poi, ne costruiremo uno personalizzato per sfruttare al massimo le loro potenzialità!
Usare librerie per lo sviluppo client come Bootstrap e Fontawesome
Progettare una UI usabile e gradevole per l’utente non è un compito semplice: ci sono professionisti specializzati in questo settore che possono aiutarci a realizzare un’applicazione di ottima qualità. Noi, come sviluppatori, il minimo che possiamo fare è procurarci delle librerie che ci guidano nella giusta direzione:
- Bootstrap offre un insieme di componenti e regole CSS che migliora l’aspetto grafico e la fruibilità dei contenuti. Il suo sistema di layout ci permette di creare pagine responsive, che si riorganizzano per adattarsi alla risoluzione dello schermo;
- FontAwesome è un webfont che contiene tante icone vettoriali che possiamo usare nei nostri menu e sui nostri bottoni per comunicare meglio il loro scopo.
Per imparare a usare queste librerie possiamo consultare i rispettivi siti web, dove è riportata la documentazione e gli esempi. Per aggiungerle alla nostra applicazione, possiamo seguire uno o entrambi questi approcci:
- Referenziarle da un CDN come cdnjs o unpkg. I CDN aiutano le nostre pagine a caricarsi più in fretta perché l’utente potrebbe avere già in cache quella libreria, se in precedenza aveva visitato un altro sito che ne faceva uso;
- Ottenerle con LibMan. LibMan è uno strumento da riga di comando che si installa con dotnet tool install -g Microsoft.Web.LibraryManager.Cli. Ci permette di scaricare i file delle librerie nel nostro progetto con comandi come LibMan install font-awesome. In questo modo, tutti i file vengono scaricati localmente e serviti dall’applicazione ASP.NET Core. Perciò, non dipendiamo da CDN di terze parti.
Possiamo sfruttare entrambi gli approcci usando il tag helper environment: mentre siamo in sviluppo usiamo le librerie che abbiamo ottenuto grazie a LibMan, così non sarà necessaria la connessione a internet. Completato lo sviluppo, allora sfrutteremo i CDN.
Grazie agli attributi include ed exclude del tag helper environment possiamo mostrare o nascondere dei blocchi di codice HTML in base al nome dell’ambiente.
Scrivi un commento