ExcelExportExtender: from IQueryable to Excel with Asp.Net

I needed to export some query results to an Excel workbook from an Asp.Net 4.0 webpage.
The simplest way I found is to exploit Excel for all the stinky work.
Excel is able to understand an html form and to render it to a worksheet, so this is the starting point.
Thus, I also needed to have this export available on several pages and with different ObjectResult.
Then I decided to write an Extender for an IQueryable object that can get the work done.

This is how the class look like, with some comments

// A static class
public static class ExcelExportExtender
{
  static String C_CONTENT = "attachment;filename={0}.xls";

  // static method that extend an IQueryable
  public static void ExportToExcel(this IQueryable Data, 
    Page ParentPage, String FileName)
  {
    if (String.IsNullOrEmpty(FileName))
      throw new ArgumentNullException("FileName is null");

    HttpResponse ResponseObject = ParentPage.Response;
    GridView gdvList = new GridView();
    // Let's hide all unwanted stuffing    
    gdvList.AllowPaging = false;
    gdvList.AllowSorting = false;
    gdvList.EditIndex = -1;
    // Let's bind data to GridView    
    gdvList.DataSource = Data;
    // We exploit the data binding for columns name!
    gdvList.DataBind();
    // Let's output HTML of GridView    
    ResponseObject.Clear();
    ResponseObject.ContentType = "application/vnd.xls";
    String head = String.Format(C_CONTENT, FileName.Trim());
    ResponseObject.AddHeader("content-disposition", head);
    StringWriter swriter = new StringWriter();
    HtmlTextWriter hwriter = new HtmlTextWriter(swriter);
    HtmlForm frm = new HtmlForm();
    ParentPage.Controls.Add(frm);
    frm.Attributes["runat"] = "server";
    frm.Controls.Add(gdvList);
    frm.RenderControl(hwriter);
    ResponseObject.Write(swriter.ToString());
    ResponseObject.End();
    }
}

and this is an example of how to utilize the ExcelExportExtender

	
protected void LinkButton1_Click(object sender, EventArgs e)
{
  FakeDataAccess fda = new FakeDataAccess();
  var DataToExport = from r in fda.RandomData
                     where (r.MyFirstProperty % 2 ==0)
                     select r;
  // only for learning purposes =)
  IQueryable result = DataToExport.AsQueryable();
  // "this" refers to the Page where this method lives
  // Let's rock!
  result.ExportToExcel(this, "EvenRecordsFileName");
}

Job Done!
Download the source code and the example project here!

How to get a simple but good form validation

I used to get the form validation by hand, with some ugly checks, message boxes, several boolean variables to combine with a lot of operators && and ||. A TOTAL mess.

My target was to provide a simple validation tool that I can spread (by inheritance) to all the forms in a project.
So if your project needs only a simple check for mandatory fields, the solution I found maybe can interest you. If you need something more sofisticated, you can imagine an extension of this solution to suite your needs.

How to get it

In a base form class, the parent of all my forms in the project, get an instance of an ErrorProvider, by putting it into the form. Be sure to have “Modifier” property set to “Protected”.
By default, the form property AutoValidate is set to EnablePreventFocusChange. This way, all the controls fire up Validating Event when it’s time to, and the focus will remain on the control when the validation fails.
In this base form we have to add two methods: ValidateControl and SetValidationHandlerOnControl.
The first one is the method that will handle the validation on the control we need to check.
The second one will add the validation handler to the control.

