Man kan titta på videos och köra virtual labs (IE 6 och högre för detta). Virtual lab är inte det roligaste och mest flexibla formatet tycker jag personligen, men det är ju bättre än inget.

Vad består då sandboxen av? Jo det är en separat process som körs som en windows service på en maskin i farmen, det kan vara på en WFE eller på någon annan maskin om man vill balansera last. Denna User Code-service (user code är ett nytt begrepp som betyder kod som körs i sandbox med de begränsade rättigheter det innebär) kommunicerar med w3wp-processen på frontenden som tar emot requesten och sedan körs koden i sandboxprocessen.

För att illustrera med ett exempel: Jag startar upp ett Visual Studio 2010-projekt, väljer Empty Project under SharePoint 2010-mallarna, väljer att det ska deployas som Sandboxed solution. Sedan lägger jag in en webpart i projektet och kodar någon funktionalitet i den. När jag sedan deployar min webpartsolution, så hamnar själva wsp:n på filsystemet i en solutionsfolder, och inne i SharePoint finns den med i det nya Galleriet för solutions.

När jag sedan smackar in min webpart på en webpartsida (eller en icke-webpartsida, för det kan man också göra nu) så är det i själva verket inte min webpart som ligger där, utan en proxy som kommer kommunicera med den webpartkod som exekverar i sandboxen.

Webpartkoden ligger alltså i en dll på filsystemet som sandboxprocessen kan komma åt, den objektmodell-kod min webpart använder då den kör i sandboxen är inte den fulla objektmodellen heller, utan en strypt version som visserligen innehåller alla objekt, metoder och properties, men som kastar exceptions om man försöker göra nåt otillåtet (som nåt med SPSecurity t.ex.). Det är alltså en runtimegrej, jag kan koda saker som är sandbox no-no:s i min webpart och få den att kompilera även om min solution är märkt som sandboxed. Jag tror att de försökt i VS att strypa ner intellisense för sandboxed solutions så att man får nån slags indikation på att en RunWithElevatedPrivileges t.ex. inte ‘finns’ i sandbox-kontext.

Jaha, men vadå? Ingen kommer ju använda sandboxed solutions om priset är att man är begränsad i vad man kan göra till att bara kunna jobba mot sharepointobjekt (som den anropande användaren har permissions på) från SPSite-nivå och neråt?

Jo, det finns en poäng till – monitorering. Sandboxed solutions kan monitoreras och det går att se vad de tar upp i fråga om serverresurser, så det går att tilldela quotas av serverresurser till olika solutions och sätta regler där en solution kan blockas om den kommer upp i ett visst antal poäng, (en poäng kan t.ex. ges för att ens kod inte hanterar ett kastat exception).

Jag har inte riktigt bestämt mig vad jag tycker än, man ska ju se vilken overhead sandbox-lagret ger och så också. Men jag tror helt klart att Sandboxed solutions kommer vara ett hett diskussionsämne när 2010 börjar spridas.

I övrigt är det ganska likt BDC, man kan koppla in SQL, webservices eller nån objektkälla. Mycket användbart verktyg, alla vill väl se sitt businessdata i SharePoint?

I nästa steg kan man öppna filen i SPD (SharePoint Designer / Destroyer) och bygga klart ett fungerade workflow, reusable eller listinstansspecifikt. När flödet är klart för deploy så kan man välja att ticka i ‘visualize workflow on status page’. Det innebär att man, om man dessutom aktiverar Visio Web-featuren i sin SharePoint, kan gå in på statussidan för en workflowinstans och grafiskt se vilka actions som är utförda, och vilka som är kvar.

Att arbeta med workflows i Visual Studio är inte något man kommer sluta göra. När det gäller svårare scenarion så kan det fortfarande behövas custom actions. Ett exempel på ett sådant scenario kan vara att man i ett arbetsflöde behöver anropa ett externt system och få ett svar, kanske lägga en order på någon vara.

Detta kommer framgent gå att lösa genom att använda sig av EDE (External Data Exchange). Workflow-runtimen kan då persistera ner workflowinstansen då anropet till det externa systemet gjorts, och sedan väcka upp det igen då det vid någon tidpunkt i framtiden kommer ett svar på anropet.

