asp.net comments edit

Su segnalazione del buon Andrea, ho scoperto che, oltre ai “conditional attributes”, 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?

asp.net comments edit

Nel rilascio di ASP.NET MVC 4 è inclusa anche la nuova release dell’ormai diffusissimo Razor View Engine. Per chi non lo sapesse è 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!

various comments edit

lrg

È la prima volta che mi capita di fare la review di un libro e, per essere alla prima esperienza, devo dire che ho l’opportunità di farlo per uno dei migliori autori internazionali che il mondo tecnico possa avere, il Super Dino Nazionale aka Dino Esposito.

Il libro in questione è “Architecting Mobile Solutions for the Enterprise” e, come potete intuire dal nome, parla di mobile application.
Nonostante io abbia una predilezione verso le applicazioni web, questo libro mi ha subito affascinato perché affronta tematiche molto web oriented come HTML5, jQuery, etc per sviluppare applicazioni mobile.

Nell’ultimo periodo in azienda sono stato coinvolto nello sviluppo di applicazioni con queste caratteristiche (nel mio caso Sencha Touch al posto di JQuery Mobile, ma poco cambia) ed ho avuto modo di toccare con mano quanto Dino spiega.

Tornando al libro ho letto il capitolo sul responsive design, sia client-side tramite le media queries che server side con l’utilizzo di Wurfl, e devo dire che mi è piaciuto parecchio.

Dino è riuscito come sempre ad arrivare in profondità di concetti complessi, spiegandoli tuttavia in maniera del tutto semplice, il che rende ancor più appetibile il libro.

Purtroppo non posso entrare molto nei dettagli in quanto il libro non è ancora disponibile, ma potete effettuare il pre-ordine da qui.

asp.net comments edit

Chi come me si sta divertendo nel testare ASP.NET MVC 4 e lo sta facendo con Visual Studio 2011, avrà sicuramento riscontrato dei problemi di stabilità da parte dell’editor Razor che causa continui freeze della UI.

Tale problema non si verifica ogni qualvolta si cerca di editare una view realizzata con Razor, ma quando si cerca di indentare il codice HTML.
Inizialmente avevo attribuito il problema a Resharper, in quanto la versione installata è una super preview ma, una volta disinstallato quest’ultimo, ho notato che il problema persisteva e a quel punto è scattato il piano B: Google.

A primo colpo ecco la soluzione:

Basta andare su Tools => Options => Text Editor => HTML => Tab ed impostare l’indenting option su Smart.

A questo punto Visual Studio torna a funzionare senza particolari crash e con Resharper J

Fonte: http://blogs.msdn.com/b/webdevtools/archive/2012/03/06/visual-studio-11-beta-razor-editor-issue-workaround.aspx

web dev comments edit

Oggigiorno siamo circondati da una quantità di device a dir poco imbarazzante, dalle centinaia (ed anche troppe) distro di Android, fino ad arrivare a computer Windows based. All’interno di ognuno di questi device è presente un browser che, a causa della velocissima crescita dell’HTML5, richiede continui aggiornamenti per stare al passo con le specifiche che si stanno man mano stabilizzando all’interno del W3C.

Tempo fa Google con Chrome ha introdotto una sorta di “Silent update”, che consiste in un “servizio” Windows che ha il compito di controllare ed installare eventuali aggiornamenti del browser.
L’aspetto positivo di questo approccio è che l’utente non deve preoccuparsi di verificare se esiste una patch o una nuova versione del browser, mentre il lato negativo è il non controllo di ciò che avviene sulla nostra macchina (l’utente non riceve notifica di nessun aggiornamento).

Questa strada si è dimostrata molto positiva, e di fatto tutti gli utenti con Chrome hanno installato  l’ultima versione (17.x in questo momento), tant’è che Microsoft ha deciso di intraprendere lo stesso percorso aggiornando automaticamente tutte le versioni di Internet Explorer alla 9 in maniera del tutto automatica.

Tale aggiornamento offre sicuramente un set di vantaggi lato utente indiscutibili, dalle performance alla sicurezza (Internet Explorer 9 si è dimostrato il browser più sicuro), oltre al supporto per HTML5.

Personalmente sono molto curioso di sapere se Microsoft sfrutterà questa tecnica anche per aggiornare IE9 con un subset di features HTML5 che questo non supporta. Di fatto Microsoft ha deciso di intraprendere una strada diversa da altri vendor tipo Google, implementando solo le specifiche mature i cui cambiamenti da qui alla chiusura dell’HTML5 saranno minimi se non nulli.
Fortunatamente/sfortunatamente (a seconda dei punti di vista) dall’uscita di IE9 molte features (websocket, fileapi, offline, input type, etc) sono “salite di grado” e risultano ora mature, tanto da poter essere promosse su un browser con IE9. La casa di Redmond ha dimostrato il suo interesse verso queste feature, e di fatto possiamo testarle su IE10 e Win8, quindi non mi stupirebbe se ci fosse un upgrade anche verso questo aspetto.

Maggiori informazioni su IE9 e l’auto update sono disponibili in questo bellissimo post.

