Le WebParts che faranno parte della prossima versione di ASP.NET 2.0, offrono l'occasione di implementare un framework di connessione cross-page che consenta a delle WebParts Consumer, di condividere informazioni provenienti da un Producer. L'articolo che segnalo è una lettura interessante in merito, con tanto di codice di esempio.

Fonte: WebParts and Cross-Page Connections

Interessante notare che in fondo alla pagina di queso post si può vedere implementato un eccellente metodo anti-spam che fa uso delle HIP.

powered by IMHO


La NotifyIcon, che tempo fa avevo rilasciato con un articolo, ha subito la medesima sorte del provider per Isolated Storage che ho rilasciato stamane.

E' possibile scaricare il sorgente completo dal sito di Sourceforge e anch'essa ricade sotto i termini della Common Creative Public License.

Ovviamente chi ne ha ricevuto/scaricato una versione precedente sotto GPL o LGPL continuerà a poterne fruire sotto i termini di quelle licenze.

powered by IMHO 1.1


Sviluppando le nuove feature di IMHO, mi sono trovato a dover estendere il Configuration Management Application Block di Microsoft. L'estensione che ho creato permette di utilizzare L'IsolatedStorage per rendere persistenti le informazioni di configurazione in formato XML, anche crittato e firmato.

Ho pubblicato la libreria e il relativo sorgente all'interno del progetto IMHO, presso Sourceforge. La libreria consta di una classe IsolatedXmlFileStorage realizzata come un provider di storage per l'application block. Essa può essere facilmente collegata ad una applicazione semplicemente modificandone il file di configurazione.

Ecco uno spezzone di codice:

<applicationConfigurationManagement defaultSection="configFile">
    <configSection 
name="configFile">
        <configProvider 
            
assembly="Elite.ApplicationBlocks.ConfigurationManagement,Version=1.0.1833.0,Culture=neutral,PublicKeyToken=null"
            
type="Elite.ApplicationBlocks.ConfigurationManagement.IsolatedXmlFileStorage"
            
file="app.config"
            
signed="true"
            
encrypted="true"/>
        <protectionProvider
            
assembly="Microsoft.ApplicationBlocks.ConfigurationManagement,Version=1.0.0.0,Culture=neutral,PublicKeyToken=null" 
            
type="Microsoft.ApplicationBlocks.ConfigurationManagement.DataProtection.DPAPIDataProtection"
            
hashKey="Ae5+5644aB=" />
    <
/configSection>
<
/applicationConfigurationManagement>

Non appena il sito http://www.imhoproject.org sarà pronto, questa libreria e le altre saranno spostate in una apposita sezione del sito.

La licenza per la libreria è la Common Creative Public License

powered by IMHO 1.1


Quello che mi è successo stamattina mi ha incoraggiato ad iniziare una nuova "rubrica" nel mio weblog, dedicata a tutte quelle cose che, a meno che non ci si legga il manuale fino all'ultima virgola (come peraltro bisognerebbe fare), si arriverà a conoscere per pura coincidenza.

Il primo post riguarda l'uso del carattere chiocciola in C#. Tutti sapranno che quando si scrivono delle stringhe in C#, anteporre la chiocciola consente di adottare una diversa politica di escape.

Così mentre questo non è consentito:

string a = "d:\myfolder";

Con l'uso della chiocciola diventa possibile:

string a = @"d:\myfolder";

Fin qui nulla di nuovo, senonché stamattina stavo facendo qualche test con il DOM del MsHTML control e mi sono imbattuto in un uso curioso ma utilissimo della chiocciola che sinceramente non mi era mai capitato di incontrare.

Digitando la seguente stringa:

int key = this.DOM.parentWindow.event.keyCode;

Mi sono trovato automaticamente una cosa del genere:

int key = this.DOM.parentWindow.@event.keyCode;

