CMS - Customizzazioni. Una necessità?

Buongiorno a tutti.
Questo post vuole essere la continuazione del precedente : Conviene realizzare un proprio CMS?. Ho chiuso il post dicendo che la necessità di personalizzare il sito/applicazione dei propri clienti, diventa la discriminante tra lo scegliere un CMS di terze parti, piuttosto che intraprendere lo sviluppo di uno proprio.
Ma cosa si intende con personalizzazione? Posto di partire da una base esistente, sia essa proprietaria o di terze parti, quasi sempre si presentano le seguenti necessità di customizzazione:

• Adeguare l'aspetto grafico al layout desiderato dal cliente  e/o a quello con cui il cliente si è già fatto conoscere, attraverso altri canali/servizi, al suo pubblico.
• Integrare il sito/applicazione, con l'infrastruttura informatica e non attualmente operativa presso il cliente
• Nel caso in cui il sito/applicazione, vada a sostituirsi ad un sito/applicazione precedente, replica di tutte le funzionalità preesistenti ed ancora utili.
• Implementazione di nuove funzionalità, disegnate su misura per il cliente, con lo scopo di favorirlo rispetto alla concorrenza o di velocizzare workflow interni ormai obsoleti.

Per tutti questi motivi posso affermare che 

PERSONALIZZARE E' UNA NECESSITA'

Supponendo che nessuno strumento, sia realizzato internamente, sia preparato da terzi,
possa permettere a clienti senza basi di programmazione di piegare il prodotto alle proprie esigenze di personalizzazione, completo la precedente affermazione nel seguente modo.


PERSONALIZZARE E' UNA NECESSITA', SIA CHE SI STIA LAVORANDO SU UN PRODOTTO PROPIETARIO, SIA CHE SI STIA USANDO UN PRODOTTO GIA' PRONTO, DI TERZE PARTI.


Le cose che un'azienda informatica deve capire e che deve quindi trasmettere ai propri clienti sono le seguenti:

1. Personalizzare il proprio sito/applicazione è una necessità. principalmente per
   POTERSI DISTINGUERE DALLA CONCORRENZA
2. Personalizzare il proprio sito/applicazione e quindi prevederne e pagarne lo sviluppo,
   E' NECESSARIO SIA SU PRODOTTO RIVENDUTO DA TERZI CHE DA PRODOTTI PROPRIETARI

Nel prossimo post cercherò di esporre le differenze di approccio, i pro e i contro, di personalizzazioni fatte su un prodotto proprietario, rispetto a quelle fatte su un prodotto di terze parti.

Grazie per l'attenzione e alla prossima.

Conviene realizzare un proprio CMS?

Buongiorno a tutti.
Oggi voglio iniziare un argomento che penso mi perseguita dall'inizio della mia carriera di analista/programmatore Web. Conviene ad una "Software House", specializzata nella realizzazione di siti web, oggi, realizzare un proprio CMS (Content Managment System)?
Ad un'analisi superficiale la risposta appare scontata: NO. Valutando brevemente che:

• sono attualmente disponibili diversi CMS gratuiti e non, molto diffusi, quali ad esempio Wordpress, Joomla, Typo3, Kentico, Alfresco, ecc..,
• i CMS di cui sopra sono molto diffusi e supportati da una community che sforna giornalmente nuovi plugin, adatti a tutte le esigenze
• i CMS di cui sopra sono mantenuti nel tempo, garantendo sempre compatibilità con i nuovi browser e funzionalità sempre al passo coi tempi.
• i CMS di cui sopra vantano un supporto della ditta fornitrice e/o della community per la soluzione di bug e  consigli per nuove implementazioni.

sembra che non abbia senso investire del tempo nella creazione di un proprio CMS, dovendo valutare che occorrerà manutenerlo e supportarlo nel tempo.

Dalla mia esperienza risulta invece che tutti i ragionamenti di cui sopra, nella vita lavorativa di tutti i giorni, valgano assai poco. Sono ormai 11 anni che lavoro quale analista/sviluppatore e in questo arco di tempo ho avuto occasione di analizzare e lavorare sia con CMS proprietari, sia con alcuni dei CMS più conosciuti, citati all'inizio dell'articolo.

