Venerdì mattina mi ha venuta la voglia di modificare la skin del mio blog che state leggendo. Al contrario di Mighell, che se ho ben capito ha litigato più per il lato estetico, io mi sono sforzato di raggiungere un solo e semplice obiettivo, cioè integrare nella parte sinistra della pagina Web tutte le informazioni che mancavano. Ad esempio, sul mio vecchio blog UGIdotNET avevo l’elenco di tutte le categorie e l’elenco dei mesi/anni di attività del blog stesso. Queste informazioni fino a venerdì mancavano del tutto nello skin attuale.

Così, dopo una breve chiaccherata con Simone per avere qualche informazione utile, mi sono dato da fare e ho risolto tutto nel giro di pochi minuti.

La prima cosa da fare è aprire con un qualsiasi editor HTML il file /Skins/<template_name>/PageTemplate.ascx. Al posto di <template_name> bisogna ovviamente mettere il nome della skin che state utilizzando. Nel mio caso, la skin è lightz. Dopo averlo aperto, è sufficiente aggiungere lo UserControl sia all’interno del <div id=”menu”>, sia all’interno del blocco iniziale <%@ Register … />.

Nel mio caso, ho dovuto aggiungere lo UserControl contenuto all’interno del file SingleColumn.ascx, quindi:

<%@ Register TagPrefix="uc1" TagName="SingleColumn" Src="Controls/SingleColumn.ascx" %>

e più sotto…

<uc1:SingleColumn id="SingleColumn1" runat="server"></uc1:SingleColumn>

Ovviamente la posizione è a vostra discrezione e non c’è alcun vincolo. Adesso – finalmente – chi raggiunge il mio browser vede sul lato sinistro le varie categorie ed i mesi di attività del blog, che è partito l’Aprile scorso. Mi piace molto, perchè in questo modo è un po’ più “navigabile” e user-friendly, ma magari è solo la mia impressione.

Ultima nota sugli UserControl. Con le ultime release di Subtext è supportata anche la Tag Cloud: è possibile specificare quanti elementi visualizzare modificando la proprietà ItemCount. All’inizio il mio skin ne visualizzava solo 20, io l’ho aumentata a 50 ed adesso la mia Tag Cloud è un po’ più popolosa.

Se ho detto qualche bestialità (cosa probabile, trattandosi di ASP.Net e dintorni), perdonatemi, ma la mia competenza è quella che è, in questo campo. Fate così: rivolgetevi ad un maestro del settore, o comunque a qualcuno di vostra fiducia come faccio io. Cosa può esserci di meglio che uno dei creatori di Subtext? 🙂

Technorati Tags: blog programming Subtext skin

Send to Kindle

Senza scendere nei dettagli di WCF, è chiaro come client e server comunichino fra loro attraverso un’interfaccia. Supponiamo di aver definito un’interfaccia IFatturazione che espone i seguenti membri pubblici:

    [ServiceContract()]
    public interface IFatturazione
    {
        [OperationContract]
        int GetImportoFattura(string denominazione);

        [OperationContract]
        string GetXmlArticolo(string Codice);

        [OperationContract]
        string GetXmlCliente(string Codice);

        [OperationContract]
        string GetNuovoNumeroFattura();

        [OperationContract]
        bool SalvaFattura(string xmlFattura);
    }

ServiceContract ed OperationContract sono due attributi che fanno parte del mondo WCF per identificare quando una certa interfaccia funge da contratto per un servizio, e quali sono i metodi che devono essere esposti attraverso la comunicazione. Pensandoci bene oggi pomeriggio, sono arrivato ad un’altra possibile definizione dell’interfaccia, cioè questa:

        [ServiceContract()]
        public interface IFatturazione
        {
            [OperationContract]
            int GetImportoFattura(string denominazione);

            [OperationContract]
            Articolo GetArticolo(string Codice);

            [OperationContract]
            Cliente GetCliente(string Codice);

            [OperationContract]
            string GetNuovoNumeroFattura();

            [OperationContract]
            bool SalvaFattura(Fattura fattura);
        }

La grande differenza fra le due è che la prima espone tipi base del .NET Framework: i metodi ritornano tipi come int, string e bool. I parametri di input dei metodi sono tutti di tipo string. La seconda invece è un po’ più consistente e forte per il domain model sul quale sto sviluppando: i metodi ritornano oggetti come Articolo, Cliente oppure prendono in input istanze di Fatture. Ad una prima analisi, dal mio punto di vista la seconda interfaccia sembrava migliore, però mi ha obbligato ad effettuare alcune operazioni:

