I Microsoft Office Labs hanno reso disponibile pptPlex, un add-on per PowerPoint che ... dà vita alle presentazioni aggiungendo effetti di zoom e pan durante la navigazione tra le slide (e all'interno della stessa slide, quando i contenuti sono troppo minuscoli).
pptPlex is a plug-in that explores an alternate method for presenting a PowerPoint slide deck. Using pptPlex, you can present your slides as a tour through a zoomable canvas instead of a series of linear slides
Le parole si spiegano molto peggio di un video :-)
L'ho installato e provato per qualche minuto e devo dire che è estremamente interessate, e non solo per via degli effetti.
Offre una modalità di navigazione (e quindi di presentazione) che ben si presta all'esposizione di contenuti non sequenziali, per la quale un ritorno ad una schermata di overview interattiva è utile didatticamente, oltre che molto ad effetto.
Utilizzare questo add-on "in produzione" forse è prematuro:
Q. Can I run my business with these tools?
A. These prototypes are unsupported so we don't think that would be a good idea.
Speriamo quindi in un buon supporto e, magari, in una integrazione nella prossima versione di Office :-)
Oggi mi sono appollaiato sotto il sole dell'alta Toscana con l'intenzione di preparare un po' di materiale per la SharePoint Conference di ottobre.
Ho riorganizzato un po' di esempi, completato qualche snippet di codice lasciato da un po' di tempo nei "todo" di outlook e poi mi sono dedicato al packaging per la sessione su STSADM che terrò con Igor.
Ovviamente non svelo nulla (:-P) ma, giacchè sono tuttora appollaiato sotto la luna dell'alta Toscana, vi scrivo un piccolo tip.
L'esigenza è stata quella di creare una solution SharePoint in grado di effettuare il deploy di una custom stsadm extension. Il che si riduce, per farla breve, alla distribuzione di un assembly in GAC (e sin qui nessun problema) e alla copia di un file in [12]\CONFIG.
Il meccanismo di packaging in solutions consente entrambe queste operazioni (definendo i relativi elementi Assembly e RootFile nel manifest della solution, e ovviamente includendo i file nel pacchetto generato):
<Solution ... >
<RootFiles>
<RootFile Location="CONFIG\stsadmcommands.Spc2008.xml" />
</RootFiles>
<Assemblies>
<Assembly Location="Spc2008.StsAdmExtensions.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
</Solution>
Purtroppo, però, STSDEV non è in grado di inserire file nella directory CONFIG.
Ponendo come presupposto che:
- Tutte le mie altre demo sono basate su progetti creati con STSDEV ... e vorrei mantenere un minimo di omogeneità almeno con me stesso :-)
- STSDEV è un tool eccellente, sia per funzionalità che per facilità di estensione
- STSDEV è corredato da codice sorgente
tutto sommato l'idea di metter su una patch non è così tanto campata per aria.
Step by step, la patch è costituita da:
1) In Globals.cs, definizione di un nuovo campo String all'interno della classe stsdev.Globals, inizializzato con il percorso della directory CONFIG:
public readonly static string ConfigFolder = RootFilesFolder + @"\CONFIG";
2) In CabDdfBuilder.cs, modifica del processo di generazione del file DDF (alla base della successiva creazione del pacchetto WSP), rilassando il controllo sull'esistenza delle directory nel ramo di progetto per includere anche RootFiles\Config:
if (Directory.Exists(Globals.IsapiFolder) || Directory.Exists(Globals.ResourcesFolder) || Directory.Exists(Globals.ConfigFolder))
3) In ManifestBuilder.cs, modifica del processo di generazione del manifest della solution, rilassando il controllo sull'esistenza delle directory nel ramo di progetto per includere anche RootFiles\Config:
if (Directory.Exists(Globals.IsapiFolder) || Directory.Exists(Globals.ResourcesFolder) || Directory.Exists(Globals.ConfigFolder))
Rebuild, test e via :-)
Ah, per inciso.
L'avete visto, no, che Ted Pattison (creatore - tra l'altro - di STSDEV) terrà una sessione proprio sulla sua creatura ?
Paul Andrew annuncia che è disponibile su Codeplex una "not-even-alpha version" della SharePoint Guidance.
La descrizione schematica che troviamo in home è piuttosto precisa:
Project Description
We plan to provide guidance to customers on how to build SharePoint Intranet Applications. This includes guidance on how to Architect, Design, and Develop applications as well as best practices.
Intended Audience
This guidance is intended for software architects and software developers who are building applications on Microsoft Office SharePoint Server. Familiarity with Windows SharePoint Services, Microsoft Office SharePoint Server, and ASP.NET is useful for evaluating the guidance.
Guidance is not even Alpha
Please note that this guidance is in draft form and will change dramatically before it is released on MSDN. We provide you access to drops to give you an idea of our direction and get your feedback. The code will continually be refactored until the point we publish it on MSDN.
Evidentemente ... "they heard from customers" (cit.) :-)
Non aspettatevi di trovare nulla di lontanamente definitivo ... però, visto che curiosare è in fondo lecito e, a dire il vero, richiesto, diamo un'occhiata partendo dalla "vision" di questa drop. Mi sono permesso un ritaglio dal pdf:
Interessante il ranking delle richieste più gettonate.
Il Debugging sembra avere la meglio su altre "piccole" questioni quali tooling (VSeWSS vs STSDEV vs WSPBuilder vs SmartTemplates vs Custom Batch vs Tutto A Mano ...) o Sviluppo in Team (che secondo me è invece il punto più interessante e aperto, e se volete va giù a domino coprendo la maggior parte degli altri desiderata).
Interessante soprattutto il fatto che alcune esigenze, che personalmente giudico *primarie* per *qualsiasi* ambiente di sviluppo, siano presentate in un documento di Vision come must have, e quindi sia lecito aspettarsi una risposta "ufficiale" (da seguire o non seguire a discrezione, ci mancherebbe, ma sempre utile come termine di confronto).
Mi riferisco in particolare al SDLC (Software Development Life Cycle) e a quanto/come/quando di questa disciplina si possa/debba applicare alle soluzioni SharePoint.
In termini più pratici, e solo per fare un esempio, tutti sappiamo che si devono fare i test, semmai il punto è individuare la metodologia più corretta per farlo, tenendo ovviamente in conto l'ambiente target, i suoi vincoli e le sue particolarità.
Alla SharePoint Conference avremo sicuramente occasione di discutere anche di queste cose. Io ho già pronta qualche domandina per Ted Pattison ... preparate le vostre :-)
Segnalo questo post di Rob Nowik che propone una soluzione, semplice ed efficace, per modificare le property di una web part al di fuori del "classico" tool pane.
Questo approccio può risultare assai utile, ad esempio, quando le proprietà che si vogliono gestire richiedono un cruscotto grafico particolarmente oneroso in termini di spazio sulla pagina, tanto da rendere insufficiente - o comunque troppo esiguo - il pannello laterale.
Da qualche tempo sono stati pubblicati due "poster" che illustrano graficamente le operazioni e le proprietà disponibili per la gestione di un'infrastruttura SharePoint via STSADM.
Per WSS: jpg, png, Visio
Per MOSS: jpg, png, Visio
Molto bene, così alla Microsoft SharePoint Conference 2008 io e Igor ve li mostreremo *tutti* :-O
Sono capitato un po' per caso a leggere questo post su Bamboo Nations (che, devo dire, sta scalando rapidamente la mia feed-parade).
Riporto qui un brevissimo e significativo excerpt:
[Deploying SharePoint Solutions]
So if you decide to put anything into the GAC make sure it's NOT shared by anyone else since then it will break if you retract one of the solutions....
Dunque, un minimo di spiegazione !
Il meccanismo di deploy delle solution SharePoint consente di installare, come parte del package, assembly nella Global Assembly Cache.
In questo senso (e in realtà non solo in questo senso, estendendo il discorso ad altri tipi di risorse o di location di installazione) le solution possono essere definite senza troppo margine di interpretazione "l'MSI di SharePoint".
Con le funzionalità aggiuntive che la piattaforma richiede (allineamento garantito tra i server della farm, per dirne una). Ma, anche, con qualche funzionalità in meno.
Si parlava di GAC.
La GAC è utilizzata (e pensata) come storage per assembly condivisi fra più applicazioni. Quando più applicazioni tentano di installare un assembly in GAC, possono richiedere la memorizzazione di riferimenti (si chiamano trace references) in modo tale da evitare disinstallazioni forzose e conseguenti, brutali crash.
Ho scritto possono ... perchè ovviamente ci sono le eccezioni.
Una di queste (purtroppo) è appunto il meccanismo di deploy delle solutions.
Prova del nove (seguire passo passo - uso le VSeWSS Extensions per rapidità, benissimo qualsiasi altro tool o il tutto a manina).
1) Creare un progetto class library, anche vuoto va benissimo (purchè compili !). Nell'esempio l'ho chiamato SomeSharedAssembly.
2) Firmare l'assembly (il metodo più comodo è dalle proprietà del progetto Visual Studio, voce Signing).
3) Build.
4) Creare uno SharePoint Empty Project (SolutionOne).
5) Add->Existing Item->La dll creata al punto 3.
6) Modificare il file manifest dela solution. Se avete usato le VSeWSS potete utilizzare il pane "WSP View", doppio click su manifest.xml. Ottenete qualcosa del genere (in bold la riga da aggiungere, ovviamente cambiando il nome della DLL creata al punto 3):
<?xml version="1.0" encoding="utf-8"?>
<Solution
SolutionId="961c3359-9b2b-4c29-86ed-b1a6399de968"
xmlns="http://schemas.microsoft.com/sharepoint/">
<Assemblies>
<Assembly Location="SolutionOne.dll" DeploymentTarget="GlobalAssemblyCache" />
<Assembly Location="SomeSharedAssembly.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
</Solution>
7) Build e deploy della solution.
8) Ripetere i punti 4..7, creando una solution identica con nome diverso (SolutionTwo, diciamo).
9) Ci troviamo con due solution installate e deployate (ripeto, se avete usato altri tool o avete scelto la strada "raw", alcuni dei punti precedenti possono cambiare, in particolar modo la creazione del package WSP e la sua successiva installazione).
10) Command prompt di Visual Studio (giusto per avere impostate le variabili d'ambiente) e lanciamo gacutil.exe (credo che gacutil non abbia bisogno di presentazioni, è *il* tool usato per esaminare ed interagire con la GAC via linea di comando).
11) gacutil -l SomeSharedAssembly. L'output dovrebbe indicare che è presente l'assembly richiesto:
D:\Windows\system32>gacutil -l SomeSharedAssembly
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
The Global Assembly Cache contains the following assemblies:
SomeSharedAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=38b02c7e6
914e65f, processorArchitecture=MSIL
Number of items = 1
12) stsadm -o retractsolution -name solutionone.wsp -immediate (controllate di avere stsadm nel path, altrimenti lo dovete invocare con il suo percorso completo, [12]\bin)
13) stsadm -o execadmsvcjobs (se non volete aspettare nemmeno quei pochi secondi affinchè il timer job che effettua il retract (= undeploy) della solution venga eseguito
14) Di nuovo gacutil -l SomeSharedAssembly.
15) Osservare e riflettere ...
Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
The Global Assembly Cache contains the following assemblies:
Number of items = 0
Abbiamo due solution che utilizzano lo stesso assembly condiviso. Facendo il retract di una delle due (a caso) abbiamo disinstallato l'assembly dalla GAC ... lasciando l'altra in braghe di tela :-O
Sarò breve. He he ... forse dal titolo non si direbbe :-)
Provo almeno ad essere schematico.
Esigenza: erogare funzionalità di data entry tramite form infopath renderizzate dal browser (via FormsServices) mantenendo, però, l’aspetto del sito SharePoint. In altre parole, inserire il “content” che IPFS ci mette a disposizione in una pagina che usi la master page del sito SharePoint in questione.
Soluzioni: ce ne sono un po’.
Una, ad esempio, che cito giusto per dovere di cronaca, è quella di usare una PageViewerWebPart che punti all’URL delle pagine aspx di FormsServices. Ammesso e non concesso che utilizzare un IFrame sia realmente necessario :-)
In alternativa (molto meglio a mio parere) si può usare il controllo XmlFormView (Microsoft.Office.InfoPath.Server.Controls.XmlFormView), che abbiamo a disposizione “aggratis”, giacchè alla fine la licenza di IPFS l’abbiamo pagata. E da buon ligure questo è già un motivo sufficiente.
XmlFormView è una web part piuttosto interessante - peraltro utilizzata anche dalle pagine native di IPFS - e dall’uso decisamente immediato. Talmente tanto da rendere possibile la creazione di interfacce semplici anche solamente mediante browser.
Il procedimento è abbastanza lineare, e potrebbe essere questo:
· Aggiunta del controllo suddetto all’elenco di SafeControls per la web application di interesse (un punto in più se decidete di fattorizzare la cosa in ottica di deploy ed inserite la modifica nel manifest di una solution ... anzi no ... due punti)
· Provisioning della web part sulla site collection (Site Settings -> Web Parts -> New -> Selezionare XmlFormView e cliccare su Populate Gallery)
· Si crea una document library dedicata alla memorizzazione delle pagine di data entry (nulla vieta di usarne una preesistente, se non una pura questione di separazione logica dei contenuti)
· Le si associa il content type WebPartPage (non necessario se in fase di creazione della document library abbiamo scelto WebPartPage come template per i nuovi documenti)
· Si crea ... indovinate ? … una WebPartPage :-)
· Si inserisce XmlFormView nella zona che maggiormente ci aggrada
· Si completa la configurazione della web part
Yep. Ma ci sono comunque un paio di considerazioni da tenere in conto.
Una, che vale un po’ sempre, è che ciò che facciamo via browser può arrivare ad un punto di non ritorno, quando le funzionalità out-of-the-box non sono sufficienti (giusto per anticipare la risposta alla domanda “ma come faccio a passare dei parametri alla form ?”).
Questo fa da contrappeso agli (indubbi) vantaggi che ci sono, uno su tutti la possibilità di delegare le operazioni ad un “power user”. Basta saperlo e scegliere di conseguenza.
L’altra considerazione che, invece, prescinde un po’ di più dalle prospettive è legata alle performance pure e semplici.
Una pagina creata come item di una document library è memorizzata in DB. Il che implica un peso non sempre trascurabile per il sistema, che si trova a non poter riutilizzare il codice compilato della pagina ASPX (la stessa cosa che succede per le famose pagine unghosted/customized che si ottengono, ad esempio, modificando un’istanza di pagina con SharePoint Designer).
Logicamente, se si riescono a fattorizzare le funzionalità di una “pagina host con master page”, la strada più conveniente è quella di definire un page template, creando poi istanze della pagina host nei siti di interesse.
Non è così complesso come può sembrare, basta giocare un po’ con le feature ... oops ... Feature di SharePoint 2007.
Ecco qualche riga di codice.
La pagina ASPX, innanzitutto, almeno le “parti salienti”:
<%@ Page Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage" MasterPageFile="~masterurl/default.master" .... />
<%@ Register Assembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.InfoPath.Server.Controls" TagPrefix="ip" %>
<%@ Register Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WebPartPages" TagPrefix="wss" %>
<asp:Content ID="cntMain" runat="server" ContentPlaceHolderID="PlaceHolderMain">
<div>
<ip:XmlFormView ID="frmViewer" runat="server" Height="100%" Width="100%" … />
</div>
</asp:Content>
Manca qualche “piccolo pezzo”, per dirne un il path del form template (o del documento InfoPath). Vi rimando alla documentazione del controllo XmlFormView su MSDN per ogni informazione riguardante i parametri necessari a mostrare documenti InfoPath al suo interno.
Scrivo qui, invece, l’element manifest di una feature che effettua, una volta attivata, il provisioning della page instance:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Path="PageTemplatePathOnFileSystem" Url=”PageInstanceUrl”>
<File Url="FormViewer.aspx" Type="Ghostable"></File>
</Module>
</Elements>
L’attributo Path indica il percorso, sul file system del front-end e relativo alla directory della feature, a partire dal quale verrà copiato il file FormViewer.aspx.
L’attributo URL specifica, invece, il suo percorso relativo alla root del sito web sul quale la feature viene attivata.
Con un po’ di lavoro in più (non molto, alla fine) è infine possibile “parametrizzare” la pagina, valorizzando quindi le proprietà del controllo XmlFormView in maniera dinamica ed ottenendo, alla fine dei giochi, una pagina generica e riutilizzabile.
Voila. Enjoy InfoPath :-)
Visto l'effetto delle traduzioni, non mi cimento e mi limito al copia e incolla.
Dryad is a general-purpose distributed execution engine for
coarse-grain data-parallel applications.
A Dryad application combines computational “vertices” with communication “channels” to form a dataflow graph.
Dryad runs the application by executing the vertices of this graph on a set of available computers, communicating as appropriate through files, TCP pipes, and shared-memory FIFOs.
The vertices provided by the application developer are quite simple and are usually written as sequential programs with no thread creation or locking.
Concurrency arises from Dryad scheduling vertices to run simultaneously on multiple computers, or on multiple CPU cores within a computer.
The application can discover the size and placement of data at run time, and modify the graph as the computation progresses to make efficient use of the available resources.
Potete leggere di più (non molto a dire il vero) sul sito di MSR qui.
Non è certo una scoperta che l'investimento (ricerca, studio, progettazione) sulla programmazione concorrente sia *la* direzione corrente e futura (prossima e forse non tanto prossima).
Quello che è interessante, a mio parere, è il fatto che (almeno dal punto di vista teorico) gli studi e gli esempi di architettura parallela applicata alle tecniche di programmazione datino, a volte, indietro di qualche decade.
Però sfruttare i principi e le idee di tecnologie o soluzioni precedenti non significa non poterle (o doverle ?) rielaborare sulla base dell'avanzamento tecnologico attuale.
E sennò da dove saltava fuori DryadLINQ :-P
Durante la creazione di uno script PowerShell di "dumping" di una site collection, sono incappato in un errore che mi ha incuriosito.
Nel tentativo di accedere alla property ContentDatabase di un'istanza di SPSite, la shell mi ha risposto picche con il seguente errore:
PS D:\Users\clu> $site.ContentDatabase
out-lineoutput : The field/property: "Id" for type: "Microsoft.SharePoint.Administration.SPContentDatabase" differs only in case from the field/property: "ID". Failed to use non CLS compliant type.
PS D:\Users\clu>
Mmhhh ... senti senti ... vuoi mica dire ...
Per garantire l'operabilità tra linguaggi che targetizzano il .NET Framework, è stato definito un insieme di regole, che vanno sotto il nome di Common Language Specifications.
Rispettando tali regole (non è difficile ... i compilatori ci danno una mano in questi casi) gli autori di librerie possono essere certi che i tipi che definiscono saranno utilizzabili senza problemi da *qualsiasi* linguaggio usi il client.
Per fare un esempio, C# supporta i tipi pointer, che però non sono CLS-Compliant. Inutile esporli pubblicamente se, poi, è richiesta l'interoperabilità :-)
C'è un'altra regola, forse la più nota di tutte, che impone di assegnare nomi differenti ai membri (overload a parte), senza considerare maiuscole e minuscole.
Le verifiche, chiaramente, si applicano solamente all'interfaccia che il tipo espone al chiamante (quindi ai membri public e protected).
In C#, ad esempio, è molto frequente uno stile di codifica che utilizza camelCasing per i campi privati e PascalCasing per le proprietà pubbliche che li incapsulano, e il tutto è perfettamente lecito.
Per curiosità ecco la definizione di SPContentDatabase (snapshots courtesy of Reflector).
SPContentDatabase ha la seguente catena di ereditarietà:
Definisce un campo pubblico ID, di tipo System.Guid:
Ma SPPersistedObject (tre livelli di ereditarietà sopra) definisce a sua volta un membro pubblico, Id, di tipo System.Guid:
Andando a spulciare il body del getter di SPContentDatabase::Id (minuscolo) ... indovinate un po' che valore ritorna ? (Vedere penultima immagine).
In realtà il caso è ancora più interessante perchè, nella documentazione di SPContentDatabase::ID, il membro è indicato come obsolete. Era presente nell'OM di WSS2.0, ora consigliano di usare la property Id (minuscolo) della classe base.
Dicevo interessante perchè è un esempio delle scelte che si trova ad affrontare chi rilascia la v2 dei propri componenti (a maggior ragione quando gli utilizzatori sono piuttosto numerosi :-)).
Eliminare la proprietà, a questo punto ridondante, da SPContentDatabase sarebbe stata la soluzione più pulita e avrebbe garantito la CLS compliance.
Ma avrebbe di fatto "rotto" la retrocompatibilità.
Ho fatto un giro per leggere quali sono i commenti a riguardo. Qui ad esempio, con annessa indicazione di un modo per circumnavigare il problema. Viene proposto di utilizzare GetMethod per invocare il getter (il metodo get_ID) di SPContentDatabase::ID.
E' chiaro che andando di reflection molte questioni si riescono a risolvere (e se è per quello, ad avere i diritti, si riescono tranquillamente ad invocare metodi privati o a cambiare lo stato interno degli oggetti).
Però ... è proprio una cura del sintomo :-(
Dal blog del team di SharePoint l'annuncio(*) fresco fresco dell'apertura di un sito (http://www.mssharepointdeveloper.com/) che mette a disposizione risorse introduttive allo sviluppo su piattaforma SharePoint (WSS3/MOSS2007):
There are Whitepapers, Virtual Labs, Web casts, Screen casts, Quickstarts & other resources. You can also download a SharePoint development VPC with all the tools you need to get started already installed
Al di là del look&feel accattivante, rigorosamente Silverlight-style, direi che è da tenere d'occhio, in particolare per chi si avvicina a SharePoint e ne vuole almeno "assaggiare" qualche aspetto.
(*) Della disponibilità di VSeWSS 1.2 per Visual Studio 2008, altro argomento del post in questione, ha appena scritto Paolo, quindi vi rimando al suo post.
Oggi da un cliente, più o meno 12 secondi dopo aver varcato la soglia, mi è stata fatta una domanda che sul momento mi ha lasciato piuttosto perplesso.
"Perchè quando modifico il testo in un documento Word (*) il valore aggiunto non viene semplicemente appeso al termine del precedente, ma tra i due viene frapposto del contenuto ?"
Contestualizzo un minimo.
Il documento in questione è WordML, utilizzato come formato nella generazione (via XSL) di documenti Word a partire da moduli InfoPath (niente document converters, nè OpenXML, nè tanto meno word print view causa necessità di compatibilità con Forms Services).
Il contenuto testuale di origine:
<w:p wsp:rsidR="00E57442" wsp:rsidRDefault="00434E2F">
<w:r>
<w:t>Ciao</w:t>
</w:r>
</w:p>
dopo una semplice modifica, si trasforma in:
<w:p wsp:rsidR="00E57442" wsp:rsidRDefault="00434E2F">
<w:r>
<w:t>Ciao</w:t>
</w:r>
<w:r wsp:rsidR="00C2519A">
<w:t> a Tutti</w:t>
</w:r>
</w:p>
Il che rende *un po' scomodo*, ad esempio, il find and replace di turno :-)
In altri termini, a priori mi sarei aspettato una versione due come segue:
<w:p wsp:rsidR="00E57442" wsp:rsidRDefault="00434E2F">
<w:r>
<w:t>
Ciao a tutti</w:t>
</w:r>
</w:p>
Il motivo di questo comportamento, almeno per me, inaspettato è spiegato nel dettaglio in questo post di Brian Jones.
Ne riassumo in due righe il significato, rimandando ogni approfondimento direttamente alla fonte.
Word memorizza dei revision identifiers (RSIDs), indipendentemente dal fatto che la funzionalità di track changes sia o meno abilitata sul documento in questione. Tali id sono numeri casuali e non contengono, per ragioni di sicurezza, alcuna indicazione che consenta di risalire all'utente che ha apportato le modifiche. Risultano utili nel caso di fork delle modifiche sui documenti, poichè eventuali merge successivi si riducono ad una indagine sulle revisioni (memorizzate come attributo nel documento stesso).
Bello. E se non lo voglio ?
Dalle opzioni del Trust Center (sia in Word 2003 che in Word 2007), Privacy Options e deselezione del check "Store random numbers to improve Combine accuracy".
Credits a Vittorio e a Mattia per la segnalazione (e per l'aver individuato in tempi brevi il workaround :-P).
Dopo qualche (rapida e poco significativa) prova su virtual machine, ho installato MOSS sul mio sistema host (Vista Ultimate sp1).
Le prime impressioni sono direi piuttosto positive. Solo un piccolo workaround, peraltro già noto e documentato (qui), e per il resto non ho ancora trovato particolari ostacoli.
Almeno per quel che riguarda un ambiente dedicato *solo* alla prova volante.
Non è solo uno sfizio quello di avere a portata di click un sistema ad uso quick test.
Ad esempio, a me capita ogni tanto di avere qualche idea di risoluzione di un problema senza avere un Visual Studio aperto su VM con MOSS installato (ehm ... forse meno spesso di quanto dovrebbe :-)).
Ora, se vogliamo aggiungere alla fuggevolezza dell'attimo anche quel minuto o due che servono a tirar su una macchina virtuale ed essere in condizioni di tradurre l'idea in mock-up ...
Credo che la rapidità di accesso alle funzionalità di un sistema abbia un valore enorme nel momento in cui consente di "cogliere l'attimo".
Mi viene in mente un paragone, un po' stiracchiato, con la scrittura al PC vs. la scrittura su carta.
Personalmente uso ormai da anni il computer per scrivere. *Quasi* tutto. Rimangono fuori le cose che escono più di getto. Su quelle la carta è ancora imbattibile.
Perchè ?
E' un giudizio personale, ma la ritengo ancora un mezzo più immediato. E qualche piccola frazione di secondo può fare la differenza.
Quello che scrivo su carta, nel momento in cui dovrà essere formalizzato, verrà trasportato su formato elettronico. Nessun dubbio a riguardo, non fosse altro che per una questione di leggibilità e di correttezza sintattica.
Dello scritto originale rimane il significato. La forma ... può darsi, non necessariamente. Una revisione ? Sempre e comunque.
Lo stesso approccio credo possa essere usato per gli ambienti di quick test.
Ottimi per catturare le intenzioni dell'autore / sviluppatore.
Ma probabilmente sconsigliabili se il prodotto del test deve essere, in qualche modo, significativo o semplicemente (un minimo) affidabile.
A conclusione, e per ritornare un po' più on-topic, trovo che la disponibilità di un sistema SharePoint installato sulla macchina di lavoro (per chi ci lavora :-)) sia estremamente interessante. Altri discorsi (ristrutturazione degli ambienti e dei processi di sviluppo) potranno essere affrontati quando il supporto sarà maggiore.
Patrick Tisseghem illustra in questo post i passi necessari per configurare una web application SharePoint all'uso dei Silverlight Blueprints for SharePoint [sorry per le ripetizioni].
Vorrei segnalare a tal riguardo un'aggiunta alla "suite" di features che Scot Hillier (& c.) sviluppa e distribuisce su Codeplex (qui), tramite la quale è possibile apportare le modifiche al web.config in maniera automatica (e facilmente reversibile).
W le SPWebConfigModifications :-)
Questi qui sopra non sono opera di Photoshop, e oggi non è il primo di aprile ...
Leggendo un po' i post "arretrati" della settimana sono finito su Bamboo Nation e chiaramente un titolo quale
How to install Windows SharePoint Services 3.0 SP1 on Vista x64/x86
ha *un pochino* attirato l'attenzione.
Con ordine ...
Il team di Bamboo Solutions ha sviluppato un preinstaller che consente l'installazione di WSS (con Service Pack 1) su sistemi Vista (x86 e x64).
<Disclaimer>
Il prodotto è ancora in versione beta (quindi non è consigliato l'utilizzo in ambienti di produzione). Inutile aggiungere che non esiste, ad oggi, alcun supporto da parte di Microsoft.
</Disclaimer>
Ho scaricato il tool (link diretto qui) ed ho provato il tutto su una macchina virtuale nuova di zecca, con Vista Business (tra l'altro senza sp1).
L'installazione non ha dato problemi particolari. Vi rimando al post che ho segnalato per tutti i dettagli (compresa la configurazione di IIS, ovviamente necessaria).
E quindi ? Cosa cambia ?
Personalmente faccio due considerazioni (con ottiche temporali differenti).
Nel breve (speriamo brevissimo :-)) periodo, durante il quale il tool è ancora in beta, si tratta secondo me di giocarci un po', con lo scopo di dare tutti i feedback possibili al team che ne sta portando avanti lo sviluppo. Non vedo ancora proponibile l'adozione di alcuna soluzione (neanche lo sviluppo) in questa fase transitoria.
Ma nel momento in cui il prodotto si stabilizza ... beh ... allora si inizia a ragionare !
Il più grosso vantaggio, a mio parere, è nella possibilità di utilizzare Vista come sistema operativo per i computer di sviluppo, senza la necessità di ricorrere all'utilizzo di macchine virtuali (con Windows Server 2003/2008). Non fosse altro che per poter "provare al volo" una personalizzazione o verificare il comportamento del sistema in tempi rapidi (e magari senza dover attaccare il disco esterno :-))
Ah, le ultime due note che mi sono venute in mente scrivendo.
1) No, non è una buona notizia perchè così si possono mettere in produzione installazioni di SharePoint che girano su Vista (che *non è* e di sicuro *non diventa* un sistema operativo server !!)
2) No, non aspettatevi la versione per XP. E non per cattiveria, ma perchè la versione di IIS che gira su XP (5.1) è caratterizzata da un'architettura interna e da un process model esposto alle applicazioni che non è sufficiente per consentire a SharePoint di essere eseguito. Gli application pool a qualcosa serviranno bene, o no ? :-P
Cambio i nomi dei namespace e dei tipi, per non fare pubblicità negativa ad una class library che, peraltro, è decisamente ben fatta.
La nota dolente è però relativa alla documentazione (ma và, che caso ...).
C'è una enum (chiamiamola colloquialmente IlMioBoolean) che, oltre a True e False, espone un elemento "Default".
C'è una classe (chiamiamola colloquialmente Pippo) che espone una property (chiamiamola colloquialmente Paperino) di tipo IlMioBoolean.
La documentazione di Paperino, la property, recita quanto segue (parafrasi):
Vale IlMioBoolean.True se abilitato. Vale IlMioBoolean.False se disabilitato. Per default vale IlMioBoolean.Default.
IlMioBoolean.Default vale (secondo la documentazione):
True o False a seconda della classe che lo utilizza.
La domanda sorge sponatena.
Quanto vale Pippo.Paperino, se non lo imposto diversamente ? :-O
More Posts
Next page »