martedì 26 gennaio 2010

Best Master Page

Facendo mente locale all'esperienza passata e ad alcuni studi recenti, con relativa sperimentazione, sono giunto alla seguente conclusione: se dovessi riscrivere una custoim master page userei solo codice html e placeholder. Detta così non c'è nulla di inaspettato, ma spiegando quanto ho in mente forse qualche perplessità potrebbe nascere. Vi invito quindi fin da subito a commentare quanto andrò a dire, concedendomi l'attenuante di una temporanea insanità mentale e del fatto che non propongo ciò come LA SOLUZIONE, ma semplicemente come uun'idea che mi è venuta in mente, o perlomeno una presa di coscienza.

L'invenzione dell'acqua calda consiste in questo: invece di mettere i controlli direttamente nella master page, soprattutto quelli custom (si pensi per esempio al rendering accessibile dei menu tramite l'utilizzo delle componenti di ARF, che ho menzionato in post precedenti), andrei a posizionarli in control template personalizzazati, posizionati in pagina tramite feature, utilizzando appunto i delegate control. Un vantaggio che mi viene in mente, e qui potrebbero scatenarsi i detrattori, è la possibilità di scrivere del codice runat server all'interno dei controlli ascx, cosa che nelle master page non è possibile fare; questo mi permetterebbe volendo (anche se non è il sistema più elegante dal punto di vista dei puristi dello sviluppo) di non generare codice compilato in DLL. Ovvero ad eventuali modifiche non dovrei ricompilare il codice per riportarlo o nella bin della web application oppure in GAC.

A questo punto sono pronto alla pubblica lapidazione. Ben venga se ne esce qualcosa di costruttivo che ci consenta di scrivere delle buone master page, facilmete manutenibili.

Aggiungo qualche link di approfondimento:
User Control in Master Page (Page Footer)
Sovrascrivere i DelegateControl

mercoledì 20 gennaio 2010

SPSecurityTrimmedControl no XHTML compliant

Leggendo un recente post di Barbara Falchi, ho scoperto che anche in SharePoint 2010 il controllo SPSecurityTrimmedControl viene renderizzato con il tag SPAN. Questo comportamento è molto noioso se si cerca di creare pagine XHTML, perchè si viene a generare del codice sintatticamente scorretto. Mi vado a spiegare: il controllo SiteActionMenu viene renderizzato come DIV con tutta la relativa struttura di anchor etc., se incluso in nel controllo SPSecurityTrimmedControl genererebbe un DIV contenuto in uno SPAN; ovvero un tag block contenuto in un tag inline, fortemente scorretto. Se invece si volesse utilizzare SPSecurityTrimmedControl per nascondere qualcosa contenuto nel tag HEAD (un css o un javascript per esempio) si andrebbe di male in peggio, in quanto i tag accettati nel tag HEAD non sono molti e se non erro tutti inline.

Il motivo per cui il controllo SPSecurityTrimmedControl genera uno SPAN e da ricercarsi nella sua implementazione; il controllo deriva da System.Web.UI.WebControl che di default crea proprio un tag SPAN:

// costruttore
protected WebControl() : this(HtmlTextWriterTag.Span) {}


A dire il vero il WebControl prevede altri due costruttori:

protected WebControl(string tag)
{
this.tagKey = HtmlTextWriterTag.Unknown;
this.tagName = tag;
}

public WebControl(HtmlTextWriterTag tag)
{
this.tagKey = tag;
}


Peccatto che il controllo SPSecurityTrimmedControl non li utilizzi.

public SPSecurityTrimmedControl()
{
}

internal SPSecurityTrimmedControl(HtmlTextWriterTag tag) : base(tag)
{
}


A mio parere sarebbe stato meglio avere la possibiltà di valorizzare una proprietà pubblica per poter scegliere il tag da renderizzare (tra SPAN e DIV) o semplicemente avere la possibilità di renderizzare solo il contenuto del controllo, comportamento che lo avrebbe reso utilizzabile a livello di HEAD. Logicamente è sempre possibile scrivere un proprio controllo, ma questo lo dedico alla prossima puntata. Intanto vi segnalo un post che tratta del controllo SPSecurityTrimmedControl, evidenziandone altri problemi. Ho comunque il sospetto che il post in questione faccia riferimento ad una versione del controllo precedente alla service pack 2.0 di SharePoint. Qualcuno me lo può confermare?

venerdì 15 gennaio 2010

SharePoint 2007 & XHTML

Per esperienza personale, oltre al fatto che è anche dichiarato da Microsoft, SharePoint 2007 non è in grado OOTB di generare codice XHTML valido, indipendentemente dal DOCTYPE utilizzato. Fortunatamente qualche espediante per raggiungere un buon grado di aderenza allo standard XHTML c'è.

Parlo principalmente della carateristica di publish del MOSS, di cui ho più esperienza. I problemi derivano per esempio dal rendering dei campi RitchImage, che aggiungono attributi deprecati e scrivono il tag in maiuscolo. Per risolvere questo problema si può ricorrere agli adapter. Molti progetti presenti in Codeplex inerenti all'accessibilità fanno ricorso a questo espediante; consiglio:
Tutti progetti che affrantano il problema della resa del codice conforme allo standard XHTML; dal mio punto di vista non esiste il progetto risolutore, un mix delle soluzioni è l'approccio migliore.

Un altro consiglio per generare del buon codice è di usare il più possibile le Content by Query WebPart, che generano il codice html tramite XSLT. Questo permette al programmatore di maggior controllo sul codice generato. L'unica accrotezza da tenere presente è che gli XSLT usati dalla CQWP generano HTML pertanto il consiglio è di modificarli per fargli generare in output del codice XML. Per avere un controllo maggiore, tramite browser, delle CQWP, ho usato una WebPart che le estende e che espone anche quelle proprietà che altrimenti sarebbero visibili solo esportando la webpart stessa; la webpart è la Extented CQWP di Waldek Mastykarz (Paging Content Query Web Part).