Beren.it

All that you can leave behind

Solo un upgrade...

Un upgrade, doveva trattarsi di un semplice upgrade, è durato 4 mesi... Il mio adorato blog n

Un upgrade, doveva trattarsi di un semplice upgrade, è durato 4 mesi... Il mio adorato blog nella veste 1.1.15 di Blognet engine dopo l'intervento a cuore aperto è rimasto però in coma per ben 4 mesi. Niente di irreparabile direte voi, non fosse che per uno developer inside come me una cosa di questo ti lascia la stessa sensazione di aver scordato il gas aperto o di aver lasciato l'auto aperta con la chiave inserita in stazione.

Devo dire che perquanto le istruzioni sul sito di riferimento fossero dettagliate è risultato assai difficile riuscire a migrare tutto, dati compresi, cercando di districarsi tra una selva di sql scripts, cartelle, file, api tutte nuove. La cosa peggiore di tutte però è stato l'esito: una pagina completamente bianca. Non un messaggio di errore, non un log, niente nella console... un vero dramma insomma. Un cadavere senza indizi. Ho dovuto pertanto cominciare una certosina analisi, ricreandomi tutto in locale. Una volta riprodotta la migrazione in locale si è trattato poi di approciare alla migrazione su Aruba.

Anzitutto lato DB ho rivisto uno a uno tutti gli oggetti eliminando tutta la roba legacy, poi lato file system, adattando il web.config ai dettami di Aruba e ripulendo le directory dai vecchi files e controlli per arrivare ad una situazione pulita. Ancora, modificare ed allineare l'application pool ed infine richiedere la modalità Full Trust. 

Insomma, è stata una vera faticaccia, quasi un lavoro, ma volete mettere la soddisfazione? Che ne dite? Bello eh? 

Nuova sintassi ciclo for JQuery 3.0

jQuery 3.0 è la nuova verione di jQuery è una beta ed è già disponibile.

jQuery 3.0 è la nuova verione di jQuery è una beta ed è già disponibile. Tra le più importanti modifiche di jQuery 3 c'è la nuova sitassi per iterare gli elementi del DOM di una jQuery collection attraverso il ciclo for…of. Questa modifica è parte delle specifiche ECMA 6.

Il vecchio modo di iterare gli elementi in jQuery era:

var $dvElements = $(“div”);
for (var x=0; x< $dvElements.length; x++){
    $dvElements[x].addClass(“dummy”);
}

Riportiamo qui invece il nuovo con jQuery 3.0: 

var $dvElements = $(“div”);
var i = 0;
for(var elm of $dvElements) {
      elm.addClass(“dummy”);
}
 

Con questa nuova sintassi, si utilizza l'elemento DOM non la collection jQuery. Non sarà quindi più necessario utilizzare un indice ma semplicemente nell'iterazione avremo già l'elemento DOM.

A questo indirizzo trovate il source.

Trovare una Lista in SharePoint per GUID con PowerShell

Una delle situazioni più classiche lavorando con con SharePoint è quella di volere recuperare una Lista e, più in generale un oggetto, conoscendone il GUID. L'esempio classico è quando si ottiene con un Access Denied il GUID dell'oggetto "proibito" con il problem di doverlo identificare. In rete si trova un ottimo post che risolve il problema mostrando la lista di tutte le library di un web con il corrispettivo GUID.

 

2007 version:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = New-Object Microsoft.SharePoint.SPSite("http://yourserver/sites/yoursite")
$web = $site.OpenWeb("yoursubsite")
write-host "Site: " + $site.id
write-host "Web: " + $web.id
$web.lists | Format-Table title,id -AutoSize
$web.Dispose()
$site.Dispose()

 

2010 version:

$site = Get-SPSite http://yourserver/sites/yoursite
$web = $site.OpenWeb("yoursubsite")
write-host "Site: " + $site.id
write-host "Web: " + $web.id
$web.lists | Format-Table title,id -AutoSize
$web.Dispose()
$site.Dispose()

 

L'unica modifica che dovete fare è sostituire l'url della vostra Site Collection. Qui sotto trovate l'esempio di output dello script.

Dynamic Data Entities - Customizzare le Foreign-Key

Personalizzare la visualizzazione delle Foreign Key nei Dynamic Data Entity

