Override, Blog, Tostring, Webnetconf12, Webdev, Windows Phone, MVC, Beta, Ottimizzazione, Browser, Firefox, Razor, ViewEngine, Book, Review, Mobile, JQuery, Visual Studio, ASP.NET, HTML5, IE9, Internet Explorer

L’ultima release (attualmente in beta) di ASP.NET MVC, di cui abbiamo visto alcune novità qui e qui, introduce veramente molte feature interessanti, una delle quali è rappresentata dai Bundle.
Ormai noi tutti conosciamo l’importanza di ridurre al minimo il numero di richieste dal client verso il server. Quando parliamo di riduzione delle richieste, includiamo un po’ tutto: dai fogli di stile, ai javascript, e magari anche i dati tramite l’utilizzo di AJAX.

Per i primi due viene utilizzata la tecnica del “combine” e “minify” di più file in un’unica richiesta. Questo approccio consiste nel raggruppare tutti i files dello stesso tipo in un unico file, e nel rimuovere tutti gli spazi e commenti non necessari.

Tradotto in soldoni, tutte queste richieste che abbiamo nella pagina :

<script src="/Scripts/jquery-1.6.2.min.js"></script>
<script src="/Scripts/jquery-ui-1.8.11.min.js"></script>
<script src="/Scripts/jquery.validate.min.js"></script>
<script src="/Scripts/jquery.validate.unobtrusive.min.js"></script>
<script src="/Scripts/knockout-2.0.0.js"></script>

Diventano una sola

<script src="/Scripts/combined.js"></script>

Ovviamente lavorare con un file unico, che sia questo un file javascript o css, risulta un po’ scomodo e, proprio per questo motivo, esistono diversi tool/framework che agevolano la creazione di un unico file a runtime o compile time.

Con ASP.NET MVC 4 effettuare il “combine” e “minify” è veramente semplice: basta utilizzare un apposito metodo ed il gioco è fatto.

Guardiamo il seguente codice:

<link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/css")" rel="stylesheet" type="text/css" />
<script src="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Scripts/js")"></script>

È importante sapere che non tutti i files presenti nella folder specificata saranno inclusi nell’output del file, ma bensì solo quelli registrati nel bundle. In un prossimo post vedremo come creare bundle custom in modo da includere differenti file in differenti folder.

Stay tuned!

This entry was posted on Tuesday, 17 April, 2012 and is filed under MVC ASP.NET . You can follow any responses to this entry through here . You can leave a response.

Su segnalazione del buon Andrea, ho scoperto che, oltre ai “conditional attributes”, Razor introduce un’altra novità chiamata “Tilde Slash” ossia “~/”.

Il concetto è simile a quello espresso in un mio vecchio post su Spark (vedi qui), con la differenza che in Spark si può specificare un dominio differente (molto comodo se si usa CDN).

In ogni caso l’utilizzo del Razor, con il Tilde Slash, aiuta lo sviluppatore nella scrittura del codice prendendosi in carico l’onere di risolvere automaticamente la url, eliminando così le noiose ripetizioni del ResolveUrl.

Dando un occhio al codice, questo markup

<img src="@Url.Content("~/Content/mylogo.png")" />

con Razor v2 diventa semplicemente questo

<img src="~/Content/mylogo.png" />

Beh comodo no?

This entry was posted on Wednesday, 04 April, 2012 and is filed under MVC . You can follow any responses to this entry through here . You can leave a response.

Nel rilascio di ASP.NET MVC 4 è inclusa anche la nuova release dell’ormai diffusissimo Razor View Engine. Per chi non lo sapesse Razor è un “framework” che offre la possibilità di scrivere il codice presente nelle view con una sintassi differente da quella delle classiche pagine ASP.NET.

Prima di Razor, nel mondo Microsoft, l’utente era abituato ad utilizzare il WebFormViewEngine anche sotto ASP.NET MVC ma, essendo MVC molto orientato al testing, la scelta di creare un’alternativa è quasi d’obbligo.

Di fatto Razor non ha più una dipendenza verso System.Web.UI.Page, e di conseguenza dall’ HttpContext, Web Server (IIS), etc.

Questo permette allo sviluppatore di poter scrivere unit test anche per le View (quanti di voi lo hanno mai fatto?).

Dopo questa premessa sulla storia di Razor, andiamo a vedere cosa offre la nuova release J.

Al momento l’unica novità di rilievo che ho riscontrato è quella che dal team viene chiamata con il nome “Conditional Attribute”, ossia la possibilità di renderizzare o no un determinato attributo, il cui valore è dinamico, e quindi legato ad una variabile.

Per renderla più semplice, diamo un’occhiata al seguente codice:

<!-- Nome della classe css presa da una variabile -->
<p class="@myCssClass">.....</p>


<!-- markup necessario in caso la variabile sia nulla -->
<p>.....</p>

Come potete vedere, la variabile myCssClass viene utilizzata per impostare la classe css appunto, in base ad un qualcosa (un evento, un settaggio, etc) gestito server side.

Ma cosa succede se dovete gestire anche la possibilità di non impostare la classe?
Precedentemente a Razor V2 l’approccio sarebbe stato più o meno questo:

@{
    var myCssClass = (bool)ViewBag.IsBol ? "boldClass" : null;
}

@if(myCssClass != null){
    <p class="@myCssClass">@ViewBag.Text</p>
}
else{
    <p>@ViewBag.Text</p>
}

Al contrario, con la nuova release di Razor, diventa tutto più semplice. Se impostate il valore della variabile myCssClass a null l’attributo non viene renderizzato, in caso contrario si.

<p class="@myCssClass">@ViewBag.Text</p>

Bisogna prestare attenzione al fatto che il contenuto string.empty (nel caso di una stringa) renderizza ugualmente l’attributo, quindi solo null impedisce il rendering.

Nel caso di value type tipo il booleano, la situazione non cambia molto. In questo caso il true renderizza l’attributo checked, mentre il false no.

<!-- codice con -->

@{
    ViewBag.IsBol = true;
}

<input type="checkbox" checked="@ViewBag.IsBol" />

Razor Rulez!

This entry was posted on Tuesday, 03 April, 2012 and is filed under MVC ASP.NET . You can follow any responses to this entry through here . You can leave a response.