Di primo acchito ho creduto di aver digitato male, non sono esattamente un dattilografo, alla tastiera. Ma rimuovendo la chiocciola evidentemente la parola chiave "event" è stata sottolineata evidenziando l'errore. Personalmente sono abituato a evitare come il male l'uso delle parole chiave nella nomenclatura del mio codice, ma riconosco che, accedendo ad esempio al DOM dell'HTML che è fatto per il Javascript sarebbe impossibile farlo senza questa scappatoia.

Naturalmente non pago ho fatto un po' di prove:

myObject.@public
myObject.@fixed
myObject.@protected
...

Consiglio: non chiamate mai public, fixed o protected un membro di una vostra classe. Non occorre dirlo, ma magari è utile ricordarlo.

Curiosità nella curiosità, il Syntax Highlighter di SharpDeveloper non riconosce la chiocciola come carattere di escape valido. Infatti, mentre VS.NET indica le keyword in nero quando viene preposta la chiocciola, per l'IDE di SharpDeveloper (che come molti sapranno è il fulcro del Code Snipped Editor di IMHO), la lascia in blu. Sarebbe interessante sapere se si tratta di una dimenticanza oppure se anche agli sviluppatori di questo ambiente di sviluppo sia sfuggita questa utile feature.

Sono ovviamente andato a vedermi l'SDK, ma non sono riuscito a trovare alcun riferimento a questo uso della chiocciola. Appena ho un attimo approfondirò le specifiche di C#, a meno che non ci sia già qualcuno che mi segnala dove trovare questo argomento.

powered by IMHO 1.1


Mi sono spesso chiesto quale dei due modi di scrivere fosse migliore:

// codice 1

if ( a == 0 )
    
return "OK";
else
    return 
"KO";
    
// codice 2

if ( a == 0 )
    
return "OK";

return "KO";

In realtà poi a intuito mi sono abituato ad usare il modo 2.

Oggi, lavorando un po con il CodeDom ho scoperto una cosa interessante: se si usa il modo 1 il compilatore automaticamente lo trasforma in 2. Probabilmente questo deriva dal fatto che l'IL generato è comunque il medesimo, ma potrebbe anche essere che si tratti di una ottimizzazione. A questo non so dare risposta, dato che non conosco bene l'IL.

powered by IMHO


Ieri sera mi sono letto un articolo di MSDN che ho considerato illuminante rispetto le problematiche di gestione della memoria in ambiente managed. Mi hanno molto impressionato i benefici che una attenta applicazione di alcune regole può portare in termini di utilizzo della memoria. Vorrei riportare un esempio limpido di questo, direttamente tratto dall'articolo in questione:

// Struttura 1 ****

struct BadValueType
{
    
char c1;
    
int i;
    
char c2;
}

// Struttura 2 ****

struct GoodValueType
{
    
int i;
    
char c1;
    
char c2;
}

Le due strutture riportate nel riquadro possono apparire del tutto uguali, se non fosse per il diverso ordine dei membri. Andando ad analizzare però la dimensione fisica in memoria ci si renderà conto che mentre la prima, occupa 12 bytes, la seconda si accontenta di 8.

La soluzione del mistero sta nel problema dell'allineamento in memoria dei bytes. La struttura 1, avrà 2 bytes per il char, due bytes di padding a 4° byte, 4 byte per l'int, altri due bytes per il secondo char e infine un altro padding al 4° byte. In totale 12 bytes. Nel secondo caso invece avremmo 4 byte per l'int, e consecutivamente 2+2 bytes contigui per i char che tra loro non necessitano di padding.

Se il risparmio di 4 bytes può risultare una banalità, proviamo ad immaginare cosa succederebbe se questa struct facesse parte di una collection di centinaia di elementi. Il risparmio ammonta a 1KB ogni 256 elementi. Non male per aver solo invertito due membri in una struct.

L'articolo completo lo si può trovare a: http://msdn.microsoft.com/msdnmag/issues/05/01/MemoryOptimization/default.aspx

powered by IMHO