Oggi vediamo come customizzare il controllo delle Foreign-Key visualizzato per default nei Dynamic Data Entities. Questo controllo visualizza i dati di una tabella terza rispetto quella che si sta editando e che viene linkata tramite una chiave esterna (Foreign Key appunto). Dato che di default viene semplemente riempito con un field dell'entità scelto in base alla PK della stessa, non sempre può essere immediato da utilizzare. Quello che faremo è visualizzare un composizione di più campi invece che uno singolo ed ordinare gli elemento rispetto ad un field specifico.

1. Visualizzazione di un campo composto: la dropdown usata nel controllo della FK (Foreign Key) può essere customizzata sovrascrivendo la funzione ToString() con un metodo custom come ade esempio illustrato qui sotto:

[C#]

    [MetadataType(typeof(TB_SEASONMetadata))]
    public partial class TB_SEASON
    {         
         public override string ToString()
         {
             return NAME + DESCRIPTION;
         }
    }

 

2. Ordinare i valori nella DropDown: per ordinare rispetto ad un campo gli oggetti all'interno della dropdown di FK occorre usare il decoratore DisplayColumn specificando il nome del field-colonna su cui effetturare l'ordinamento in questa maniera:

[C#]

    [MetadataType(typeof(TB_SEASONMetadata))]
    [DisplayColumn("NAME","NAME", false)]
    public partial class TB_SEASON
    {         
         public override string ToString()
         {
             return NAME + DESCRIPTION;
         }
    }

 

In effetti resta la perplessità sul fatto che il primo parametro di tale decoratore sia un field che a tutti gli effetti poi non è utilizzato: in fatti nell'esempio il field NAME è stato specificato essere la DisplayColumn quando in realtà verrà comunque visualizzato l'override del ToString()... In ogni caso il secondo parametro che è la sortcolumn funziona correttamente e noi otteniamo il risultato sperato.

Dynamic Data Entry - Un datepicker per le date

Personalizzare il controllo di editing delle date con i Dynamic Data Entity

Sappiamo tutti che uno dei formati di dato più pericolosi in assoluto è la data. Fondamentalmente perchè ognuno la scrive un pò come gli pare e piace con il problema che poi quando si va a scriverla sul DB ci possono essere spiacevoli sorprese. Nell'ambito dei Dynamic Data Entry di cui da un pò di post mi occupo per la notevole versatilità che hanno l'idea che più di tutte si è fatta largo nel mio ideale di applicazione è quella di consentirne l'inserimento e la modifica attraverso un datepicker. Dato che molti però, come il sottoscritto ;), non masticano molto JQuery magari ripiegare su una soluzione più semplice può essere di utilità ed in questo ci viene in aiuto l'Ajax Control Toolkit che potete scaricare gratuitamente qui.
Questo fantastico set di controlli oob Ajax contiene un buon Calenda Extender che fa al caso nostro. Scaricata infatti la dll ed inclusa come referenza del progetto potremo infatti usufruire di tale funzionalità.

Per implementare tale modifica dovremo dunque aprire la lista dei controlli ed, una volta individuato il controllo generico di Edit delle date aprirlo nell'editor.

Nella toolbox a sinistra selezionate il Calendar Extender e trascinatelo nel controllo a destra. Se nella toolbox a sinistra non doveste trovare il controllo significa che dovete semplicemente aggiungere la dll cliccando con in destro sulla toolbox quindi premendo "Choose items" ed infine nella finestra che si aprirà browsandola.

Una volta che avete trascinato l'extender all'interno del controllo, il gioco è praticamente fatto. Basterà infatti modificare le sue proprietà per ottenere l'effetto voluto:

  • TargetControlID: è l'ID del controllo che conterrà poi effettivamente la data che nel nostro caso è la textbox preesistente. In pratica con questa proprietà l'extender sa su quale controllo deve visualizzare il datepicker. Questa proprietà deve essere valorizzata altrimenti il datepicker non funzionerà.
  • Format: questa indica semplicemente il formato in cui verrà tradotta la data scelta nel date picker ed inserita nel controllo. Nel nostro caso nel classico formato che si usa in Italia.

Una volta concluso questo il gioco è fatto senza JQuery e con un effort ridicolo.

 

Dynamic Data Entity - Gridview Pager

Customizzare il controllo di paginazione del GridView nei Dynamic Data Entity

Una delle cose più scomode che mi è capitato di utilizzare con i Dynamic Data è il paginatore out of the box. O meglio, diciamo che la configurazione di default mi risultava davvero parecchio scomoda: avere il numero di righe di default visualizzate a 10. Troppo poche, specie se si ha uno schermo ad alta definizione e degli occhi buoni, si rischia di avere perennemente mezza pagina vuota.

Come fare allora? Mi metto a spulciare un pò il codice e mi accorgo che il tutto è assai più semplice di quanto si possa pensare. Infatti la modifica/personalizzazione interessa solamente 2 files:

  • GridViewPager.ascx è il controllo ascx che contiene la dropdown con i valori selezionabili di righe
  • List.aspx è il template di pagina di default che utilizza la gridview che viene visualizzata nelle pagine

La prima modifica in GridViewPager.ascx è opzionale nel senso che si possono cambiare i valori nella dropdown, aggiungerne di nuovi o toglierne a piacere. Il consiglio è quello di lasciare sempre il valore 10 che corrisponde al default della griglia come vedremo tra un pò. Ma in generale anche qui la libertà è massima.

Nel mio caso rimuoverò i valori 5 e 15 ed aggiungerò il 50, ma voi potete ovviamente fare come vi aggrada.
Fatto questo procediamo però con la modifica più importante cioè: dove cambiare il valore di default da quello scomodo 10 al più comodo 20? Semplicissimo: aprite il template di pagina List.aspx individuate il tag del GridView e tra gli attributi metteteci un bel PageSize=20. In questo modo:

Fatto questo con un seplice reload della pagina avrete personalizzato con facilità il numero di righe visualizzate nel paginatore della griglia. Ecco il risultato:

ASP.NET Ajax client-side framework failed to load

Errore ASP.NET Ajax client-side framework failed to load

Qualche giorno fa mi ero trovato a dover riconfigurare su una macchina nuova un'applicazione ASP.NET 4.0 che avevo inizialmente sviluppato su di un'altra. In pratica sulla vecchia macchina tutto funzionava a dovere, invece sulla nuova mi ritrovavo ad avere sempre in caricamento l'errore "ASP.NET Ajax client-side framework failed to load". In effetti tutto ciò che era Ajax nell'applicazione non funzionava più. Ho fatto così una serie di ricerche sul web ed ho trovato gli errori più assortiti e fantasiosi: da un problema al web.config, ad inserire codice custom nel routing dell'applicazione (è un app MVC) e infine modificare mille settaggi diversi in IIS. Tutto senza alcun esito.

Finalmente questa mattina mi imbatto in questo post che mi ha risolto tutti i problemi. In effetti come suggerisce il tipo, ho guardato sotto il site di IIS in cui gira l'applicazione e nella sezione Handler Mapping ho verificato che c'erano pochissime voci e nessuna su ASP.NET 4.0, di conseguenza ho fatto come consigliava lui cioè ho fatto un rerun del comando aspnet_regiis nella directory del Framework 4.0 (perchè a me lo dava con le applicazioni 4.0)

Una volta eseguita questa operazione magicamente negli Handler Mapping mi sono ritrovato tutte le voci mancanti (specie quelle su ASP.NET 4.0) e soprattutto l'errore ed i problemi ad esso correlati erano svaniti.

CMS su SP2010 (parte 3) - Creazione Web Application

In questo post prenderemo confidenza con l'ambiente di Sharepoint 2010 e ad alcuni strumenti assai utili quando si deve lavorare in questo contesto. Non perderndo di mezzo quello che è il nostro obbiettivo, cioè un semplice CMS, cominciamo con l'aprire la Central Administration di SP2010. Per chi fosse un totale neofita di SP, la Central Administration è una Web Application a tutti gli effetti che consente di amministrare praticamente tutte le funzionalità e i settaggi di SP: una sorta di pannello di controllo di Windows, trasferito nel contesto di Sharepoint.

Per accedere ad essa è sufficiente premere start e ricercare sotto la Cartella dei programmi Sharepoint 2010 Products il link a Sharepoint 2010 Central Admin dopo pochi secondi una finestra del browser si aprirà e dopo aver inserito le credenziali di un utente amministratore (tipicamente quello della macchina) mostrerà proprio la web application di destinazione. Attenzione: sebbene Sharepoint 2010 quanto a browser compatibility è molto migliorato rispetto al predecessore, consiglio per di utilizzare IE 32bit (anche se la macchina che utilizzate è 64bit) per ragioni di compatibilità con alcuni controlli ActiveX che in alcuni casi vi porterebbero a perdere del tempo in fase di configurazione se utilizzati su altri browser.

Come già precisato la Central Administration è un pò il pannello di controllo di Sharepoint. Quindi l'interrogativo che resta ancora aperto è: dove e come creare la Web Application custom su cui far girare il CMS? Il nostro obbiettivo è infatti creare una Sharepoint Web Application, vale a dire un'applicazione Web che "viva" sotto il contesto di Sharepoint, cioè sia configurabile tramite la Central Admin e fruisca di tutte le funzionalità out-of-the-box di SP.
Per farlo si potrebbe semplicemente, acceddere al menu Application Management della Central Admin, ma noi invece utilizzeremo invece un tool molto potente che consente per altro un'astrazione e una robustezza considerevole soprattutto per quella che è considerata la fase di deploy. Il tool di cui sto parlando è PowerShell. L'unica accortezza che si chiede di prestare per utilizzarlo nel contesto di SP è di non aprire il classico link a PS che ad esempio si può trovare nella barra del desktop, ma quello più specifico al di sotto del menu degli Sharepoint Products. In effetti, questo PS si differisce da quell'altro per l'accesso amministrativo alle risorse di SP, che altrimenti potrebbero darvi numerosi problemi Access Denied e anche quello di fornire già tutte le funzionalità di SP senza doverle esplicitamente caricarle sostituendo di fatto l'obosleto STSADM.

Nella schermata che si aprirà, una shell a tutti gli effetti, andiamo dunque ad inserire una serie di parametri che ci torneranno utili nella creazione della web application. Partiamo innanzitutto dal comando che effettua l'operazione: New-SPWebApplication. Qui sotto sono invece riportati i parametri fondamentali che useremo a breve:

  • Name è il nome della web application
  • ApplicationPool è il nome dell'application pool che verrà creato in IIS e su cui girerà l'applicazione
  • ApplicationPoolAccount è il "managed account" con il quale girerà l'app pool
  • URL è l'url pubblico dell'applicazione
  • Port è la porta su cui girerà l'app
  • Database Name è il catalog di SQL Server che verrà creato per gestire l'applicazione da Sharepoint
  • Database Server è il nome dell'istanza di SQL Server su cui verrà generato il Catalog di cui sopra.

In realtà i parametri da utilizzare possono essere molti di più, ad esempio in questo caso utilizzero l'authentication di Windows, che è quella di default ma se volessimo utilizzare quella Claim Base dovremmo modificare alcune cose. In questa pagina di MSDN potete trovare tutto quello che vi serve anche sotto gli altri scenari possibili.
A questo punto lanciamo il batch dopo averlo customizzato :

$name = "Beren CMS"
$AppPool = "BerenCMSAppPool"
$url = "www.berencms.com"
$port = 9999
$AppPoolAccount = "XXX\Administrator"
$sp_webapp_databasename = "WSS_BerenCMS"
$sp_webapp_databaseserver = "XXX\Sharepoint"
New-SPWebApplication -Name $name -ApplicationPool $AppPool -port $port -url $url -ApplicationPoolAccount (Get-SPManagedAccount $AppPoolAccount) -DatabaseName $sp_webapp_databasename -DatabaseServer $sp_webapp_databaseserver

Purtroppo però, a meno che non abbiate già configurato un "managed Account" l'esito del batch sarà negativo:

In effetti l'errore: "No matching accounts were found" sembra indicare un problema con l'utente specificato per l'account dell'Application Pool. Dopo una breve googolata trovo che in effetti l'utente usato nell'application pool deve essere un "Managed Account". . Per creare un managed account occorre aprire la Central Admin, cliccare sulla sezione di Security e quindi Service Account.

Scorrendo la pagina clicchiamo sul link "Register new managed account" e quindi nella pagina che si aprirà introduciamo l'account che sopra abbiamo designato ad essere usato nell'Application Pool, quindi premiamo OK e quando torniamo alla pagina deglia account nella tendina troveremo anche l'account appena creato. Per maggior sicurezza lanciamo batch per verifica la bontà dell'operazione effettuata.

Ci siamo! Ora l'utente è risolto correttamente dal sistema e quindi possiamo rilanciare il primo batch di creazione della Web Application:

Nell'immagine qui sopra si può notare come al termine della creazione unbreve riepilogo mostrerà i dati della Web Application appena creata. Bene, ed ora? Abbiamo creato la Web Application ma se proviamo a raggiungerla attraverso l'url ci beccheremo un bel errore inquanto la webapplication in se per se è solo un involucro vuoto all'interno del quale va generata la SiteCollection ed in particolare il web Site che sta come root e dal quale discenderanno poi tutti i web site che possono servire. Nel prossimo post ci occuperemo della creazione della sitecollection.

CMS su SP2010 (parte 2) - Visual Design

Il Visual Design dell&#39;applicazione

Dopo aver definito nel post precedente la struttura architetturale del sistema prima di gettarci nell'implementazione dell'applicazione occorre definire brevemente come dovrà essere visivamente la nostra applicazione come agirà per l'utente finale il CMS. Per farlo anzitutto disegnamo un layout di massima in cui sia presente una struttura fissa non editabile dal CMS (nel caso specifico si identificherà nella MasterPage) e quindi una parte invece editabile di contenuto, la cui gestione sarà del tutto demandata la CMS.

Per semplicità al momento l'applicazione sarà composta da una sola pagina (quella della figura sopra) la cui sola parte centrale sarà possibile editare.

Nella figura a sinistra la parte in evidenza è proprio la MasterPage, cioè quella parte di una pagina comune a tutte le pagine del sito e per il momento non editable dal CMS. Nella parte destra dell'immagine troviamo invece il contenuto editabile della pagina che come vedremo in seguito potrà essere definito in modalità differenti da pagina a pagina e nel nostro caso l'unica parte realmente editabile da CMS.

Ma come si comporterà il CMS? Come illustrato nell'immagine, sostanzialmente il CMS si occuperà di renderizzare delle textbox al posto dei testi editabili che saranno presenti nel solo box centrale dove individuiamo il testo del titolo del contenuto. Ovviamente il suo compito non si limiterà solo a quello, ma si farà carico altresì di gestire i pulsanti per l'editing, il salvataggio, l'approvazione, etc... Nel prossimo post ci occuperemo proprio di creare il layout definito ora in Visual Studio.

CMS su SP2010 (parte 1) - Il Design

Implementare un CMS con Sharepoint 2010

Il concetto è creare un CMS seguendo una serie di requisiti classici che un CMS dovrebbe avere:

  1. Autenticazione
  2. Visualizzazione dei contenuti
  3. Autorizzazioni e Ruoli
  4. Editing dei contenuti e gestione delle versioni
  5. Processo di approvazione dei contenuti e notifica

Nell'immagine seguente si può vedere quali siano gli attori in gioco e quali siano le operazioni che eseguono.

 

In particolare identifichiamo i seguenti:

  1. Viewer: non è nient'altro che l'utente finale, visualizzerà le pagine così come sono state approvate senza poter sospettare minimamente che ci sia una regia dietro ed in particolare un processo di editing e approvazione. Per lui sarà una normale web application. Nulla di più.
  2. Editor: è colui che può editare le pagine, modificandone a piacere i contenuti. Le sue modifiche saranno visibili solo agli altri Editor ed agli Approver. Perchè una modifica possa essere visualizzata da un semplice Viewer dovrà completare un processo di approvazione.
  3. Approver: è colui che deve decidere se una modifica può essere o meno pubblicata e quindi resa visibile ai viewer.
  4. Administror: è colui che ha accesso completo all'applicazione e la amministra.

Ovviamente gli attori in gioco sono ridotti all'osso garantendo quelli che sono i requisiti minimi dell'applicazione. Per quanto riguarda invece le risorse in gioco fondamentalmente troviamo:

  1. Web Server: è il cuore del CMS dove vengono visualizzati, editati ed approvati i contenuti.
  2. Content Repository: è dove i contenuti vengono memorizzati e dove viene mantenuta la history delle modifiche sugli stessi.
  3. User repository: dove sono presenti gli utenti con i loro dati

Inutile dire che la scelta di come implementare la soluzione ricada su Sharepoint 2010. Naturalmente i concetti sopra espressi possono essere tranquillamente mutuati sotto qualsiasi altra infrastruttura. Certo, come vedremo di seguito utilizzare Sharepoint ci consentirà di evitare l'implementazione di numerosi componenti evitandoci dolorosi mal di pancia in fase sia implementativa che di testing e deploying, per di più consentendoci un livello di personalizzazione notevole ed un'interfacca utente davvero intuitiva.

La soluzione basata su Sharepoint 2010 prevederà in pratica:

  • Sharepoint 2010: per la gestione della web application e del content management
  • Active Directory come repository degli utenti

Naturalmente scelto Sharepoint 2010 la scelta sul sistema operativo è limitata a Windows Server 2008 a 64 bit e SQLServer 2008, requisito minimo di funzionamento. Come autenticazione utilizzeremo quella integrata NTLM, dunque in caso di dominio l'autenticazione avverrà su di esso altrimenti in caso di server stand-alone si baserà sugli utenti di macchina.
Nella prossimo post cominceremo a creare la web application vuota e settare le prime configurazioni base su SP2010.