En lite udda nyhet (tycker jag) är workfloweventreceivers. Det kommer alltså avfyras events i samband med att workflows startar och stoppar. Då kommer man kunna skriva eventreceivers som triggar på dessa event. Så det blir på något sätt kod som körs i samband med en action i ett arbetsflöde, men den koden ligger utanför flödet. Nåja, det är ett nytt verktyg iaf, man behöver ju inte använda det. Kankse kan det vara användbart för att reagera på när arbetsflöden man inte skrivit själv drar igång.

I korthet handlar det om att man skickar in en xml-fraga till den tjansten och far tillbaka ett json-svar. For att fa till den dar xml:en att skicka till servicen sa har det tillkommit tre klientobjektmodeller, en for managed code, en for javascript och en for Silverlight. Att jobba med klientobjekten ar lite annorlunda an att jobba med server-Sharepointkod, dels sa heter objekten inte samma sak, och dels sa kan man jobba i scope upp till sitecollectionniva enbart.

Namngrejen funkar sa att SP ar borta ur objektnamnen, sa att SPSite blir Site, SPList blir List osv., annars ska det vara sa att objekten ska ga att kanna igen vad galler namn pa properties osv.

Nar man jobbar fran klientsidan sa ar tillvagagangssattet lite annorlunda ocksa, man definierar sina objekt, men de blir forst anvandbara efter att de laddats (genom att man kallar Load pa dem). Nar man laddar objekten kan man valja att enbart ladda det man vill arbeta med. Sa om man t.ex. vill byta Titel pa ett antal ListItems sa kan man, t.ex. m.h.a. lite stilig lambdanotation, valja ut att bara ladda titel for varje item och inte itemets 50-60 andra kolumner.

Stod for stora listor ar en annan nyhet. 50M items per lista ska man kunna ha nu. Det finns throttlingmojligheter som ger olika anvandare med olika behorigheter olika mojligheter att hamta items. Defaultinstallningarna ger en reader mojlighet att genom en query fa ut max 5000 items och en poweruser ska kunna fa ut 20000.

LINQ to SharePoint ar ocksa nytt, och ar ocksa en sak som i vissa avseenden ersatter CAML, kompletterar ar kanske ett battre ord. I vilket fall som helst handlar det om att mna kan stalla LINQ-fragor mot SharePointlistor. Eller snarare stalla fragor mot entities som skapas utifran listor/content types. For att skapa entityobjekt finns ett tool som heter SPMetal, det bygger dock pa att man deployar sin listdefinition och gor en lista av den i en site, sedan kan man kora SPMetal for att fa ut C#-kod. Om man tittar pa de genererade objekten sa ser det dock ut som om det inte ska vara sa svart att gora en visual studioplugin som skapar entities fran listdefinitioner, nagon kommer sakert bygga ett sadant.

Det började med en high level-presentation av vad som är nytt med SharePoint 2010. Ganska mycket samma saker man sett några gånger i sneek peek-videos och sessions från SPC09.

Sessionen efter det behandlade developer roadmap, det var också något av en översikt, men den här gången över vad som är nytt för utvecklare. I den efterföljande labben fick vi också känna på det nya gränssnittet, det s.k. UI v4 (det interface som finns i innevarande sharepointversion kallas UI v3), med server ribbons och ajaxiga kontroller. Vi skrev lite kod för att slå på developer dashboard på en webpartsida också, och så blev det lite powershell. Mycket av administrationen av SharePoint är ju tänkt att skötas i powershell istället för med stsadm.

Efter lunch blev det en titt på SPT, det är ytterligare en ny förkortning som står för SharePoint Tools, de som kommer med Visual Studio 2010 alltså. Något jag tyckte var mycket intressant med dem var hur det är tänkt att man ska deploya SharePoint-projekt. Server-explorern med SharePoint connections var intressant också, i den kan man browsa sina siter från VS. Den kan inte riktigt lika mycket som SharePoint Manager (jag såg inga propertyobjekt), men det kan ju tänkas att det kommer till innan release, annars kommer säkert nån annan bygga till det.

Det är nog lagom för en postning, men det kommer mera….