Beren.it

All that you can leave behind

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'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.

 

RichText Editor in SharePoint 2010

Il Richt text editor out-of-the-box del CMS di Sharepoint 2010

Il RichText editor in Sharepoint, almeno fino al 2007, è sempre stato un grosso problema: difficile da customizzare e soprattutto non particolarmente sofisticato, spesso richiedeva l'ausilio di editor di terze parti (come il Rad per fare uno dei nomi più gettonati). Così entrando nella nuova piattaforma di mamma Microsoft, si riproponeva il problema: quale editor WYSIWYG avranno implementato i pazzi di Redmond? Avranno provato a colmare questo gap, magari con una soluzione intelligente?
La risposta è SI, ed è un SI pieno perchè partendo dal concetto che il nuovo SharePoint rende sempre disponibile nella pagina il Ribbon Office like, con pochissima configurazione è possibile ottenere lo strumento di formattazione del testo tipico ad esempio di Word con tutte le funzionalità ad esso connesse come si può notare dall'immagine qui sotto:

Per poter usufruire di quersto tipo di controllo occorrono fondamentalmente due cose:

  1. Un custom field di tipo HTML
  2. Un controllo di PublishingWebControls:RichHtmlField

Per realizzare il primo basta creare una feature che deploy un field di tipo HTML nel modo seguente:

[XML]

  <Field ID="{27F5254A-888B-48c6-909D-C87BCDB264C8}"
  Name="RichTextEditor"
  Type="HTML"
  Group="Custom Xin Field"
  DisplayName ="Rich Text Xin Editor"
  RichText="TRUE"
  RichTextMode="FullHtml" >

dove i valori chiave sono: Type="HTML", RichText="TRUE" e RichTextMode="FullHtml".
Per quanto riguarda il controllo da embeddare nella pagina invece fondamentalmente è sufficiente specificare il field su cui si andrà a lavorare (inutile dire che il field deve essere associato alla pagina in cui poi il controllo è inserito):

[XML]

<PublishingWebControls:RichHtmlField 
FieldName="RichTextEditor" runat="server"/>

Va detto che per chi non gradisse tutte le libertà fornite dal controllo c'è una vasta gamma di opzioni attivabili sullo stesso, ad esempio per disattivare la scelta del font, l'inserimento di URL etc... Per un overview consiglio di dare un occhio all'MSDN.