venerdì 12 marzo 2010

Addin di Outlook per l'integrazione con TFS

Vi voglio segnalare un ottimo plugin per Outlook che offre alcune utili funzionalità di integrazione con Team Foundation.

Con questo addin è possibile creare "al volo" a partire da una mail, un task, un bug o in genere un qualsiasi work item configurato nel vostro progetto. Il plugin provvede inoltre a inserire il testo della mail direttamente nel field che avete impostato a livello di configurazione, così come l'oggetto della mail.
Ciò può tornarvi molto utile ,ad esempio, nella creazione di work item di tipo Bug, la quale è spesso conseguenza di una segnalazione via mail. Con questo addin, quindi, potrete a partire dalla mail inserire il Bug in TFS e monitorare in futuro il suo stato.

Infine due utilissimi bottoni hanno la funzione, rispettivamente, di aprire direttamente un work item creato in precedenza a partire dalla mail selezionata e di avere un rapido accesso alle query configurate sul server.

Ecco i link per scaricare l'addin:

Addin per Outlook 2003

Addin per outlook 2007

giovedì 11 marzo 2010

Modificare un Work Item Type in Team Foundation

Lavorando con Team Foundation diventa fondamentale adattare il modello di gestione del progetto che ci fornisce Microsoft out of the box (MSF for AGILE Software Development o il MSF for CMMI Improvement) al nostro modello che più preferiamo o più aderisce alla nostra realtà lavorativa.
A questo proposito vi descrivo come è possibile cambiare o aggiungere un Work Item Type, che è di fatto uno dei componenti principali di tutto il modello di gestione progettuale (che in TFS viene chiamato Process Template).
Innanzitutto è necessario che vi installiate i Power Tools di Visual Studio che vi aggiungono delle utili funzionalità per la gestione dei process template di TFS:
Power Tools for Visual Studio 2008
Nel caso volessimo modificare un Work Item Type già esistente è necessario aprire il menu di Visual Studio Tools/Process Editor/Work Items Type/Open WIT from Server, scegliere un progetto di TFS e un work item type.
A questo punto il work item type (WIT) viene aperto in editing. Nel primo tab Fields è possibile aggiungere un nuovo metadato al WIT o modificarne uno esistente. Prendiamo come esempio la modifica del WIT Task del nostro progetto, con l'aggiunta di un nuovo campo che rappresenti la difficoltà del task. Nel tab Fields premere New e inserire i dati del nuovo campo:



Nel tab Rules, invece, è possibile definire tutte le logiche di validazione, i valori di default, ecc... del campo in questione. Nel nostro caso inseriamo i possibili valori che il campo può assumere, utilizzando la rule ALLOWEDVALUES:



Ora è necessario inserire il nuovo campo nel form che TFS mostra nel momento in cui viene creato un nuovo Work Item. Per fare ciò, aprire il Tab Layout e inserire un nuovo controllo nella gerarchia dei controlli del form. Facciamo l'esempio di voler inserire il campo Difficoltà sotto il titolo del task:



Prememdo su Preview Form è possibile avere l'anteprima del form modificato:



Salvando il file WIT le modifiche sono già pubblicate sul server di TFS. E' possibile pero' lavorare in modalità "offline" cioè esportare un Work Item Type da TFS in un file con estensione WIT (menù Tools/Process Editor/Work Items Type/Export WIT), eseguire le modifiche e importare il file nuovamente in TFS (menù Tools/Process Editor/Work Items Type/Import WIT).

mercoledì 3 marzo 2010

Mantenere lo stato dei controlli in ASP.NET MVC

Una delle prime cose che si imparano quando si affronta per la prima volta il mondo di ASP.NET MVC provenendo da un'esperienza di WebForms, è che la grande "invenzione" che ha reso tanto popolare quest'ultima tecnologia non esiste più, ossia il ViewState.

Dopo un momento di smarrimento, si cerca di capire come farne a meno (e capirete che di vantaggi ce ne sono!)

Ovviamente i creatori di MVC non ci hanno lasciato con le mani vuote, ma hanno pensato a un modo articolato ma efficace per ottenere lo stesso risultato. In realtà quello che si può ottenere "gratis" dal framework è il mantenimento del valore effettivo di un input control (dunque non le altre proprietà come Visible, Color, ecc..)

Prendiamo ad esempio una textbox:

<%= Html.TextBox("SearchText","testo di default")%>

e il seguente Action method invocato dal submit presente nella pagina della textbox:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Search(string SearchText)
{
    return View();
}

Mandando in esecuzione il codice vedremo che alla prima apertura della pagina la textbox avrà il valore "testo di default", modificando la textbox e premendo il bottone di submit la textbox viene renderizzata con il valore modificato. La textbox ha mantenuto lo stato!

Cosa è successo??

Tutto ciò è dovuto al fatto che "per convenzione" il framework MVC valorizza i controlli presenti in una pagina prendendone i valori secondo una scala di priorità di seguito riportata:

1 MVC controlla se è presente un valore nella proprietà ModelState["SearchText"].Value.AttemptedValue.   ModelState è una collection in cui sono aggiunti TUTTI i valori che i model binder trasferiscono al controller. La collection diventa utile quando si vuole far apparire un messaggio di errore di validazione e non si vuole perdere al post della pagina quello che l'utente ha inserito.

2 MVC controlla se è presente un valore di default del controllo (nel nostro caso la stringa "testo di default")

3 MVC controlla se è presente un valore per l'elemento ViewData["SearchText"]. ViewData è la collection che il Controller passa alla View con tutti i dati sul modello.

4 MVC controlla se è presente un valore per l'elemento ViewData.Model.SearchText . ViewData.Model è l'oggetto che viene passato dal Controller alla View come modello

Tornando al nostro caso, al primo accesso della pagina scatta la regola 2. Il ModelState, infatti, è vuoto mentre la stringa di default è valorizzata.
Al post della pagina, il "miracolo" è possibile proprio per la presenza della proprietà ModelState["SearchText"].Value.AttemptedValue (regola 1). Notare che questa è stata valorizzata poichè la proprietà SearchText è un parametro di ingresso dell'action method e dunque è stata inserita nel ModelState dal model binder. Qualora non ci fosse tale parametro, il ModelState["SearchText"] non sarebbe valorizzato e noi al post della pagina troveremmo di nuovo la stringa "testo di default" (di nuovo regola 2).

E' bene dunque tenere sempre a mente queste priorità in modo da non incorrere in comportamenti non previsti.