namespace ValidationTest{
  public partial class MyBaseForm 
  {
    ... 
    protected void ValidateControlHandler(object sender, CancelEventArgs e)
    {
      // this string will be the tooltip shown when an error appears
      String error = null;
      String textToCheck = String.Empty;
  
      // we need to be sure that the sender control is 
      // of the type System.TextBox
      Type senderType = sender.GetType();
      if (senderType == typeof(TextBox))
        textToCheck = ((TextBox)sender).Text;
      else 
        throw new ArgumentException(
  	    "The sender is not a TextBox, but a " + senderType.Name);
  
      // Mandatory field: if the textToCheck is null or empty, fire up the error 
      if (String.IsNullOrEmpty(textToCheck))
      {
        error = "Mandatory field"; 
        // this CancelEventArgs property locks the pointer over the control 
        // until the error disappears
        e.Cancel = true;
      }
  
      // if there isn't any error, the SetError get a 
      // null string and it will not shown.
      // otherwise the SetError will show an icon and a tooltip 
      // next to the control that fails the validation
      errorProvider.SetError((Control)sender, error);
    }
  
    protected void SetValidationHandlerOnControl(Control ctrl) 
    { 
      // we need to be sure that the sender control 
      // is of the type System.TextBox
      Type ctrlType = ctrl.GetType();
      if (ctrlType == typeof(TextBox))
        ctrl.Validating += new CancelEventHandler(this.ValidateControlHandler);
    }
  }
}

Ok, that’s almost done.
Now, if we had a form that inherits from MyBaseForm, we can add the controls we need to validate with a simple call to SetValidationHandlerOnControl.
Let’s consider that we have three TextBoxes: by default they all have property CausesValidation set to true. And let’s have a button that is the default AcceptButton for the form, with the TabIndex property value set to be greater than the TabIndex value of the textboxes.
So we need to call

namespace ValidationTest{
  public partial class MyChildForm : MyBaseForm
  {
    public MyChildForm(){
      InitializeComponent();
      SetValidationHandlerOnControl(this.textBox1);
      SetValidationHandlerOnControl(this.textBox2);
      SetValidationHandlerOnControl(this.textBox3);
    ...
    }
  }
}

that’s it!
Now if we don’t provide any string in one of the textBox, the ErrorProvider will show a little (!) icon near to the textBox, the focus will remain on until the string is null or empty. (See image below)
validation
Get the solution with this example here (18Kb). Hope you’ll find it interesting…
Comment out the article if you like it!

EDIT: corrected a typo. Sorry!

Singleton Pattern per C#

Singleton Pattern per C#

piccolo esempio di pattern singleton thread safe per C#. dal momento che lo uso molto spesso e che devo copiarmelo di qua e di là, ho deciso di scriverlo sul sito, che almeno so sempre dove trovarlo =D
ciao

public class Oggetto 
{
   #region Singleton
   //singleton pattern
   private static bool _isInit;
   private static Exception _error;
   private static volatile Oggetto _instance = null;
   private static object _syncObj = new object();

   /// 
   /// Get the Oggetto Instance
   /// 
   public static Oggetto Instance
   {
      get
        {
           if (_instance == null)
           {
              lock (_syncObj)
	      {
                 if (_instance == null)
                    _instance = new Oggetto();
              }
           }
           if (_isInit)
              return _instance;
           else
              throw new Exception(
                 "Error initializing Oggetto", _error);
        }
   }

   private Oggetto()
   {
      try
      {
         InitData();
         _isInit = true;
      }
      catch (Exception ex)
      {
         _isInit = false;
	 _error = ex;
      }
   }
   #endregion

   private void InitData()
   {
      // qua ci va l'inizializzazione
   }

   // comodo per reinizializzare tutto, se serve
   internal void RefreshCache()
   {
      this.InitData();
   }
}

c#, dotnet, lavoro, pattern, singleton, best practices

Java vs C#

