Posts
163
Comments
179
Trackbacks
5
ottobre 2007 Blog Posts
AutoCompleteExtender: modificare la larghezza della lista

Giornata di problemi con l'AutoCompleteExtender. Generalmente utilizzo l'AutoCompleteExtender associato a textbox abbastanza lunghi. In questi casi non ho mai ricontrato problemi con la larghezza della lista degli elementi che di default viene settata identica alla lunghezza del textbox.
Cosa succede però se abbiamo un textbox con dimensioni ridotte e una lista con elementi molto lunghi? In questo caso gli elementi vanno a capo su una o più linee. Non c'e' problema mi dirite voi, da CSS si può modificare la dimensione associando una classe alla proprietà CompletionListCssClass dell'AutoCompleteExtender.

Eh invece no! Se si modifica semplicemente l'attributo Width non succede un beneamato piffero. Andando a sbirciare nel JS dell'AutoCompleteExtender troviamo infatti la seguente riga di codice:

this._completionListElement.style.width = Math.max(1, elementBounds.width - 2) + 'px';

La soluzione è abbastanza semplice, nel CSS basta aggiungere la dichiarazione !Important dopo l'attributo Width.
Se si specifica un valore fisso per la larghezza tutto funziona correttamente, mentre se si specifica 'auto' a volte si verifica un piccolo problema di visualizzazione: la lista viene infatti visualizzata con dimensione nulla.

A mio giudizio la soluzione ideale sarebbe avere una proprietà aggiuntiva nell'AutoCompleteExtender che permetta di scegliere se avere la lista con le stesse dimensioni del textbox o se averla con dimensioni "custom".


Technorati Tags: ,


posted @ mercoledì 31 ottobre 2007 16:25 | Feedback (0)
Lista di "Undefined" restituiti dall'AutoCompleteExtender

Aggiornando l'Ajax Control Toolkit all'ultima versione potrebbe nascere un problema utilizzando l'AutoCompleteExtender.
La lista dei valori recuperati potrebbe essere tutta a "Undefined". Dico potrebbe, perchè il bug salta fuori solo se il nostro metodo del Web Service (o PageMethod) restituisce una serie di interi.

In questo caso il nuovo sistema che permette di gestire le coppie chiave/valore, entra in gioco e genera il bug come spiegato in questo Issue sul sito del progetto. Il bug dovrebbe essere già stato risolto in uno dei changeset, ma se non potete attendere ecco un fix veloce:

values.Add(AjaxControlToolkit.AutoCompleteExtender.CreateAutoCompleteItem(value, value))

Sostanzialmente si tratta di creare, attraverso il nuovo metodo CreateAutoCompleteItem, un elemento composto da chiave/valore assegnando sia al valore che alla chiave il nostro intero.

Technorati Tags: ,


posted @ mercoledì 31 ottobre 2007 13:25 | Feedback (0)
Far convivere Thickbox e UpdatePanel

Ho già citato in precedenza la libreria javascript jQuery. Per chi non la conoscesse consiglio vivamente di fare un salto sul sito e verificare cosa permette di fare.

Comunque su jQuery sono basati anche tutta una serie di plug-in che permettono di avere animazioni ed effetti, drag and drop, accordion e via di questo passo. Tra tutti questi plug-in quello che forse è il più conosciuto è il Thickbox che consente di aprire dei popup stile il ModalPopupExtender dell'AjaxControlToolkit.

L'aggiunta di questo popup è molto semplice: oltre all'inclusione dei file js e dei css relativi, è sufficiente aggiungere ad un generico anchor la classe thickbox:

<a href="fckedit/popup.aspx?TB_iframe=true&height=500&width=700" class="thickbox">Edit</a>

Nel mio caso utilizzo il Thickbox per visualizzare una pagina ASPX in cui è incluso l'FCKEditor.
Tutto funziona senza problemi fino a quando non si va ad inserire l'anchor in un UpdatePanel. Qui iniziano i problemi. Infatti dopo un AsyncPostback, generato da uno qualsiasi dei controlli presenti nell'UpdatePanell, i nostri anchor torneranno ad essere dei "link" normali e non apriranno più nessun popup.