Ciauz

web dev comments edit

Quando ci troviamo a navigare pagine web con connessione protetta - e per connessione protetta intendo tramite il protocollo https - ed alcune delle sue risorse (immagini, javascript, css, etc) non puntano ad un indirizzo sicuro, rischiamo di avere una fastidiosa notifica da parte del browser che ci obbliga a dare il consenso per mostrare i contenuti non sicuri.

Diamo un occhio all’html seguente per capire meglio di cosa stiamo parlando:

<meta name="description" content="" />
    <meta name="author" content="" />
    <link rel="stylesheet" href="http://mysite.com/css/mystyle.css" />
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js" type="text/javascript"></script>
    <script type="text/javascript" src="http://mysite.com/js/libs/modernizr-1.7.min.js?v=1.5.0.21"></script>

Finché navighiamo la pagina sopra in http non c’è nessun problema ma, se proviamo ad aprire la stessa pagina in https, un buon browser dovrebbe notificarci il rischio a cui andiamo incontro (sia il css, sia jquery puntano ad una connessione http e non https).
Per evitare il problema ci basta cambiare le url da http://.... ad https://..... nel caso la connessione corrente sia in https, e viceversa.
Ovviamente questo cambio deve essere automatico e, riempire il codice di html di if che cambiano il protocollo, non è la soluzione corretta!

Fortunatamente esiste un rimedio più semplice e pulito che consiste nella rimozione dall’url della parte relativa al tipo di protocollo; quindi dobbiamo rimuovere http: o https: e lasciare semplicemente il // come mostrato di seguito.

[xml] <meta name="description" content="" /> <meta name="author" content="" /> <link rel="stylesheet" href="//mysite.com/css/mystyle.css" /> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js" type="text/javascript"></script> <script type="text/javascript" src="//mysite.com/js/libs/modernizr-1.7.min.js?v=1.5.0.21"></script> [/xml]

A questo punto sarà il browser a “switchare” in automatico dalla connessione http/https in base a quella corrente.

Questa tecnica prende il nome di “network-path reference” (maggiori info qui) e funziona anche per i css, come potete vedere sotto:

