Chi sviluppa in ASP.NET e applicazioni web in generale sente costantemente l'esigenza di aver il più completo controllo di quello che accade durante l'esecuzione dell'applicazione.
Lato server visual studio (in .net) offre ottimi strumenti di debug e quindi il lavoro è generalmente semplice.
Lato client invece risulta ostico capire cosa realmente sta accadendo, quali dati vengono scambiati e quali file sono coinvolti nelle elaborazioni. Un ottimo tool che ci aiuta è possibile trovarlo al link http://projects.nikhilk.net/.
Con questo tool è possibile monitorare l'intero traffico HTTP, vedere anche le chiamate "nascoste" nelle applicazioni AJAX e vedere chiaramente le strutture dati javascript scambiate tra il client e il server.
Una ottima installazione e una guida completa completa inoltre il tool.
mercoledì 29 agosto 2007
giovedì 26 luglio 2007
Manipolazione degli eventi javascript lato client
Normalmente il comportamento dinamico di una pagina web è predefinito e calcolato direttamente in fase di definizione della pagina stessa. Così il file in html che arriva al browser ha una serie di oggetti che rispondono ai vari eventi, eseguendo metodi e cambiando proprietà.
Un esempio:
Può capitare però che il comportamento della pagina debba cambiare in funzione della pagina stessa. Quindi gli eventi javascript che dovranno essere generati durante la vita della pagina non sono definiti direttamente lato server ma vengono impostati "dinamicamente" nel browser.
In pratica è possibile scrivere un oggetto HTML senza eventi associati
ad esempio:
e aggiungere un poco di codice.
La chiamata o.onclick = new Function('prova()'); consentirà di agganciare la chiamata alla funzione prova() a runtime.
Un esempio:
<div style="height: 39px; border-style:solid;" onclick="javascript:prova();">
div con click definito nella pagina
</div>
Può capitare però che il comportamento della pagina debba cambiare in funzione della pagina stessa. Quindi gli eventi javascript che dovranno essere generati durante la vita della pagina non sono definiti direttamente lato server ma vengono impostati "dinamicamente" nel browser.
In pratica è possibile scrivere un oggetto HTML senza eventi associati
ad esempio:
<div id="divNoEvent" style="height: 39px;border-style:solid;">
div senza click definito a runtime
</div>
e aggiungere un poco di codice.
<script type="text/javascript">
function prova()
{
alert('hai fatto click');
}
var o = document.getElementById('divNoEvent');
o.onclick = new Function('prova()');
</script>
La chiamata o.onclick = new Function('prova()'); consentirà di agganciare la chiamata alla funzione prova() a runtime.
lunedì 25 giugno 2007
Configurare una rete wireless ragionevoltemente sicura a casa propria...
Da pochi giorni ho approntato un access point a casa mia e dietro (anzi, sotto) di lui c'è un router ADSL di alice...
Tra un pochino la porterò in flat mode... e quindi rimanendo sempre acceso lo ho configurato affinchè offra un livello di sicurezza contro accessi indesiderati e non sia utilizzabile da sconosciuti, vista anche la nuova moda del war driving.
Vediamo se ho approntato tutto per benino per evitare che qualcuno oltre a me riesca ad usare la mia rete per i propri comodi...
- Cambiato password dell'admin dell'access point. Sembra banale, ma in quasi tutte le periferische si entra con Admin Admin...cambiare questa password mi è sembrata la cosa più ovvia e semplice da fare.
- Cambiato elenco dei mac address autorizzati ad accedere all'access point.
- Ridotto la potenza del segnale dell'access point al minimo indispensabile per avere buona copertura nella zona di interesse ma non far vedere la rete a chi ne è fuori ... Non abito in una zona affollata, ma se abitassi in un condominio mi scoccerebbe non poco vedere un elenco di 12 reti wireless attive intorno a me...
- Tra poco (non lo ho ancora fatto) abiliterò la crittografia WEP.
- Configurati gateway e ip per funzionare con il router ADSL. (non serve per la sicurezza, ma senza è inutile avere un access point acceso).
Tra un pochino la porterò in flat mode... e quindi rimanendo sempre acceso lo ho configurato affinchè offra un livello di sicurezza contro accessi indesiderati e non sia utilizzabile da sconosciuti, vista anche la nuova moda del war driving.
Vediamo se ho approntato tutto per benino per evitare che qualcuno oltre a me riesca ad usare la mia rete per i propri comodi...
- Cambiato password dell'admin dell'access point. Sembra banale, ma in quasi tutte le periferische si entra con Admin Admin...cambiare questa password mi è sembrata la cosa più ovvia e semplice da fare.
- Cambiato elenco dei mac address autorizzati ad accedere all'access point.
- Ridotto la potenza del segnale dell'access point al minimo indispensabile per avere buona copertura nella zona di interesse ma non far vedere la rete a chi ne è fuori ... Non abito in una zona affollata, ma se abitassi in un condominio mi scoccerebbe non poco vedere un elenco di 12 reti wireless attive intorno a me...
- Tra poco (non lo ho ancora fatto) abiliterò la crittografia WEP.
- Configurati gateway e ip per funzionare con il router ADSL. (non serve per la sicurezza, ma senza è inutile avere un access point acceso).
martedì 19 giugno 2007
Custom controls con eventi personalizzati
Creare custom controls è una attività piuttosto comune per lo sviluppo di applicazioni web. Personalmente la tecnica in composition è quella che preferisco, in quanto mi consente di raggruppare funzionalità anche evolute in poco tempo e con un grandissimo tasso di riutilizzo.
Ma un controllo per sua natura deve generare eventi server.
Dopo parecchia fatica ho trovato questa reference sul sito MSDN che spiega chiaramente come fare un controllo lato server che generi via javascript un evento lato server.
Nell'esempio spiegano la costruzione di un semplice link button che chiami la funzione OnClick sul server, ma cambiando delegati e nomi agli eventi, tutto funziona con eventi personalizzati e tipizzazione particolareggiata degli eventi.
Ma un controllo per sua natura deve generare eventi server.
Dopo parecchia fatica ho trovato questa reference sul sito MSDN che spiega chiaramente come fare un controllo lato server che generi via javascript un evento lato server.
Nell'esempio spiegano la costruzione di un semplice link button che chiami la funzione OnClick sul server, ma cambiando delegati e nomi agli eventi, tutto funziona con eventi personalizzati e tipizzazione particolareggiata degli eventi.
venerdì 15 giugno 2007
10 cose da evitare... anzi... me ne bastano 6
Traggo spunto da un bel post di merlinox intitolato 10 cose da evitare sviluppando siti per "appuntare" anche io un elenco di cose da evitare (secondo me) sviluppando in .NET e con qualsiasi altro linguaggio di programmazione a oggetti...
1) fare copia e incolla... Se si ha necessità di copiare e incollare del codice significa che non si è sfruttata a dovere la struttura di ereditarietà messa a disposizione dal linguaggio a oggetti.
2) usare gli if e gli switch per modificare il comportamento. Ritorno al punto 1, esiste l'ereditarietà, quindi si può istanziare l'oggetto con il comportamento corretto e non mettere un if per variare il codice che verrà eseguito.
3) Implementare le proprie interfacce. E' più semplice manutenere una applicazione, anche se piccola, se questa implementa interfacce.
4) tipizzare il tipizzabile. Una applicazione che utilizza solo oggetti fortemente tipizzati è più facile da manutenere e da debuggare.
5) usare gli enumeratori. Si lega al punto 4, un enumeratore elenca semplicemente opzioni disponibili, il codice risulterà più pulito e non si potranno verificare situazioni non note.
6) ereditare tutto l'ereditabile... Controlli, engine e quant'altro. Non sappiamo dove la nostra applicazione finirà e quali comportamenti vorremo introdurre. Iniziando a scrivere l'applicazione utilizzando oggetti "nostri" che ereditano quelli di base, ci apriremo la porta per eventuali implementazioni future.
...se questi sei punti li avessi avuti ben chiari anni fa, beh, tutto sarebbe stato più semplice...
1) fare copia e incolla... Se si ha necessità di copiare e incollare del codice significa che non si è sfruttata a dovere la struttura di ereditarietà messa a disposizione dal linguaggio a oggetti.
2) usare gli if e gli switch per modificare il comportamento. Ritorno al punto 1, esiste l'ereditarietà, quindi si può istanziare l'oggetto con il comportamento corretto e non mettere un if per variare il codice che verrà eseguito.
3) Implementare le proprie interfacce. E' più semplice manutenere una applicazione, anche se piccola, se questa implementa interfacce.
4) tipizzare il tipizzabile. Una applicazione che utilizza solo oggetti fortemente tipizzati è più facile da manutenere e da debuggare.
5) usare gli enumeratori. Si lega al punto 4, un enumeratore elenca semplicemente opzioni disponibili, il codice risulterà più pulito e non si potranno verificare situazioni non note.
6) ereditare tutto l'ereditabile... Controlli, engine e quant'altro. Non sappiamo dove la nostra applicazione finirà e quali comportamenti vorremo introdurre. Iniziando a scrivere l'applicazione utilizzando oggetti "nostri" che ereditano quelli di base, ci apriremo la porta per eventuali implementazioni future.
...se questi sei punti li avessi avuti ben chiari anni fa, beh, tutto sarebbe stato più semplice...
venerdì 8 giugno 2007
Con Hyperwords le pagine web diventano interattive
Rendere ogni parola di una pagina web interattiva! Non sono amante di firefox ma per questo plug in potrei cominciare ad utilizzarlo quotidianamente.
L'idea è quella di consentire una interazione ogni parola e accedere velocemente da un semplice menu a wikipedia, google maps, il client di posta e molto altro...
Che dire, guardate il video su you tube e ditemi se non fa gola anche a voi!!!!
Letto su...
http://www.downloadblog.it
L'idea è quella di consentire una interazione ogni parola e accedere velocemente da un semplice menu a wikipedia, google maps, il client di posta e molto altro...
Che dire, guardate il video su you tube e ditemi se non fa gola anche a voi!!!!
Letto su...
http://www.downloadblog.it
Passaggio di parametri tra pagine in ASP.NET, POST e GET e CROSS PAGE POSTING
La programmazione web classica prevede il passaggio di parametri dal client al server attraverso la tecnica GET o POST dei form HTML.
Quando ci si avvicina al mondo di ASP.NET si perde parzialmente il controllo dell'HTML che verrà generato e soprattutto non si riesce, semplicemente, a controllare i form ASP.NET in quanto le pagine vengono generate con 1 form html con action impostata automaticamente alla pagina stessa.
Cercando nella MSDN ho individuato le guide lines Microsoft per effettuare il CROSS PAGE POSTING DATA, e quindi risolvere il problema di passaggio dei parametri tra pagine ASP.NET.
Cross-Page Posting in ASP.NET Web Pages
How to: Redirect Users to Another Page
Quando ci si avvicina al mondo di ASP.NET si perde parzialmente il controllo dell'HTML che verrà generato e soprattutto non si riesce, semplicemente, a controllare i form ASP.NET in quanto le pagine vengono generate con 1 form html con action impostata automaticamente alla pagina stessa.
Cercando nella MSDN ho individuato le guide lines Microsoft per effettuare il CROSS PAGE POSTING DATA, e quindi risolvere il problema di passaggio dei parametri tra pagine ASP.NET.
Cross-Page Posting in ASP.NET Web Pages
How to: Redirect Users to Another Page
How to: Post ASP.NET Web Pages to a Different Page
Iscriviti a:
Post (Atom)