Credo che, per un'azienda che sviluppa siti internet sia fondamentale avere una base solida. Un CMS proprietario o un di terze parti. Pensare di sviluppare ogni progetto web come una applicazione a se stante diventa sul lungo periodo poco conveniente.

• su progetti progetti piccoli impone di iniziare lo sviluppo da zero ad ogni nuovo progetto
• su progetti grandi rende difficile la manutenzione, che richiede per ogni progetto un trattamento separato.

Credo che nella decisione di un'azienda, nel prediligere lo sviluppo interno all'utilizzo di un CMS di terze parti  stia tutta nella sua attenzione verso il cliente. Nel lavoro dei servizi il cliente è in RE. Nel nostro lavoro il cliente pretende, ha sempre ragione e soprattutto ci paga.

Il cliente ha una necessità fondamentale:

• POTERSI DISTINGUERE DALLA CONCORRENZA

Questa necessità porta l'azienda informatica che si occupa delle sue necessità, a dover fare i conti con quella cosa che viene denominata

• PERSONALIZZAZIONE / CUSTOMIZZAZIONE

Nel momento in qui entra in gioco la grande "C" (customizzazione), tutte le regole del gioco cambiano,

Come cercherò di esporre nel prossimo articolo.

Mvc - Rendere una checkbox obbligatoria

Per far si che in una pagina realizzata con il framework MCV, una checkbox sia obbligatoria, occorre un pò di lavoro. Nemmeno con la versione 4.5 di.NET sono stati capaci di rilasciare qualcosa che lo faccia in maniera semplice.

Prima di cominciare bisogna analizzare alcuni concetti di base:

1. Una checkbox permette solo 2 valori: acceso o spento.
2. Se si utilizza MVC, è bene che si sfrutti la logica dei modelli e delle annotazioni per segnare che una proprietà è obbligatoria.
3. La validazione deve avvenire 2 volte, ovvero una volta lato "client", attraverso del javascript ed una seconda volta lato server, casomai il javascript avesse fatto cilecca o sia stato manomesso.

Per rappresentare la nostra proprietà useremo un valore booleano. Non esistendo una annotazione di base che permetta di definire che una proprietà booleana debba per forza essere essere uguale a "true", dobbiamo costruirla noi:

    public class BooleanRequiredAttribute 

                    : RequiredAttribute, IClientValidatable
    {
        /// <summary>
        /// Initializes a new instance of the 

        /// <see cref="BooleanRequiredAttribute" /> class.
        /// </summary>
        public BooleanRequiredAttribute() { }


        /// <summary>
        /// Checks that the value of the required data field is equal to true.
        /// </summary>
        /// <param name="value">The data field value to validate.</param>
        /// <returns>
        /// true if validation is successful; otherwise, false.
        /// </returns>
        public override bool IsValid(object value)
        {
            return value != null && (bool)value == true;
        }


        /// <summary>
        /// When implemented in a class, returns client validation rules                 /// for that class.

        /// </summary>
        /// <param name="metadata">The model metadata.</param>
        /// <param name="context">The controller context.</param>
        /// <returns>
        /// The client validation rules for this validator.
        /// </returns>
        public IEnumerable<ModelClientValidationRule> GetClientValidationRules(
            ModelMetadata metadata, ControllerContext context)
        {
            return new ModelClientValidationRule[] {
                new ModelClientValidationRule() { ValidationType = "mandatory", 

                   ErrorMessage =  ErrorMessage}};
        }
    }

La nostra classe deve

1. implementare la classe "IClientValidatable" in quanto dovremmo scrivere anche la parte di validazione lato "client"
2. ereditare "RequiredAttribute" di modo da dover semplicemente fare un "override" del metodo "IsValid", dove restituiremo "true", solo se il valore della proprietà testata sarà "true"
3. inventare una chiave per la validazione lato "client". In questo caso abbiamo scelto "mandatory", ma potete scegliere il nome che preferite.

A questo punto decorate la proprietà del modello con il nuovo attributo

        [BooleanRequiredAttribute]
        [DataType(DataType.Text)]
        public bool Privacy { get; set; }