[css].mycssclass { background: url(//mysite.com/myimage.jpg); }[/css]

Inoltre questo approccio funziona egregiamente con tutti i browser, tranne che con Internet Explorer 7 e 8 dove, solo per i tag o @import, il download della risorsa avviene due volte (maggiori info qui).

Figo no?

asp.net comments edit

Giorni fa ho avuto a che fare con un piccolo problema riguardante le url di una mia applicazione web. In pratica mi trovavo con delle richieste verso un indirizzo tipo il seguente “/mycontroller/myaction/myid%20” (per chi non lo sapesse %20 equivale allo spazio) che, non per volere mio, restituiva sempre un 404 invece di dirottare la chiamata verso il mio controller.

Come si può ben immaginare il problema è dovuto a quel %20 che, per qualche strano motivo, non viene digerito dal sistema di routing di ASP.NET 3.5 SP1.

Ovviamente un url del genere può sembrare raro in un’applicazione web, e molti di voi si chiederanno il perché di tale indirizzo, quindi provo a spiegarlo di seguito Smile.

La settimana scorsa mi trovavo a sviluppare un textbox autocomplete con jquery per un’applicazione ASP.NET MVC; sfortunatamente le features richieste non erano coperte dalle migliaia di esempi presenti in rete, quindi mi sono dovuto armare di coraggio e, a colpi di javascript e json, sono riuscito a realizzare la textbox che trovate qui.

All’apparenza il funzionamento è identico a quello di tutte le textbox con autocomplete. Per capire il problema sopra mostrato, non è necessario addentrarsi nel codice javascript o nel modo in cui ho implementato la textbox, ma basta capire cosa fa per mostrare i suggerimenti all’utente.

Nel momento in cui l’utente digita qualcosa, questo qualcosa viene inviato ad una Action di un controller MVC che non fa altro che eseguire una query con un like e restituire i primi 7 elementi. Questo vuol dire che ogni volta in cui l’utente digita una lettera all’interno della textbox, via javascript viene inviato il testo digitato per eseguire l’operazione sopra descritta.
Passando alla pratica, quando l’utente digita “Mario”, una chiamata tipo la seguente “/Search/PersonSuggestion/Mario” viene effettuata.

Supponiamo ora di voler raffinare la ricerca in quanto troppe persone si chiamano Mario, e noi vogliamo trovare il classicissimo Mario Rossi.

Nel momento in cui l’utente deve aggiungere “ Rossi” (spazio Rossi), la chiamata diventa più o meno così:

/Search/PersonSuggestion/Mario%20Rossi

Ovviamente prima di arrivare a digitare Rossi c’è uno spazio, quindi verrà effettuata una chiamata come questa: “/Search/PersonSuggestion/Mario%20

Ed eccoci arrivati al problema iniziale: il 404 da parte del server.

Il motivo risiede nel fatto che il runtime di ASP.NET effettua una validazione delle url in entrata, applicando le stesse regole del filesystem. Questo vuol dire che, così come non possiamo creare una folder con lo spazio alla fine (quindi “Mario “), non possiamo neanche avere un url con lo stesso spazio.

Ovviamente questo tipo di validazione è “aggirabile” grazie ad una proprietà dal curioso nome “RelaxedUrlToFileSystemMapping”, da aggiungere alla sezione HttpRuntime del web.config come mostrato di seguito.

<system.web>
    <httpRuntime 
            requestValidationMode="2.0" 
            executionTimeout="20" 
            requestPathInvalidCharacters="" 
            relaxedUrlToFileSystemMapping="true" />

Ciauz

web dev comments edit

Stampa Anche quest’anno (per il terzo anno consecutivo), ho la fortuna di partecipare come speaker alla più importante conferenza italiana sul mondo Microsoft e non solo.
Specifico il “non solo”, perché proprio io sarò lì per parlare di HTML5 che, come tutti sappiamo, non è una tecnologia Microsoft, ma è sicuramente un percorso importante per il futuro delle applicazione web e non.

Anche il “e non” non è a caso J. Oltre ad una sessione full immersion su HTML5 in cui mostrerò tutto ciò che ad oggi possiamo utilizzare e cosa arriverà a breve, parteciperò sempre come speaker ad un’altra sessione sul data entry in Windows 8 dove, insieme al mitico Salvuzzo, mostreremo come accedere e mostrare dati in un’applicazione Metro UI con C# e HTML5+JS.

Direi che di motivi per non mancare ce ne sono tanti. Se non vi bastano date un’occhiata agli speaker e all’agenda, aggiungeteci che l’early bird è stata prolungata fino al 31 ottobre, e a questo punto non avete proprio più scuse Smile

 

See you there!

various comments edit

Chiacchierando con amici e colleghi, ho notato che molti fanno uso di DropBox come tool/repository per condividere e “backuppare” le informazioni più importanti. Uno dei motivi per cui ritengo DropBox un ottimo tool è sicuramente il buon funzionamento ed il supporto praticamente a tutte le piattaforme (Windows, Mac, iPhone, Android, etc).

Tuttavia uno dei più grandi limiti di DropBox è la folder di Sync. Una volta installato si ha la possibilità di effettuare il sync ed il backup solo della folder creata dal client, con l’obbligo di copiare tutti i nostri file al suo interno, rinunciando alla struttura presente nel nostro Hard Drive.

Fortunatamente è ora possibile aggirare questo problema scaricando “Drop Box Folder Sync” da qui http://wiki.dropbox.com/TipsAndTricks/SyncOtherFolders

Una volta installato il client, possiamo aggiungere e togliere tutte le folder che preferiamo in qualsiasi parte dell’hard-disk; infatti, cliccando con il tasto destro su una cartella, si noterà l’aggiunta di due nuove voci di menù:

  • Sync with DropBox;
  • UnSync with DropBox;

Inutile spiegarne il significato.

Ciauz

asp.net comments edit

Tutti i giorni mi capita di consultare esempi e progetti fatti da altri, sia nel mondo dell’open source che nel mondo del lavoro.

Moltissime volte ho visto applicazioni MVC che hanno il “vizietto” di utilizzare le classi del dominio direttamente dentro le View. Devo ammettere che anche io in passato sono stato tentato - a volte ho anche ceduto - di percorrere questa strada per accorciare i tempi di sviluppo ma, ancora una volta, mi trovo a blaterare su questo errore.

Partendo dalla premessa che noi siamo pagati per sviluppare del buon codice (non credo che mai nessuno vi abbia mai detto – “ti pago, ma scrivi un codice di merda!”), e che non dobbiamo scrivere il codice a nostra comodità perché siamo pigri, volevo ricordare alcuni dei problemi che si posso incontrare utilizzando il dominio nella view:

  • La view può avere maggior complessità (non è detto che l’entity abbia le info come le vuole la view, e quindi questa deve recuperarle ed adattarle): questo rischia di creare scenari la cui testabilità della view può diventare difficile, se non impossibile;
  • Query inaspettate. Spesso le entity di dominio sono “proxate” da un O/RM, questo vuol dire che colui che realizzerà la view potrà accedere ad una property che scatenerà a sua volta una query onerosa (magari vuole mostrare il numero di prodotti e fa un count su IList<Product>, finendo con il caricare tutti i prodotti);
  • Problemi di balancing. Per lo stesso motivo di cui sopra (proxy dell’O/RM), le entity di dominio possono non essere serializzabili, escludendo così la possibilità di effettuare caching sui dati delle view.
  • Crescita applicativa bloccata. Se all’improvviso, per imposizioni del client o per scelte architetturali, ci si trova nella situazione in cui tutta la logica di accesso ai dati finisce in un servizio e le view non possono arrivare direttamente all’O/RM, siamo costretti a riscrivere tutta la parte dinamica delle view attingendo ai DTO restituiti dal servizio.

Capisco la comodità e la velocità nell’utilizzare il dominio nella view, ma fidatevi, alla lunga paga la strada corretta!

Ciauz