Il perchè è dovuto al fatto che al caricamento lo script del Thickbox (come del resto quello del suo cugino Lightbox), esegue una funzione di inizializzazione (TB_init) che scorre il DOM alla ricerca degli anchor con la classe "thickbox" aggiungendo un handler che esegue lo script custom al click del link. L'handler si va a prendere i parametri direttamente dall'href. Nel caso precedente viene aperta una pagina ASPX in un iFrame e viene impostata la dimensione del popup.

Come ha giustamente sottolineato Marco nel forum "Il problema è che, dopo un AsyncPostback, il nodo <A> è un'istanza *DIVERSA* da quella precedente, pertanto senza l'handler che fa tutta la magia".

Per risolvere il problema è necessario quindi reinizializzare il thickbox ogni volta che viene eseguito un AsyncPostBack. Sempre grazie a Marco  la soluzione è quella di aggiungere la seguente funzione lato client (a meno che di fare obrobri lato server come avevo fatto io ):

function pageLoad() { var isAsyncPostback = Sys.WebForms.PageRequestManager.getInstance().get_isInAsyncPostBack(); if (isAsyncPostback) $(document).ready(TB_init); }

Non è necessario richiamare la funzione pageLoad in quanto viene richiamata dall'MS Client Script Library al caricamento della pagina.
L'unica accortezza è quella di non richiamare più volte la funzione TB_init, in quanto si andrebbe ad aggiungere più volte l'handler ai vari anchor (il controllo sul tipo di postback serve proprio a questo).


Update: aggiornata la soluzione al problema in base al commento del solito Marco :)


Technorati Tags: , ,


posted @ giovedì 25 ottobre 2007 15:05 | Feedback (3)
Post e tips per ASP.NET e AJAX

Segnalo, per chi come me non lo conosceva, un interessante blog con un sacco di post e tips sulla personalizzazione grafica dei controlli ASP.NET e Ajax:

http://mattberseth.com/blog/

Tra i vari post due mi sono stati molto utili:


Technorati Tags: ,


posted @ giovedì 25 ottobre 2007 13:03 | Feedback (0)
Creare file ZIP in .NET senza la SharpZipLib

Post interessante su una delle richieste più comuni:

http://weblogs.asp.net/jgalloway/archive/2007/10/25/creating-zip-archives-in-net-without-an-external-library-like-sharpziplib.aspx

Personalmente non sapevo dell'esistenza della .NET Zip Library. 

 

Technorati Tags: ,


posted @ giovedì 25 ottobre 2007 11:54 | Feedback (0)
Sempre sul lavoro del programmatore

Dopo la mia riflessione precedente, segnalo questo post di Daniele Bochicchio.
Chiaramente quoto tutto al 100%, comprese le virgole e i punti. Stavo iniziando a lasciare un commento, ma dato che stava diventando un po' troppo lungo ho deciso che forse era meglio esprimere il mio parere direttamente con un post.

Il divertimento e la passione sono due componenti fondamentali nel nostro lavoro. Se mancano, come dice Daniele si cade nella noia e nella depressione e si va avanti facendo stancamente il proprio compitino.

Mi chiedo questo però: e' così difficile per un datore di lavoro capire che in un'azienda informatica i programmatori sono fondamentali? E' così difficile capire che se si lavora con dei computer obsoleti o con dei monitor CRT vecchi di decenni e sfarfallanti non si sta certamente lavorando nelle condizioni migliori?

Fortunatamente attualmente non sono in queste condizioni, ma fino a qualche mese fa la situazione era quella. Mi sono sempre chiesto una cosa: ma perchè deve essere sempre il programmatore a "scassare i maroni" per avere un computer decente? Partendo dal presupposto di voler utilizzare le ultime tecnologie presenti sul mercato e non VB6, non sarebbe il datore di lavoro il più interessato ad avere i dipendenti il più efficiente possibile? Come dice Daniele il PC del programmatore dovrebbe essere il più pompato dell'azienda, più di quello del titolare che magari lo usa solo per mandare qualche messaggio email o per scrivere documenti con Office.