1. I tipi che devono essere trasmessi (Articolo, Cliente e Fattura) devono essere decorati con l’attributo DataContract. Cosa che non è sempre possibile, per esempio quando non disponiamo del sorgente dei tipi appena citati. Nel mio caso non è così, però, come ragionamento ci sta.
2. La prima interfaccia mi dà l’impressione di essere più interoperabile. D’altra parte, non fa altro che mandare avanti ed indietro stringhe in XML, o comunque di ritornarmi tioi semplici. La secondo no. Ditemi se sbaglio.

Alla fine ho scelto la prima implementazione di IFatturazione.

Sul server ho messo del codice che serializza oggetti e li restituisce come XML al client. Per esempio, se il client esegue il metodo GetXmlCliente passando un certo codice, viene creata un’istanza dell’oggetto, i valori delle proprietà vengono lette da database. Poi l’oggetto viene serializzato in uno StringWriter e restituito al client. Ecco il metodo che fa da helper a questa funzionalità:

static string getSerializedObject(Entity instance)
{
    XmlSerializer ser = new XmlSerializer(instance.GetType());
    StringWriter output = new StringWriter();

    ser.Serialize(output, instance);
    
    output.Flush();
    output.Close();

    return(output.ToString());
}

Sul client c’è del codice che fa l’esatto opposto, cioè da una stringa XML deserializzo per ottenere l’istanza dell’oggetto. Vero che così facendo ho aggiunto un po’ elaborazione aggiuntiva, ma ho preferito fare così. Se anche voi sviluppate con WCF, mi piacerebbe sapere cosa ne pensate, perchè sicuramente siete passati anche voi da una situazione di questo tipo. Come l’avete risolta? Perchè?

Technorati Tags: .NET Framework programming WCF interface

Send to Kindle

Vi ho già parlato altre volte (forse troppe) del mio piccolo RapportinoMaker. Eppure, vi dirò, nella sua semplicità mi permette di esplorare, disegnare e sfruttare componenti che altrimenti non avrei mai visto. Vi faccio un piccolo riassunto perchè ci tengo.

RapportinoMaker è un software che gira dalla console di Windows. Accetta al massimo due argomenti: il mese e l’anno di cui si vuole generare il rapportino. Quindi, per esempio, possiamo lanciarlo con una riga simile a questa:

Dopo aver premuto Invio, RapportinoMaker apre il database di Outlook, preleva tutti gli appuntamenti del mese e dell’anno passati come input e conta quanti giorni ho lavorato. Il conteggio si basa sull’oggetto dell’appuntamento: se è una determinata stringa, allora l’appuntamento viene preso in considerazione, altrimenti…nisba.

Determinato il numero di giorni effettivamente lavorati (per esempio 20), posso generare due cose: il rapportino su un foglio Excel e la fattura. Parliamo di quest’ultima. Tutto il database della mia fatturazione è online, adeguatamente protetto, su un server SQL 2005 disponibile via Web. Tecnicamente parlando, se non ci sono firewall o regole particolari, RapportinoMaker potrebbe aprire una connessione verso il server SQL ed aggiungere record nelle tabelle per generare la fattura. Questo può ovviamente essere ottenuto sia con istanze di SqlConnection/SqlCommand, sia con architettura basata su NHibernate.

Capita però di dover utilizzare RapportinoMaker in ambienti dove il mio SQL Server è irraggiungibile. Vuoi per qualche firewall, vuoi per qualche restrizione dei responsabili di rete, RapportinoMaker non riesce a completare il lavoro per cui è stato progettato mesi e mesi fa. Se lo uso a casa, non ci sono problemi, ma quando lo uso sul lavoro, qualcosa non va.

Ecco il motivo per cui ho deciso di studiare WCF. Esponendo un servizio WCF sulla porta 80, RapportinoMaker non comunica più direttamente verso il database, ma sfrutta un servizio che lo fa per lui. RapportinoMaker comunica con il servizio tramite un’interfaccia IFatturazione che espone metodi per caricare e salvare articoli, clienti e fatture. Adesso si è fatto davvero tardi, ma mi riprometto in futuro di parlarvene, se non altro per darvi qualche infarinatura su come creare un servizio WCF, dal momento che potrebbe davvero essere utile a tutti voi. Come al solito, stay tuned!

Technorati Tags: .NET Framework WCF database services

Send to Kindle