e aggiungete il seguente script alla pagina:

(function ($) {
            $.validator.unobtrusive.adapters.add("mandatory", 
              function (options)         {
                options.rules["required"] = true;
 
                if (options.message) {
                    options.messages["required"] = options.message;
                }
            });
        } (jQuery));

e il gioco è fatto. Lato client si occuperà la libreria "jquery.validate" della validazione, mentre lato server se ne occuperà il framework MVC, richiamando nel metodo del controller la funzione "ModelState.IsValid"

es

  [HttpPost]
  public Save(Models.MyModel model)
  {
     if (ModelState.IsValid)
     {
        /* validazione riuscita */
     }
  }

Spero che questo articolo vi sia stato di aiuto.

Trasformare una stringa in una data in javascript

Trasformare una stringa in una data, in javascript, specialmente se si lavora ad un programma multilingua, dove la lingua del thread dipende dalla lingua dell'utente, può essere un vero delirio. Inoltre, l'oggetto javascript "Date" ha dei metodi di inizializzazione che accetterebbero una stringa, ma che si comportano in maniera diversa, tra le varie versioni di internet explorer. Nemmeno passando la data nel formato internazionale "yyyy-MM-dd", se il thread non è inglese, si è sicuri di trasformare correttamente il dato.

La seguente funzione javascript, sebbene non elegantissima, vi verrà in aiuto e funziona con tutte le versioni di Explorer, firefox e chrome.

function string2Date(theDate, format) {
    if (theDate == null) {
        return new Date();
    }

    var strings = theDate.replace('.', '/').replace('.', '/').split('/');
    var mydate = new Date();

    if (format.substring(0, 1) == 'M') {
        mydate.setFullYear(strings[2], strings[0] - 1, strings[1]);

    }
    else {
        mydate.setFullYear(strings[2], strings[1] - 1, strings[0]);
    }

    return mydate;
}

La funzione accetta in ingresso la stringa contenente la data e il formato in cui essa è espressa. Il formato, è quasi sempre noto, dipende dalla lingua del thread.

es.

   1:  italiano -> 'dd/MM/yyyy'

   2:  tedesco  -> 'dd.MM.yyyy'

   3:  inglese  -> 'MM/dd/yyyy'

A questo punto, ad esempio con un thread italiano, potete usare la funzione un questo modo :

var stringDate = '28/04/2013';

var myDate = string2Date(stringDate , 'dd/MM/yyyy');

Serializzazione e deserializzazione in c#

Nell'interscambio di dati è usuale utilizzare formati xml. Se usiamo c# come linguaggio di programmazione, ci sono dei metodi del framework che ci aiutano parecchio. Inoltre dalla versione 3.5 del framework potete usare gli "Exstension Method", ovvero potete dotare qualsiasi classe di metodi aggiuntivi, in relazione al tipo.
Combinando le due cose potete scrivere dei metodi per la serializzazione e deserializzazione di classi e renderli generici. Ad esempio:

Con i seguenti "Extension Method"

        /// <summary>
        /// Serializes to XML.
        /// </summary>
        /// <param name="value">The object to serialize.</param>
        /// <returns>
        /// a XElement rappresenting the class serialization
        /// </returns>
        public static XElement SerializeToXML(this object value)
        {
            XmlSerializer x = new XmlSerializer(value.GetType());
            XDocument doc = new XDocument();
            using (XmlWriter xw = doc.CreateWriter())
            {
                x.Serialize(xw, value);
                xw.Close();
            }
            return doc.Root;
        }


        /// <summary>
        /// Deserializes the specified string to an object of type T.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="value">The value containing an xml.</param>
        /// <returns>
        /// an object of type T
        /// </returns>
        public static T Deserialize<T>(this string value)
        {
            XElement xElement = XElement.Parse(value);

            return xElement.Deserialize<T>();

        }

        /// <summary>
        /// Deserializes the specified string to an object of type T.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="value">The value containing an xml.</param>
        /// <returns>
        /// an object of type T
        /// </returns>
        public static T Deserialize<T>(this XElement value)
        {
            XmlSerializer x = new XmlSerializer(typeof(T));
            T result;
            using (XmlReader xr = value.CreateReader())
            {
                result = (T)x.Deserialize(xr);
                xr.Close();
            }
            return result;
        }