Invece stranamente non è così, o almeno spesso non è così. Capisco che ci siano problemi di bilancio, di entrate e di uscite, ma si lavora nel campo dell'informatica, si lavora con i computer, non si stanno costruendo cucine. La cucina magari dura e funziona bene per 10 anni, il computer dopo 10 anni lo puoi usare solo come fermacarte.

Sull'orario non sono così "libertino" come Daniele. Capisco anche che, quando si lavora in gruppo e con tanti colleghi, non si possa avere un orario completamente flessibile. Altrimenti se ognuno avesse esigenze diverse, ci si vedrebbe veramente poco in ufficio!
Però vanno considerate tante altre cose:

  1. Arrivare mezz'ora (o un'ora) dopo alla mattina o uscire prima alla sera non cambia molto i rapporti aziendali.
  2. Visto che spesso gli straordinari non si pagano, se si esce un'ora prima un giorno e si rimane un'ora di più il giorno dopo ci dovrebbe essere una compensazione. Invece sembra che conti solo l'ora che si è preso di permesso (sto parlando in generale, attualmente per mia fortuna la mia situazione non è questa!).
  3. Se c'e' un'assistenza tecnica che ha orari fissi, i programmatori non devono essere obbligati a seguire lo stesso orario, tranne in casi di  necessità particolari. Sono due lavori diversi e i dipendenti non sono tutti uguali. Chi fa assistenza tecnica è giusto che sia reperibile nell'orario che si è prestabilito.
  4. La settimana ha cinque giorni lavorativi. Il pomeriggio quasi tutti vanno a casa con orari che vanno dalle 17 alle 18. Perchè mai le riunioni si devono fare sempre il venerdì pomeriggio 10 minuti prima di andare a casa? C'e' un qualche accordo segreto che obbliga i datori di lavoro a questo genere di "soprusi"?

Ultima questione: i tempi dello sviluppo. Scrivere codice alla velocità della luce, senza progettazione, senza analisi, senza uno straccio di commento (no le parolacce lasciate qua e la nel codice non contano come commenti), senza  documentare in nessun modo quello che si sta facendo, porta (non sempre) a rilasciare accrocchi semi-funzionanti in tempi rapidi. Lavorando in questo modo però qualche problemino prima o poi nasce....
Quindi se poi il cliente BIG01 si inca**a come una salamandra quando dopo qualche giorno l'accrocchio smette di funzionare (di solito succede sempre a ridosso della riunione citata al punto 4), non ci si deve stupire più di tanto!

posted @ martedì 16 ottobre 2007 12:26 | Feedback (11)
Riflessione personale: i programmatori e le nuove tecnologie

Ieri il post di Simone ha indotto anche me ad una riflessione. Però la mia riflessione non è ne su Architetetti vs. architetti ne su ALT.NET vs "MS tools and technologies, bensì sul rapporto tra i programmatori e le nuove tecnologie.

In particolare ragionavo su questa frase che in quest'ultimo periodo mi tocca in modo particolare:

I don't want to point the finger against anyone, but in my experience with previous jobs, I was the only one interested in staying up to date with the technologies, learning new approaches. I was the only one that fought with the CTOs to setup a CI process and introduced a kind of TDD approach inside the projects. In January, I was the one that informed the dev team that there was a new version of the .NET framework, version 2.0 (no, not the 3.5, the 2.0... and it was 2 years after is has been released).
So, I might have been very unlucky, but the truth is that 80% or more of the developers only care about working 9 to 5, have their work done with the least possible effort, and don't study to stay up to date with the new trends or technologies, they goes to user group meetings only if they are during the working hours and their employer doesn't take off a day of annual leave.

