Endelig en god artikkel om OpenWeb() sin inkonsistente oppførsel
Dette er en issue jeg har brukt enormt lang tid på å finne ut av tidligere.
På bloggen til Waldek har jeg funnet kanskje den mest forklarende og ikke minst oppklarende gjennomgangen av dette.
Ikke kast bort tid, sjekk hele posten her:
http://blog.mastykarz.nl/inconvenient-opening-spsite-openweb/
En fabelaktiv SharePoint blog
Kom akkurat over en helt fabelaktiv SharePoint blog, hvor SharePoint MVP Waldek Mastykarz har blogget om enormt mange nyttige metoder og triks.
Hvordan få tak i SharePoint WebPart Property Attributes i en usercontrol
Jeg pleier å lage usercontrols når jeg utvikler i SharePoint, som ofte gir et lite fleksibelt resultat.
Noe av styrken til webparts er jo at man kan definere attributter og dermed lage de (realtivt) generelle og benytte seg av innebygget funksjonalitet (f.eks. Personalisering).
Ved å legge selve logikken ut i en usercontrol tenker mange at man da går glipp av all denne funksjonaliteten, men det er ganske feil.
Ved å definere opp variabler i usercontrolen, som mottar WebPartens attributter går det hele veldig pent for seg.
Et lite eksempel:
public override void CreateChildControls()
{
base.CreateChildControls();
UserControl uc = (UserControl)Page.LoadControl(@”/UserControl/testUC.ascx”);
uc.testValue = “Bananas”; //Her henter du webparten sine attributter.
Controls.Add(uc);
}
Inne i usercontrolen må du da legge til:
public string TestValue
SharePoint WebPart Property Attributes
Fant en god artikkel om hvordan man bruker atributter i SharePoint webparts, så webpartene kan utvikles mer generelt.
Posten (som jeg har hentet fra http://joeshepherd.spaces.live.com/blog/cns!9AE2097A4A610B63!302.entry) har jeg kopiert hit, så jeg har den i “arkivet”.
I wanted to put this information out there because it was not well published when I was building WebParts for the first time. When you build a WebPart in MOSS 2007 you have the ability to expose the public properties of the WebPart in the editor pane of the WebPart page. This allows you to set some administrative values for the WebPart behind the scenes. In order to make this happen you have to tag the property as being Web Browsable. Unfortunately most of the documentation only gives information on the WebBrowsable and Personalizable attributes. However there are a few others that you might find valuable to know about. Some of the other attributes are listed below along with explanations and links to further resources.
WebBrowsable [WebBrowsable(True)]
“Indicates whether the designated property of a Web Parts control is displayed in a PropertyGridEditorPart object.” (MSDN) http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.webbrowsableattribute.aspx
WebPartStorage [WebPartStorage(Storage.Personal)]
This attribute specifies what type of storage options the WebPart will make use of. The most common is Storage.Personal. “This property can be personalized by individual users. Its WebPartStorageAttribute value is Storage.Personal, which specifies that the property can be stored on a per-user basis. Only users with the Personalize Web Part pages right can set this property.” (MSDN) http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpartstorageattribute.aspx
Personalizable [Personalizable(true)]
Allows users the ability to personalize settings for the WebPart. http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.personalizableattribute.aspx
WebDispayName [WebDisplayName(string)]
Defines the Friendly Name for a property of a WebPart control. This is the name that will show up in the editor screen. http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.webdisplaynameattribute.aspx
WebDescription [WebDescription(string)]
Defines the string value to use as a ToolTip for a property of a Web Parts control. (MSDN) http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.webdescriptionattribute.aspx
SPWebCategoryName [SPWebCategoryName(string)]
Defines the friendly or localized name of the category of a property in the CustomPropertyToolPartcontrol inside the ToolPane. http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.spwebcategorynameattribute.aspx
ConnectionProvider [ConnectionProvider(string)]
Identifies the callback method in a server control acting as the provider in a Web Parts connection, and enables developers to specify details about the provider’s connection point. (MSDN) This is used to create connectable WebParts. http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.connectionproviderattribute.aspx
ConnectionConsumer [ConnectionConsumer(string)]
Identifies the callback method in a server control acting as the consumer in a Web Parts connection, and enables developers to specify details about the consumer’s connection point. (MSDN) This is used to create connectable WebParts. http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.connectionconsumerattribute.aspx
Below is an example of how to use these attributes in your WebPart code.
[WebBrowsable(true),
Personalizable(false),
WebPartStorage(Storage.Personal),
WebDisplayName("User Name(Domain\\username)"),
WebDescription("User to display in the WebPart."),
SPWebCategoryName("Options")]
public string UserLoginName
{
get { return _loginName; }
set { _loginName = value; }
}
Happy coding!
Individuell Page.Cache variabel
Et artig eksempel på bruk av Page.Cache
Problemet mitt er som følger:
Brukerne skal fylle ut et skjema. Skjemaet er bygget opp så legger til og fjerner rader fra et dataset. For hver rad som legges til /slettes eller endres må datasettet oppdateres. So far so good. Utfordringen kommer ved at jeg ikke kan lagre datasettet i basen for hver av disse operasjonene. Mitt dataset ligger derfor lagret i Page.cache. Dette fungerer helt fint, til det kommer flere brukere inn på siden som gjør dette samtidig. (Da vil begge brukerne dele på datasettet.)
For å komme rundt dette, har jeg laget et prefix, som er unikt for brukeren (BrukerID eller noe slikt), som jeg har lagert i en cookie. Denne prefixen bruker jeg så når jeg skal lagre og hente data fra Page.cache.
C# eks:
Page.Cache[getUserPrefix + "Dataset"] = myDataSet;
og
myDataSet = (DataSet)Page.Cache[getUserPrefix + "Dataset"];
public string getUserPrefix()
{
string retVal = “”;
if(this.Page.Request.Cookies["CookieNavn"] != null && this.Page.Request.Cookies["CookieNavn"].HasKeys)
{
if(this.Page.Request.Cookies["CookieNavn"]["UserPrefix"] != null)
{
retVal = this.Page.Request.Cookies["CookieNavn"]["UserPrefix"].ToString();
}
}
return retVal;
}
Sharepoint 2007 Form Based Authentication
Fant en virkelig god oversikt over hvordan man kan implementere og feilsøke flere forskjellige authentication providers som både kommer som standard i windows, men også endel andre. Deriblandt ADSF.
http://blogs.msdn.com/harsh/archive/2007/01/10/forms-based-authentication-in-moss.aspx
Update et liste element uten å lage ny versjon
Normalt er versjonshåntering og historikk et stort salgsargument for å ta i bruk SharePoint, men det er ikke alltid man ønsker å lage en ny versjon av et element i en liste.
Normalt sett bruker jeg følgende kode for å oppdatere og å lage en ny versjon av liste elementet:
SPList list = web.Lists["myList"];
SPListItem item = list.Items[0];
item["myField"] = “my value”;
item.Update();
list.Update();
Men nå skulle oppdatere et element uten å lage en ny versjon, ble jeg litt svar skyldig.
Etter litt frem og tilbake på msdn, fant jeg frem til en nydelig funksjon som er tilgjengelig på liste elementet i SharePoint.
SPList list = web.Lists["myList"];
SPListItem item = list.Items[0];
item["myField"] = “my value”;
item.SystemUpdate(false);
list.Update();
Ved å bruke SystemUpdate funksjonen oppdaterer ikke SharePoint liste elementet sine Modified felter (Modified, Modified by osv.) ved å sende inn false, som argument til funksjonen. Som standard sendes det inn true, og da opprettes det nye versjoner av elementet.
Det eneste som deretter gjenstod var å redigere workflow’en slik at det nye elementet i listen automatisk godkjent for publisering.
Windows Server 2008 R2
Etter å ha installert Windows Server 2008 standard på min lokale laptop (En Dell Latitude D830) og virkelig elsket det, måtte jeg bare oppgradere til Windows Server 2008 R2. Det er ingen hemmelighet at det egentlig er Windows 7 Server, men du og du så deilig operativsystem dette er.
Nå bruker jeg mindre ressurser, har mer kraft igjen på maskinen selv når jeg kjører 2 sql server instanser, sharepoint server, enterprise search og en hel masse annet. Nå går det faktisk ann å arbeide i tillegg. Nå skal det sies at jeg kjører 64-bit utgaven, men jeg kommer ikke til å gå tilbake.
Hvis du skulle ha lyst til å prøve (noe jeg absolutt anbefaler) så følg denne veiledningen her. Om du velger Windows 2008 server eller r2 spiller ingen rolle. Personlig har jeg blitt helt frelst av R2.
Ny jobb, nye muligheter
Da har jeg begynt å jobbe med litt tyngre saker. Jeg har begynt i Microsoft avdelingen hos Affecto som er et av nordens største selskaper innenfor datavarehus og business intelligence.
Det er både litt sørgmodig å forlate “medie” verdenen, men jeg er først og fremst utvikler og gleder meg til å endelig kunne jobbe mer med teknologi og litt mindre media.
Og dersom du vurderer å bytte beite, så si gjerne ifra. Affecto trenger flere flinke folk.
Trening
