mercoledì 30 dicembre 2009

Blogs su SharePoint

Segnalo due nuovi blog in italiano si Sharepoint; uno più orientato ai site builder, mentre l'altro dedicato all'architettura di SharePoint e ai suoi aspetti sistemisitici.

http://nonsolosharepoint.wordpress.com/
http://sharepointpig.wordpress.com/

domenica 27 dicembre 2009

SharePoint 2007 e le risorse globali

Mi è stato detto che se si vuole creare una WSP che distribuisca in automatico le risorse globali è necessario che nel manifest.xml i file di risorse siano dichiarati ApplicationResourceFile nell'apposita sezione ApplicationResourceFiles (http://stackoverflow.com/questions/296003/deploy-a-resource-file-to-appglobalresource-folder-on-activation).

Siccome con WSPBuilder non è possibile ottenere un manifest così fatto è necessario procedere a mano, ma facendoci aiutare da WSPBuilder fin dove possibile.
Per prima cosa copiare nella root del progetto il file WSPBuilder.exe.config e impostare a true la proprietà BuildDDF: .

Mettere i file di risorse nella cartella Resources all'interno della cartella 12.

1 - Generare una wsp, copiarla e rinominarla con estensione .cab.
2 - Aprire il file cab ed estrarre il manifest.xml.

3 - Modificare il file cab aggiungendo sotto

<rootfiles>
<rootfile location="Resources\myResource.en-US.resx">
<rootfile location="Resources\myResource.resx">
</rootfile>

il codice seguente

<applicationresourcefiles>
<applicationresourcefile location="myResource.en-US.resx">
<applicationresourcefile location="myResource.resx">
</applicationresourcefile>

4 - Scaricare il "Microsoft Cabinet Software Development Kit" e creare il file CAB a mano con MakeCab.exe.
5 - Rinominare il file cab in wsp e installarla in sharepoint con stsadm.

Dopo aver fatto tutto questo, però, mi sono accorto che i file di risorse invece di essere compiati nella cartella App_GlobalResources, vengono copiati in un cartella "resources" sempre all'interno della web application di SharePoint ospistata da IIS nella quale la nostra wsp è stata deployata.

Dopo un po' di ricerche ho trovato questo articolo (http://www.mikhaildikov.com/2007/03/sharepoint-resources-types-use-and_2163.html) in un blog che spiega bene come in effetti gli elementi de manifest ApplicationResourceFiles e Resources siano inutili e suggerisce un modo per copiare a runtime i file di risorse nella cartella App_GlobalResources. Un altro utile articolo sui file di risorse è "SharePoint Internals: Resources".

Se qualcuno ha sperimentato altri modi ho ha trovato il sistema di usare i sopra citati elementi del manifest non abbia problemi a scrivere un commento. La stessa cosa vale se sapete come funziona il meccanismo delle risorse in SP 2010. Nella speranza che ci siano stati dei miglioramenti nella gestione delle risorse globali.

mercoledì 23 dicembre 2009

SharePoint 2010 Client Object Model

Fianalmente cominciano a trovarsi svariati video su SharePoint 2010 che entrano in dettaglio sulle novità di questo nuovo prodotto di Microsoft. Essendo molto attratto dalla nuova interfaccia e curioso di capire come poter sviluppare siti che si avvicinino sempre più all'esperiece degli utenti, mi sono concentrato sui video che mostravano una delle grandi novità della UI si SP 2010; il Client Object Model.

Vi segnalo due video in cui parla Andrew Connell:
Overview of the Client Object Model
ECMAScript Client Object Model

Nell'articolo seguente invece viene fatto un paragone tra le applicazioni client stile SP 2007 e quelle che saranno con SP 2010:
SharePoint 2010: Introducing the Client Object Model