Penso che la situazione descritta da Simone sia comune a molti e che i fortunati che riescono ad applicare nel lavoro le tecnologie appena uscite siano veramente pochi se rapportati alla totalità dei programmatori. Ma non sempre è colpa della "mediocrità" dei programmatori o della loro scarsa voglia di innovarsi (non dico che non ci siano casi di questo genere, tutt'altro!). Questo credo sia particolarmente vero per chi lavora come dipendente.

Per quanto mi riguarda attualmente sono l'unico nella mia nuova azienda ad avere una certa esperienza con .NET e in particolare con la versione 2.0. Tutti gli altri sono ancora "ancorati" a VB6 e in particolar modo ad ASP. Non credo che una situazione del genere riguardi solo noi.

Il motivo di questa "staticità" non va però ricercato in una scarsa volontà dei singoli, ma bensì va ricercato nelle "dinamiche aziendali". Nella pratica si corre tutte il giorno inseguendo un progetto dopo l'altro, inseguendo un cliente dopo l'altro. Il prodotto attuale funziona, è solido, è stato installato e personalizzato decine e decine di volte. I clienti sono contenti e soddisfatti. Perchè cambiarlo? Perchè "perdere" tempo a convertitlo? Chiaramente le mie sono domande retoriche e, ad onor del vero, anche da noi si è cominciato il lento processo della conversione verso il mondo .NET.

Ma è un processo lungo, difficile e soprattutto costoso. Oltre alla riprogettazione del software, vanno formate principalmente le persone, che devono sperimentare, studiare e assimilare i nuovi concetti, i nuovi costrutti, i nuovi ambienti di sviluppo. Ma se fanno questo, non producono, non fatturano (detto in termini "commerciali"). Non tutti infatti hanno la possibilità di studiare nel tempo libero. Gli impegni sono per tutti mille e il tempo libero è sempre più ridotto.

E allora? E allora si rimane ancorati, al proprio sapere, alla tecnologia che si sa usare da anni e che non ha mai "tradito". Questo fino a che qualcosa non scoppia. Quando la tecnologia usata diventa talmente obsoleta da essere percepita come tale anche dai clienti finali.  Quando si inizia ad avere difficoltà a vendere i propri prodotti perchè il cliente percepisce la loro "obsoloscenza", perchè ad esempio,  l'interfaccia grafica non è quella che è abituato a vedere nei programmi comunemente usati.

Allora si che si corre ai ripari, ma forse è troppo tardi...

posted @ venerdì 12 ottobre 2007 15:42 | Feedback (9)
Trasferire variabili di sessione tra ASP e ASP.NET

Purtroppo non sempre il passaggio da ASP a ASP.NET è così immediato. Spesso ci sono in piedi tante applicazioni vecchie, più o meno complesse, che funzionano egregiamente ma che vanno gradualmente migrate verso .NET.

Spesso e volentieri tali applicazioni sono installate da molti clienti e necessitano di manutenzione e aggiornamenti. E spesso e volentieri migrare in uno solo step a .NET significa un impegno molto onoreso sia in termini di tempo sia in termini di costi.

In questo scenario (penso comune a molti) la soluzione che si potrebbe adottare è quella della migrazione graduale, magari realizzando i nuovi moduli direttamente in ASP.NET. In una situazione del genere può sicuramente tornar utile il seguente articolo che illustra un metodo abbastanza semplice per il passaggio di variabili di sessione tra ASP e ASP.NET:

http://www.eggheadcafe.com/articles/20041017.asp

La stessa metodologia può anche essere applicata alle variabili di applicazione. La cosa interessante di questa soluzione è che, a differenza di molte altre che ho trovato, non fa uso di cookie, ma usa una semplice struttura XML.

Technorati Tags: , ,


posted @ giovedì 11 ottobre 2007 11:37 | Feedback (1)
L'importanza della documentazione

In questi giorni sono veramente stressato! Sono alla prese con l'integrazione di un web service sviluppato da una compagnia straniera.
Il suddetto web service viene accompagnato con un file .chm che "dovrebbe" illustrare e descrivere i vari metodi disponibili. I metodi elencati in questa "reference" sono 12, tutti con la stessa signature: file XML in input e file XML in output.

La prima sopresa è che se ci si collega al web service i metodi che si trovano non sono 12 ma bensì 17. Quindi 5 sono magicamente scomparsi dalla documentazione o comparsi nel web service! Se siano utili o meno non lo so ancora, ma dal nome potrei intuire che potrebbero anche essere necessari.

Comunque passiamo oltre. Vista la signature delle funzioni mi sarei aspettato che almeno la struttura dei file XML di input e di output fosse descritta a sufficienza. Mi aspettavo che i vari tag, i vari attributi e i vari valori da specificare fossero dettagliati nella documentazione e che magari ci fossero esempi per i casi principali. Ovviamente non è così! Nella documentazione sono descritti i nodi "root" del file XML e gli attributi principali. Gli eventuali nodi figli (che NON sempre sono opzionali) e tutti gli altri attributi sono lasciati all'immaginazione del povero programmatore. Per fortuna insieme al file .chm sono disponibili anche una serie di file .XSD che permettono di capire come devono essere costruiti i file XML, anche se la maggior parte degli attributi sono di tipo stringa e non c'e' modo di sapere quali valori è possibile specificare.

Il risultato qual'e': si va a tentoni, provando, riprovando, contattando l'assistenza tecnica, inviando file XML errati e ricevendo in risposta le modifiche da effettuare. Per fortuna ogni tanto il web service (scritto in .NET) restituisce eccezioni in cui viene data una qualche indicazione sui nodi e sugli attributi mancanti.

Quello che mi chiedo è: visto che non c'e' un canone di assistenza, ne esiste un costo per ogni "ticket" o email inviate all'assistenza, non era meglio curare la documentazione ed evitare le decine di segnalazioni che presumo saranno inviate da programmatori come me?

posted @ giovedì 11 ottobre 2007 10:02 | Feedback (1)
[OT] - Post interessante su Google

Vorrei segnare un post veramente interessante dedicato a Google.
Ecco il link: http://blogs.devleap.com/romeopruno/archive/2007/10/01/google-ci-pensi-te.aspx.

Romeo mi vorrà scusare se non ho fatto troppa attenzione al testo   .

posted @ lunedì 1 ottobre 2007 21:26 | Feedback (1)
Aggiungere Gravatar in ASP.NET

Interessante terzo post di una "trilogia" dedicati ai Gravatar in ASP.NET.
Ecco il link:

http://weblogs.asp.net/jgalloway/archive/2007/10/02/gravatar-201-advanced-gravatars-in-asp-net.aspx

Technorati Tags: ,


posted @ lunedì 1 ottobre 2007 20:52 | Feedback (0)
[OT] - Ho già bisogno di ferie...

Ebben si, ho già bisogno di ferie. Forse lavoro troppo, forse sto facendo troppa fisioterapia, o forse sono semplicemente matto (ipotesi più che plausibile ).

Perchè dico tutto ciò? Stanotte mi sono sognato che a casa mia erano presenti due persone di Microsoft per un corso, una donna (no, non mi ricordo le fattezze!) e udite, udite Lorenzo.

Non mi ricordo assolutamente che tipo di corso fosse, so che c'erano tante persone. Dopo una prima introduzione di Lorenzo, la palla è andata all'altra insegnante e io e lui siamo andati in cucina a farci un caffè... Lascetelo dire Lorenzo, sei proprio maldestro! Mi devi una moka nuova!!

Che dite, mi ricovero subito o aspetto qualche giorno?

posted @ lunedì 1 ottobre 2007 19:50 | Feedback (2)
News
Se volete sapere con chi avete a che fare eccomi qui in uno "scatto" lavorativo.

La mia foto

Logo MCAD
Logo MCTS