In questo modo, per serializzare una classe dovrete semplicemente scrivere

MyClass a = new MyClass();

XElement xml = a.SerializeToXML();
MyClass b = xml.Deserialize<MyClass>(xml)

Come esporre in xml i dati delle proprie applicazioni

Sembra una cosa semplice. E difatti lo è. Oggigiorno, indipendentemente dal linguaggio di programmazione utilizzato, esporre i propri dati in formato xml è semplicissimo. Il linguaggio xml è poi molto adatto all'interscambio di dati, in quanto semplice e autoesplicante.

Allora perché ci sono sempre un sacco di incomprensioni e problemi quando 2 aziende devono scambiarsi informazioni? Perché i programmatori delle suddette aziende passano settimane e telefonarsi per cercare di far funzione quelle benedette interfacce di scambio dati?

Perché non vengono seguite poche semplici regole. Il linguaggio XML non è magia. Non si spiega da solo. Come una qualsiasi lingua parlata, se le parole vengono messe insieme senza senso, l'ascoltatore non può recepire il messaggio. Inoltre non prendiamoci in giro: difficilmente il programmatore che scrive l'algoritmo di export XML ha poi anche il tempo di scrivere una documentazione per chi utilizzerà il file generato. Cerchiamo quindi di generare file che non necessitino di spiegazioni.

Semplici regole quando si scrive un file XML:

1. Scrivete tutto in una lingua (preferibilmente in inglese).
   Sembra una cosa da poco, ma chi leggerà il vostro file lo leggerà in maniera più veloce, senza dover interpretare ogni parola
2. Nominate nodi ed attributi in maniera estesa. Non lasciate alla fantasia di chi utilizzata il vostro XML il dover capire se "SecCode" sia "Codice Secondario", "Codice Settore", o altro.
3. Le date e le cifre vanno scritte in formato inglese. In questo modo i parser dei vari linguaggi di programmazione possono interpretarle correttamente
4. Sfruttate gli attributi per tutte le informazioni che non hanno altre informazioni collegate. Questo vi permette di risparmiare dei caratteri e soprattutto permette a chi legge l'xml di capire quali informazioni possono averne altre di collegate.
5. Scegliete se scrivere tutto in "Camel Case" o in "Pascal Case"
   
   
   es

<customers>
  <customer key="100" name="Marco" surname="Rossi">
    <orders>
      <order key="200" date="2010-01-01" total="10.00" >
        <product title="lavastoviglie XYZ"></product>
      </order>
    </orders>
  </customer>
  <customer>
    ...
  </customer>
</customers>

Ovviamente ci sono altre best practice che in questo pos mi sono dimenticato.

Grazie per aver letto questo articolo.

Sembrerebbe che tutta l'importanza che viene attribuita ai blog sia veritiera. Oggi ho aggiunto i link ad alcuni dei siti che gestisco e già ho potuto rilevare delle visite derivanti da questo blog. Sono molto soddisfatto. Chissà come si evolverà questa avventura.

Sono molto curioso...

Oggi ho provato ad inserire alcuni dei siti a cui ho collaborato.
Li dovreste trovare alla destra del blog. Sono curioso di sapere se questo (ammesso che io continui a tenere questo blog) influenzerà o meno le visite dei siti stessi.
Ai posteri l'ardua sentenza...

Non ho mai avuto un blog. Prendo questo blog come occasione di studio.
Vorrei capire se un nuovo blog viene seguito, da chi e soprattutto perché.

Sono un programmatore da ormai 11 anni, prevalentemente lavoro in ambiente web, su tecnologia Microsoft. Mi occupo di analizzare i problemi e di risolverli e per questo ho bisogno di farmi esperienza anche nell'ambito dei blog.

Saluto quindi tutti quelli che passeranno di qui e invito a lasciare un commento per poter rispondere alle mie domande:

Perché la gente scrive blog? cosa ci scrive?

Hello World!