Da qualche settimana ho cambiato lavoro: ho lasciato la società di consulenza e adesso lavoro per un gruppo piuttosto grande, anche qui come sviluppatore.
I cambiamenti non sono stati solo esteriori, ma anche di contenuto. Infatti sono passato dallo sviluppo Java/Oracle a quello C#/SqlServer. “Oddio!” direte voi… beh, all’inizio lo dicevo anch’io.
Sto valutando le analogie e le differenze tra questi due mondi, cercando di riutilizzare al massimo l’esperienza che ho in Java nel nuovo ambiente. Ora, da utente e da contributore dell’Open Source, passare a M$ mi fa abbastanza impressione, ma considero il mio un lavoro che usa l’astrazione, quindi mi devo slegare dal pensiero del “basso” livello (linguaggi, compilatori, sistema operativo), e devo pensare al codice e a quanto bene sono capace di scriverlo, a come possa funzionare il programma che faccio, senza altro. Sì, questo potrebbe sembrare un esercizio di retorica o di teologia informatica…
Ora comincio con le considerazioni che sto facendo da quel poco che ho imparato nell’ambiente M$, spiegando un po’ l’effetto che mi fa.
Prima di tutto devo ribadire che lavoro per una grande azienda, quasi tutti gli utenti hanno client Windows, ci sono decinaia di server attivi, dall’AS/400 al Linux, da Sap con NetWeaver all’ultimo WS2003 con Sharepoint. C’è chi lavora in Cobol (ancora!), chi è espertissimo di VBA, c’è gente che fa in Excel robe che credevo impossibili (sul grado di affidabilità dei risultati non metterei la mano sul fuoco), c’è tanto lavoro in Java e altrettanto in C#.
Ora, quello che M$ permette, in virtù della sua posizione quasi monopolistica, è un altro grado di integrazione: condivisione dei dati, remote desktop, deploy delle applicazioni. Il lato negativo è che, come dice nonmiricordochi, “fai un programma a prova di stupidi e solo gli stupidi lo useranno”. Non siamo a questo punto, però il fatto che la programmazione per Window$ sia piuttosto semplice, corrisponde al fatto che i lavori non sempre sono eseguiti con rigore.
Faccio due esempi.
Comincio con la gestione delle eccezioni in C#: esiste ma non è obbligatoria. Cioè tu puoi eseguire un metodo che potenzialmente può generare un’eccezione e non prendertene carico. In Java è obbligatorio gestire l’eccezione, e l’errore di non farlo viene segnalato a compile-time. In C# puoi scrivere tutto il codice che vuoi senza usare mai try{} – catch(){}. È una cazzata! Un oggetto genera un’eccezione, non gestita, e si schianta tutto il programma. Ora questo modo di fare avvicina i “programmatori”, perchè è “facile” programmare così, ma il codice e il programma che ne esce è debole.
Secondo esempio: ASP.Net è la controparte web delle applicazioni Web, ed usa lo stesso paradigma degli eventi. Ogni pagina web è un “form” allo stesso modo che in un’applicazione client. E allo stesso modo risponde agli eventi, tipo button_click, che esistono sul client. Questo rende “facile” per un “programmatore” scrivere sia codice per client che per web, perchè sono praticamente identici. Ma in questo modo non c’è una chiara separazione del modello dalla presentazione e dal controller (ossia non c’è un paradigma MVC dietro) e lo “spaghetti code” imperversa. E inoltre la parte di presentazione, di default, è renderizzata con codice HTML 4.01, con un sacco di javascript auto-generato da visual studio. volendo si può costringere la pagina a usare codice XHTML 1.0, ma volendo usare XHTML 1.1 Strict, i controlli web non funzionano perchè sono fuori standard.
Il css non esiste. Questo perchè Visual Studio ti permette di definire le proprietà degli oggetti della pagina in modo “così semplice”, che scrive lui tutto lo stile per gli elementi in modalità “in-line”! Quindi se ti va di cambiare il colore delle pagine devi andare a modificarle tutte, invece di cambiare una riga nel css…
Insomma, l’approccio generale mi sembra questo: “guarda che bei bottoni colorati, clicca qui e là, è facilissimo programmare…” e il risultato è lo spaghetti-code.
In Java si può scrivere codice bruttissimo, ma un minimo di “metodo per fare le cose per bene” c’è, e questo in C# mi manca
ma io ormai sono in ballo, e cercherò di ballare meglio possibile… alla prossima (e via alla flame war!)