Leggendo gli articoli che sono linkati dal post di Pierre sono rimasto fortemente impressionato da quanto facile potrebbe essere implementare questo pattern in .NET, specialmente in ambiente Windows Forms. Quello che avviene normalmente in una applicazione è che la form (a.k.a view) interroga il database, tipicamente attraverso una serie di strati intermedi e popola ad uno ad uno i controlli in essa contenuti. Ques'ultima operazione avviene per mezzo del Databinding che consente al programmatore di "dimenticarsi" del dato dopo che lo ha affidato al controllo fintanto che non se lo andra a "riprendere" direttamente nell'oggetto di business cui esso è collegato.

Nel codice di Fowler, questa parte è rappresentata da una serie di metodi set() e get() che non fanno altro che scrivere e leggere i "controlli" in risposta alla loro modifica. In .NET tutto ciò si potrebbe tranquillamente realizzare esponendo all'esterno le proprietà dei controlli e "bindando" gli oggetti di business a queste ultime piuttosto che ai controlli stessi. In questo modo tutto il codice di set() e get() è semplicemente "inutile". Non resta altro che da agganciarsi agli eventi dei pulsanti Ok e Cancel e leggere/scrivere gli oggetti di business nel supporto di persistenza.

Poniamo ad esempio di avere una form che espone la checkbox dell'esempio di Fowler:

public class AlbumForm : Form
{
    
private CheckBox chkIsClassical;

    
public AlbumForm()
    {
        
// inizializzazione controlli
    
}
    
    
public bool IsClassical
    {
        
get return chkIsClassical.Checked;  }
        
set { chkIsClassical.Checked = value; }
    }
}

La nostra classe Presenter non dovrà fare altro che istanziare la View e poi fare il bind dell'oggetto di business (model)

public class AlbumPresenter
{
    
public void LoadViewFromModel( Form form, Album album )
    {        
        Binding binding = 
            form.DataBindings.Add( "IsClassical", album, "IsClassical" );
    }
    
    
public void LoadModelFromView( Form form, Album album )
    {    
        form.BindingContext[ album ].EndCurrentEdit();
        UpdateModel( album );
    }

    
public void EditAlbum( Album album )
    {
        AlbumForm form = 
new AlbumForm();

        LoadViewFromModel( form, album );
        
        
if ( DialogResult.Ok == form.ShowDialog() )
            LoadModelFromView( form, album );
    }
}

Il codice l'ho buttato giù direttamente nel post, senza verificare che compili, ma direi che di primo acchito la cosa può funzionare. Sarebbe interessante capire se ci sono delle responsabilità che possono essere accomunate da una classe astratta Presenter oppure da una View.

Naturalmente la domanda che mi sorge è: è davvero così semplice oppure ho scordato di considerare qualcosa?

powered by IMHO 1.1


Ho appena scoperto che la mia segnalazione in merito a Define Event & Stay ha ottenuto risposta nel Product feedback center.

Ecco come:

Resolved as Won't Fix by Microsoft on 2004-12-27 at 12:53:07    
Hey there -

I absolutely agree that if you're trying to wire up multiple events at once, our default behavior (of jumping to the event handler) is cumbersome. The experience is optimized for folks working in serial rather than "multi-pass" - that is, dropping a control, naming it, labelling it, hooking up an event and writing code for it, etc. We'll consider ways of addressing this in future versions of the designer, however.

Thanks!
Jeff

Fonte: MSDN Product Feedback Center

Ma voi davvero lavorate così?

powered by IMHO


Stamane mi sono accorto di una cosa strana, che non riesco a spiegare.

Il seguente codice ritorna true:

 public void Main()
 {
     
string test = "1.0.....2";
     
     
double doubleResult;
     
     Console.WriteLine( 
         
double.TryParse( test, NumberStyles.Any, CultureInfo.CurrentCulture, out doubleValue ) );
 }

Ma con tutta la buona volontà non riesco a capire come "1.0.....2" possa essere un double valido. Va detto per inciso che sul mio pc il punto è considerato il separatore delle migliaia, tuttavia questo non va certo a migliorare la situazione.

powered by IMHO