lunedì 23 febbraio 2009
Ok non è che sia sta grandissima notizia comunque Fico!!!!
Tags: Silverlight Rai
mercoledì 28 gennaio 2009
Ciao a tutti, da un po di tempo (due giorni) sono alle prese con un problema che affligge il mio VS 2008, ma anche quello del mio collega, non ho solo io il desktop impossesato posseduto! ;)
Visto e considerato che si tratta di uno strano comportamento sottopongo alla vostra attenzione i passi per replicare la stranezza:
- Creare una nuova soluzione in visual studio.
- Aggiungere un progetto di tipo “CLass Library”.
- Aggiungere un progetto di tipo “ASP.NET Web Application”.
- Predisponete un path di rete con all’interno le seguenti dll : Microsoft.SharePoint.dll, Microsoft.SharePoint.Search.dll, Microsoft.SharePoint.Security.dll, con i relativi xml (Microsoft.Sharepoint.xml, Microsoft.sharepoint.Search.xml, Microsoft.sharepoint.Security.xml).
- Aggiungete al progetto di tipo “Class Library” una referenza a Microsoft.SharePoint.dll che deve puntare al path di rete predisposto al passo 4, per fare un esempio il percorso alla dll potrebbe essere “\\myserver\libraries\sharepoint\Microsoft.SharePoint.dll” ricordatevi che nelle proprietà della libreria importata dovete settare il flag “Copy Local” come false.
- Aggiungere al progetto di tipo “ASP.NET Web Application” una referenza al progetto di tipo “Class Library” (la referenza deve essere aggiunta a partire dal tab Projects nella form di inserimento delle referenze).
- Compilate il Progetto di tipo “ASP.NET Web Application”
Ora se aprite la Bin del progetto di tipo “ASP.NET Web Application” notate la presenza di quattro file che non dovrebbero esserci:
- Microsoft.SharePoint.Search.dll
- Microsoft.SharePoint.Search.xml
- Microsoft.SharePoint.Security.dll
- Microsoft.SharePoint.Security.xml
Note: Il problema non si verifica in tutte le installazioni di Visual Studio ad esempio un’altro collega non è riuscito a replicarlo, ho importato i sui settings nel mio Visual Studio ma lo strano comportamento rimane nella mia installazione, poi non c’è nessunissima riga di codice che chiami in causa le dll sopracitate. Secondo avevo resharper installato l’ho disinstallato ma il problema persiste. Infine utilizzo Visual Basic come linguaggio per le mie aplpicazioni (non ho verificato in C#).
Tags: Visual Studio 2008
mercoledì 26 novembre 2008
Sebbene personalmente non ami particolarmente l'uso della sessione nelle web-application, spesso essa viene utilizzata anche perchè non si può fare altrimenti. La seconda affermazione (spesso viene utilizzata) spiega il perchè di questo post, difronte infatti ad un'applicazione che ne faceva un largo uso ho cercato di capirne il funzionamento nei suoi dettagli.
Partiamo dal fondo dalla sua definizione formale, la sessione così come la conosciamo è definita dall' HTTP State Management Mechanism RFC. Essa infatti:
This document specifies a way to create a stateful session with HTTP requests and responses.It describes two new headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal,but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)
Sostanzialmente per quello che riguarda ASP.NET senza addentrarci troppo nei dettagli della RFC 2109 vi riporto una semplice e sommaria descrizione di come le cose funzionano,
Il Server si occupa di generare una nuova sessione (se necessario), mantienere la sessione e l'elimina all'occorrenza.
Il Client si occupa di ricordare al Server quale è la sessione che lo riguarda.
Come si può notare la maggior parte del lavoro è portata avanti dal Server, il gioco è basato su di uno scambio costante, tra il Client ed il Server, di particolari Cookie (non sono come i classici cookie salvati nel hard-disk del client), il Server alla generazione della nuova sessione inserisce nella response un header in più, il Set-Cookie. Il Client per confermare al Server il mantenimento della sessione inserisce un header in più nella Request fatta, il Cookie. Il Set-Cookie viene conservato nella cache del Client (se sbaglio correggetemi :| ).
NB. Questa descrizione è una mia libera interpretazione per avere un quadro certo sul funzionamento della RFC basta leggersela.
Dopo questa breve descrizione vediamo in pratica come verificare i concetti espressi sin d'ora. Quello che ci serve è una Web-App che generi una nuova sessione :) e di un tool che effettui dello sniffing per verificare il contenuto delle Request e delle Response passate tra il Client ed il Server.
Partiamo dalla prima cosa, per questo apro Microsoft Visual Web Developer 2008 Expr. Ed. creo una nuova ASP.NET Web Application.
Default.aspx:
1: <%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Default.aspx.vb" Inherits="SessionTest._Default" %>
2:
3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
4:
5: <html xmlns="http://www.w3.org/1999/xhtml" >
6: <head runat="server">
7: <title></title>
8: </head>
9: <body>
10: <form id="form1" runat="server">
11: <div>
12: <p>
13: <%Response.Write(Session.SessionID)% >
14: </p>
15: </div>
16: </form>
17: </body>
18: </html>
Default.aspx.vb:
1: Partial Public Class _Default
2: Inherits System.Web.UI.Page
3:
4: Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
5: Session("TestSession") = "Test Della Sessione"
6: End Sub
7:
8: End Class
Nel code-behind genero una nuova sessione con l'assegnazione al'oggetto Session("TestSession") un valore stringa qualsiasi vedi linea 4 del file Default.aspx.vb, nel file Default.aspx visualizzo l'ID della sessione appena generata nel Server. Per verificare lo scambio di Set-Cookie e Cookie tra Server e Client utilizziamo Firebug, abilito quindi il "Support For Network Monitoring", premiamo F5 nel Web Developer per attivare il debug. Quello che succede poi vine mostrato nell'immagine sotto:
Evidenziate in rosso l'Id della Sessione visualizzato nella pagina (primo in alto) ed il Set-Cookie nell Header (intestazione) della Response passato al Client dal Server (secondo riquadro in basso).
Ora per vedere l'Header Cookie Passato dal Client al Server basta effettuare un refresh della pagina:
In questo caso il secondo riquadro rosso nell'immagine sopra mostra l'Header Cookie aggiunto nella Request fatta dal Client al Server.
Tra i vari problemi legati a questo tipo di teconoliga possimao evidenziarne uno introdotto con l'utilizzo dei Tab nei moderni browser, se infatti aprissi un nuovo tab nell'istanza precedente di Firefox e navigassi fino alla stessa risorsa mi accorgerei che:
viene visualizzato lo stesso numero di sessione (riquadro rosso), di conseguenza in uno scenario complesso se effettuassi modifiche che hanno impatto nella sessione, nel tab in alto, poi nel tab che sta sotto mi troverei lo stato della sessione modificato (note l'immagine sopra è stata realizzata con l'utilizzo dell'add-on per Firefox Split Browser).
Conclusioni:
Queste anomalie non investono solo le applicazioni ASP.NET provate ad accedere a due Account di Gmail differenti su due tab differenti di Firefox o internet Explorer, nella stessa istanza del Browser, provate poi ad effettuare qualche modifica nei settings di un account e verificate cosa succede all'altro. Fino a poco tempo fa succedevano delle cose strane tipo email che invece di arrivare ad un account arrivano magicamente nell'altro account.
mercoledì 24 settembre 2008
Se per caso vi trovate a Manhattan e vi capita un bisogno (puà capitare ;) )
nessun problema c'è il motore di ricerca delle toilette
Tags: Toilette
giovedì 18 settembre 2008
Dopo la presentazione da parte di big G di Google DocType, sono andato a curiosare per vedere di cosa si tratta:
Google Doctype is an open encyclopedia and reference library. Written by web developers, for web developers. It includes articles on web security, JavaScript DOM manipulation, CSS tips and tricks, and more. The reference section includes a growing library of test cases for checking cross-browser and cross-platform compatibility. fonte Google.
Navigando tra vari Howto, ne ho trovato uno interessante: HOWTO detect when the user resizes the browser window (goog.dom.ViewportSizeMonitor). Questa funzionalità ci permette di monitorare le dimensioni del browser, tramite la gestione di determinati eventi custom, che vengono sollevati ogni volta che l'utente ridimensiona la finestra del browser.
Bene mi interessa, decido di includere questa funzionalità all'interno della mia applicazione ASP.NET (non entro in questo post nel merito della licenza). Dopo aver creato la mia banalissima soluzione con la Default.aspx in VS 2008 creo in essa la directory *js* che a sua volta include la directory *CommonTools* è mia intenzione infatti "storare" i vari javascriot presi da big G in questa directory. Fatto questo riporto i vari passi che ho compiuto:
- Il punto di partenza è recuperare i vari *.js da includere nella directory CommonTools, accedo per cui al codice sorgente (google ci dice che possimao vedere il sorgente dal web oppure scaricarlo nella nostra macchina) di doctype.
- Aggiungo in primis i file base.js e deps.js presi dalla root goog gli linko all'interno della pagina default.aspx.
- Aggiungo il file goog.dom.ViewportSizeMonitor.js (ViewportSizeMinitor).
- Il file goog.dom.ViewportSizeMonitor.js si porta dietro delle dipendenze: goog.dom, goog.events, goog.events.EventTarget ... Le dipendenze non sono altro che file js, dobbiamo per cui includerli all'interno della nostra soluzione (è semplice capire quali file includere basta vedere il codice sorgente dei file importati e verificare le righe di codice che richiamano la funzione *goog.require* definita in base.js). Le dipendenze devono essere risolte in maniera ricorsiva, se x.js necessita di y.js che a sua volta necessita di z.js devo importare tutti tre i file (non potrebbe essere altrimenti ;)).
Finito, ho importato rurri i file necessari in maniera ricorsiva ecco cosa mi ritrovo all'interno della directory CommonUtils:
Per fare in modo che vengano caricati correttamente senza generare errori javascript a runtime li ho linkati all'interno della Default.aspx (nella sezione head) come segue (il file deps.js viene caricato da base.js non è necessario linkarlo):
<!--JAVASCRIPT -->
<script src="js/CommUtils/base.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.disposable.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.array.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.string.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.event.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.math.size.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.math.coordinate.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.object.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.events.Listener.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.userAgent.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.structs.SimplePool.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.events.BrowserEvent.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.dom.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.events.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.events.EventTarget.js" type="text/javascript"></script>
<script src="js/CommUtils/goog.dom.ViewportSizeMonitor.js" type="text/javascript"></script>
Poi per poter usufruire della funzionalità sempre nella sezione head di Default.aspx ho incluso il seguente script:
<script id="ResizeEventHandler" type="text/javascript">
var vsm = new goog.dom.ViewportSizeMonitor();
goog.events.listen(vsm, goog.events.EventType.RESIZE, function(e) {printViewportSize(vsm.getSize());});
function printViewportSize(param)
{
document.getElementById('ViewPortSize').innerText = param;
}
</script>
Bene ecco fatto ora la label ViewPortSize mantiene il valore delle dimensioni della finestra del browser:
Considerazioni:
Non entro nel merito delle ottimizzazioni che si possono apportare all'applicazione, avrei potuto trattare i vari javascript come embedded resources oppure avrei potuto applicargli un'algoritmo di compressione ... Comunque l'inclusione di ben 17 file .js mi sembra eccessiva (anche se i vari "bechmark" firebug :) che ho eseguito non dimostrano un overload pazzesco per il recupero) comunque, se si ha bisogno solo di questa funzionalità è possibile sicuramente trovare altre vie meno onerose. Certo è che Doctype mette a disposizione degli sviluppatori un gran numero di funziuonalità, ma al costo di adottare in blocco tutta la loro filosofia (non si agisce sull'esistente ma si ricreare tutto da zero ex: il dom ed i tipi di dato come string), poi non ho verificato che tipo di implicazioni ci sono sulla licenza del prodotto sviluppato.
Tags: ASP.NET Doctype Google