Nel secondo in particolare, fate attenzione quando viene mostrato il controllo SharePoint:ScriptLink che ha un attributo nuovo LoadAfterUI. Questo attributo non viene spiegato ma immagini serva per indicare a SharePoint di caricare lo script sp.js in modo asincrono, dopo che la pagina è stata caricata completamente.

Il client object model faciliterà l'accesso ai dati. Esistono ancora i web service, ma il client object model ne è una valida alternativa.

Altra novità sono le REST API di SharePoint.

giovedì 10 dicembre 2009

Costruire un sito web - riflessioni

Costruire un sito web è come costuire una casa.

Bisogna avere un progetto, segliere i materiali e seguire gli standard. Gli architetti che disegnano la casa hanno anche le basi di ingegneria per sapere che quello che disegnano starà in piedi, poi si fanno aiutare per i calcoli delle forze, ma un'idea di base riescono a farsela da soli; almeno i più bravi. I problemi da affrontare nel progettare una casa sono sempre gli stessi, al massimo aumentano un po' le complessità se la casa è a più piani, in una zona sismica oppure un grattacielo. Di certo i materiali sono pressapoco sempre gli stessi: cemento, legno, ferro etc. Gli architetti più smalizziati e ripesttosi delle leggi si preoccupano dell'abbattimento delle barriere architettoniche e per endere più confortevole e abitabile la casa pensano a una serie di servizi utili a chi ci abiterà.

Se ci pensate progettare un sito web ha le stesse analogie, purtroppo la sua costruzione non sempre segue le stesse regole utilizzate per progettare una casa. Spesso i designer non parlano le lingue del web, ragionano solo con la carta e curano solo l'aspetto finale del sito. Usabilità (i confort della casa) o l'accessibilità (l'abbattimento delle barriere architettoniche) sono parole usate a puro titolo commerciale, ma non ne conoscono le basi. La stessa cosa spesso la si può dire anche per gli stessi sviluppatori. Conosco programmatori ASP.NET che non conoscono il protocollo HTTP, che non sanno come funzionano le FORM. Altri che ignorano il linguaggio CSS e non sanno che per scrivere uno script Javascript cross-browser è meglio affidarsi al DOM del W3C, usano ancora "document.all"! Come se un muratore non sapesse fare il cemento o riconoscere un mattone.
Ho parlato con grafici che non conoscevano le unità di misura del web, lavoravano solo in pixel. Altri che non conoscevano il significato delle misure in percentuale: "allora a 1024x768 la colonna destra la facciamo del 30%, mentre a 800x600 la facciamo del 25%"! Cosa? Fissiamo una percentuale e la teniamo per tutte le risoluzioni.

Nessuno di noi si cimenterebbe da solo a costruirsi la casa, mentre tutti bene o male abbiamo provato a fare un sito. Chi lo fa di professione dovrebbe approfondire i fondamentali e specializzarsi nel proprio ruolo, ma sempre più spesso questo non si fa.

sabato 5 dicembre 2009

Un po' di medicina per i nostri CSS

Ormai è chiaro a tutti che scrivere codice html cross-browser utilizzando XHTML e CSS in passato era come camminare in un campo minato, a causa delle implementazione più o meno fedele degli standard. Il libro che sto leggendo "Progettare libri web standard" riassume un decennio di storia dei browser motivando anche alcune scelte che hanno introdotto alcune volte delle errate interpretazioni degli standard css, si pensi per esempio al caso del Broken Box Model di IE. Nel leggere il libro mi sono accorto che nel corso della mia vita professionale, che è cominciata nel 1999, ho visto tutte le cose elencate nel libro, e ho anche scritto codice HTML usando quei mezzucci descritti nel libro come immondizia HTML. Per fortuna la scoperta dei css e di XHTML mi ha aperto gli occhi.

Vi riporto un po' di link utili menzionati nel libro di siti in cui vengono presentati i vari bug che affliggono i più comuni browser.

Oltre a descivere i vari bug vengono proposte anche delle soluzioni per poter scivere del codice HTML il più possibile cross-browser.