Creare un Accelerator per Internet Explorer 8 è veramete semplice: in estrema sintesi vuol dire creare un file XML che punta ad un servizio esterno e renderlo installabile tramire una semplice API window.external.AddService
Potete da oggi scaricare un template XML già fatto da MSDN a questo link che contiene tutte le sezioni commentate con il significato di ogni sua parte. La documentazione completa è disponibile a questo link: OpenService Accelerators Developer Guide.
Vi segnalo inoltre la mia sessione su Accelerator, Web Slice e Visual Search Provider per qualche informazione in più:
Altre sessioni su Internet Explorer 8 sono:
i video durano solo qualche minuto :-)
Per iscriversi a questo link.
Fiddler2 è un utilissimo tool per Internet Explorer che mi è stato più volte utile. La particolarità di Fiddler è che funziona come proxy lato client, cioè si pone come strato intermedio tra il browser e le chiamate fatte al server. Questa particolarità può spesso essere utile perchè si è in grado di intercettare le chiamate http uscenti dal browser prima che arrivino ad un server e, dall’altro lato, intercettare le risposte dal server al browser.
Questo consente non solo di vedere ad esempio gli header della chiamata http dal client verso il server, ma anche di modificarli prima che arrivino a quest’ultimo. Posso anche aggiungere e rimuovere header. Questa particolarità mi è stata spesso utile in passato nello sviluppo di filtri ISAPI.
Avendo accesso all’intera richiesta http prima di essere inviata al server e alla risposta prima che possa essere restituita al browser è possibile fare anche di più.
Di recente mi è capitato di avere un client che faceva una richiesta http ad un file su un server, che aveva un nome completamente differente da quello realmente presente: ok lasciamo stare il perchè, quello che mi è capitato è che non avevo acesso al codice del client e tanto meno al codice del server: sì la vita è strana a volte.
Vediamo come usare Fiddler2, che va preventivamente installato, per intercettare e modificare queste chiamate.
Ho cercato di semplificare lo scenario in cui mi trovato per illustrare i passi da seguire.
Dal menù Tool di IE , troverete Fiddler2.
Se la pagina che chiamate inizia con localhost, Fiddler non è in grado di intercettare la richiesta, la tecnica che uso di solito è, una volta attivato fiddler, scrivere al posto di localhost ipv4.fiddler, come vedete in figura:
Se andate sotto Rules, quindi Automatic Breakpoints, quindi potete selezionare di intercettare la richiesta uscente: “Before Requests”.
Potete anche cliccare nella barra in basso, per attivare la funzionalità più rapidamente, come vedete in figura:
Ora se facciamo una richiesta dal browser, vedremo che Fiddler la blocca, dandoci appunto la possibilità di lavorare sugli header http:
In figura vedete che la richiesta #1 è stata bloccata, nella finestra degli header della richiesta, vedete che un menù contestuale mi permette di fare diverse operazioni sugli header.
Una segnalazione in rosso, mi dice che la richiesta uscente è stata bloccata, posso, premendo il tasto giallo, farla proseguire al server e bloccare a questo punto la risposta che ritorna, oppure , dopo aver fatto le modifiche del caso, premere il tasto verde e semplicemente completare la chiamata senza più interruzioni.
Nel mio caso voglio modificare la chiamata GET alla pagina pippo.htm, che viene eseguita all’interno di un’applicazione Silverlight. Facendo doppio click sulla chiamata GET posso modificarne il contenuto, come segue:
Quindi come potete vedere ho modificato il nome del file che viene richiesto dall’applicazione e che so essere presente sul server.
Premendo ora il tasto giallo, la richiesta prosegue, viene elaborata dal server, ma prima di arrivare al client viene, se possibile, bloccata. La risposta deve avere un dominio intercettabile da fiddler. Quindi non deve avere localhost come nome di dominio, ma nel mio caso reale non era un problema perchè la risposta arrivava da un server su internet a cui non avevo accesso.
Fiddler è sicuramente un tool che trovo utilissimo in scenari in cui una semplice developer toolbar difficilemente arriva. Lo svantaggio è che spesso la configurazione soprattutto se si usa in locale (localhost +porta) non è velocissima. Ma in altri casi in cui volgio ispezionare l?HTML o i CSS una developer toolbar è più immediata. Quindi l’accoppiata IE8 Developer Toolbar + Fiddler penso sia una buona accoppiata per chi sviluppa applicazioni web.
La Basta!Italia è una conferenza che si svolgerà in Italia il prossimo 16-18 Marzo a Roma all’interno della quale è possibile seguire workshop e sessioni di approfondimento organizzate su diverse tracce. Potete leggere una descrizione di come è strutturata la conferenza a questo link.
In questi giorni sto riffletendo su come strutturare la mia sessione dal titolo AJAX: Presente e Futuro. Durante questa sessione ho intenzione di ripercorrere l’evoluzione di ASP.NET, dall’introduzione di ASP.NET AJAX, le ultime novità introdotte in .NET 3.5 SP1, fino a raccontarvi quello a cui stanno lavorando per la prossima versione di ASP.NET AJAX. L’obbiettivo della mia sessione non è solo quello di raccontarvi questa evoluzione, ma anche di capire quale approcci sia meglio seguire per lo sviluppo di una moderna applicazione RIA: rispetto alla user experience, rapidità e produttività di sviluppo, accessibilità dei siti e performance. Durante la sessione vedremo l’approccio AJAX server-side, come funziona e quando può avere senso utilizzarlo, rispetto ad un approccio AJAX client-side, c’è chi lo chiama “puro”, che spesso è reso complicato perchè richiede l’uso di molto JavaScript e framework per il rendering della UI. A fronte di una semplificazione dello sviluppo lato client, ha senso ad esempio l’uso li librerie come jQuery, che verranno integrate e supportate nella prossima release di Visual Studio.
Se infine avete sentito parlare delle novità di IE 8 per l’ AJAX Navigation o state solo cercando di capire se ASP.NET AJAX o Silverlight, ci vediamo a Roma…
[Update 11/3]
IE8 al momento è stato rilasciato in versione RC1. Una delle cose che preferisco del nuovo IE8 è il fatto che è stato pensato con l’idea di offrire il maggior supporto possibile agli standard W3C per il layout delle pagine : W3C Cascading Style Sheets Level 2.1 , W3C Selectors API, ed un supporto limitato alle W3C Cascading Style Sheets Level 3 Specification (Working Draft), non ancora in effetti un vero e proprio standard.
IE8 verrà rilasciato con un nuovo motore di layout, che sarà quello abilitato di default per la visualizzazione delle pagine. Il supporto verso questi standard W3C consentirà di sviluppare un sito web che funzioni correttamente su diverse versioni di browser, quindi non solo IE, che li supportano.
Ma cosa succede per i siti che sono stati sviluppati in precedenza, per versioni precedenti di Internet Explorer ? In questi siti potrebbero presentarsi dei problemi di visualizzazione e nell’esecuzione del JScript che utilizzano il version Vector e la User Agent String per generare codice di logica applicativa, ritornerò dopo su questo punto.
Diciamo che si possono vedere 4 possibili aspetti per quanto rigurda la compatibilità:
E’ sicuramente quello a cui tendere nel futuro se si ha già un sito esistente perchè assicura la maggior compatibilità agli standard W3C. Non è necessario modificare subito il proprio sito proprio, perchè IE8 introduce la document compatibility
IE 8 per mantenere la compatibilità ha introdotto una funzionalità che si chiama document compatibility, grazie a questa è possibile far funzionare
E’ sicuramente quello a cui tendere nel futuro se si ha già un sito esistente perchè assicura la maggior compatibilià agli standard W3C. Non è necessario modificare subito il proprio sito proprio, perchè IE8 ntroduce la document compatibility
IE 8 per mantenere la compatibilità ha introdotto una funzionalità che si chiama document compatibility, grazie a questa è possibile far funzionare IE8 in un delle tre diverse modalità di rendering della pagina, che sono:
In particolare tramite un tag meta posto nell’ header della pagina o via http header si può assegnare uno dei valori presenti nella tabella seguente:
Oppure la potete vedere da questo flow chart dal blog di Giorgio Sardo
Quindi se abbiamo un sito che viene visualizzato correttamente con IE7 e volgiamo aspettare a fare le modifiche per rendere più compatibile con gli standard quello che possiamo fare è usare il tag con il valore IE=EmulateIE7. Questo fa si che IE8 si comporti come IE7, che, scusate il gioco di parole, si usa una delle due modalità di layout proprie che vedete in tabella e per che sono guidate dalla presenza (o meno) della direttiva DOCTYPE nella pagina. Questo ci garantisce per la parte di layout, ma se abbiamo scritto del codice JScript non proprio corretto che usa la User-Agent-String o il Version-Vector ? Ok, ne parliamo dopo..
Come impostarlo:
2.1 Impostando il tag meta nella pagina HTML (page-per-page)
2.2 usando un header http
Ad esempio a livello file web.config
Usando la console di IIS 7
Per altre versioni di IIS e Apache
Se da IE8 premete tools, Compatibility View Setting, vi apapre la seguente schermata In cui vedete che potete impostare i due check box che ho evidenziato, con cui:
Anche l’utente, se non dovesse vedere bene un sito può intervenire premendo un bottone accanto a quello del browser, abilitando la Compatibility View. Questo fa visualizzare il sito nella modalità usata da IE7 Standard:
Il bottone non viene visualizzato nei seguenti casi:
Questo equivale ad usare, come visto il valore IE=EmulateIE7, tranne per una piccola cosa:
Ho tracciato usando Fiddler la chiamata per vedere come è fatta la User-Agent-String (UA) (questa identifica l’identità del browser e viene inviata al server via header http):
La UA riporta che la chiamata è fatta da un browser IE 7(MSIE 7.0) , cosa che non avviene se imposto il tag meta o uso l’header http visto in precedenza, in cui verei MSIE 8.0. E’ però possibile capire lato codice (sia client che server) che sta parlando di un IE8 perchè esiste la nuova dicitura Trident/4.0. In pratica per essere più chiaro:
Ora che dovrebbe essere un po’ più chiaro per quanto riguarda la document compatibilty, che quindi può essere modificata anche dall’utente, supponiamo di aver migrato il sito ed essere compatibili con IE8 Standard mode, possiamo usare il tag meta o l’header http visto in precedenza per forzare l’IE8 dell’utente a lavorare nella sua modalità standard, per far questo usate il valore IE=EmulateIE8, che se riguardate la tabella vista in precedenza ha proprio questo scopo.
Spesso la User-Agent String, viene usata sia lato server che client per implementare della logica differente da browser a brower è quindi importante che sia scritto bene il codice che controlla la versione del browser e che tenga quindi presente anche di IE8.
Su MSDN trovate un esempio di una funzione tipo che usando le regual expression estrae il valore correto:
Il VV è una funzione tipica solo di Internet Explorer. in una chiave di registry è salvata la versione del browser, quella che viene visualizzata nell’ help.
Ora potete scrivere dei commenti condizionali che in base alle diverse versioni del browser, e generare codice di markup opportuno, ad esempio se voleste supportare nel vostro siti più versioni di Internet Explorer.
Su MSDN trovate un esempio d’uso delVV, con cui potreste implementare logiche diverse per caricare CSS diversi, ad esempio
Per testare i vostri siti potete procedere in due modi
Operando sul tasto Browser Mode:
Operando su Document Mode:
Se utilizzate il controllo WebBrowser (WebOC) in un’applicazione WinForm o WPF, il comportamento di default è che la pagina caricata viene visualizzatam in modalità di compatibiltà con IE7. E’ possibile cambiare il comportamento del WebOC agendo su un’opportuna chiave di registry:
Abilitare la modaltità IE8 Standard: MyApplication.exe è il nome dell’applicazione che usa il WebOC
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION] "MyApplication.exe" = dword 8000 (Hex: 0x1F40)
Quindi operando sulla chiave di registry FEATURE_BROWSER_EMULATION è possible impostare tre modalità: IE8 Standards Mode, IE7 Standards Mode e IE8 Standards Mode (Forced). Quest’ultima modalità sarà aggiunta nella RTM di IE8 e forzerà la modalità IE8 Standard ignorando se la pagina visualizzata è stata inserita nella compatibility list. Trovate altre informazioni sul post del team di IE qui. ecco la parte più interessante della tabella con i valori di questa chiave. Le tre righe nell’ordine si riferiscono alle tre diverse modalità dette prima.