Dead Sharepoint

I lost my sharepoint portal, again. I got some dreaded another user is editing the list (or is it deleted the list) which also manifests itself in deleting 20 out of the 27 available web parts. It also manifests itself in the Area not found message and value cannot be null page.

I deleted my portal , recreated it, oh oh can’t rebuild my portal.

So yet again Im uninstalling SPS/WSS and creating anew.

Wierd Control / Customizing Sharepoint

SPSWC:CollaborationServerMetaTag

Watch out for the above control, it appears on the SPS (home page) area template but not on the others.

On our customization of the area templates this tag had been inadvertantly removed.

Bad things started to happen, especially with my replacement content editor web part, this used the WSPC save properties capability, it worked every where but the home page. It used to work on the old home page. Sure enough replace the page it works.

That control is the culprit and like so many other things in sharepoint no documentation on what it is, why it is, or how to use it.

Thanks again MS.

Ok Ok Google are great (Satellite Maps on Google Maps)

I take it all back, give google their due.  They must have seen “world wind”, which is also fantastic, and thought we could do that in maps.

Yes Google have satellite imagery on maps now, it uses the same ajax techniques to awesome effect due to, what worldwind calls the USGS urban maps.

Now if they could just apply mipmapping at various levels of magnification to smooth out the transisition and mix land sat 7 pictures with urban ortho.

Great work.

 

How to get the Current SPS Area

Nice little code snippet to determine current SPS area

http://weblogs.asp.net/avnerk/archive/2004/09/14/229033.aspx

 

Preconfigure a Web Parts Height or other property (including custom ones) for deployment (continued)

In my work to create a WebPartBase, that will Skin a webpart and control its ContextSecurity (ie disallow its use in WSS or SPS or allow only on Specific Area) I discovered that the inherited properties for DefaultHeight (the method I previously used to auto configure the Height property) no longer worked.  After a bit of fiddling it made sense as my webpartbases Xml root was not the same as the inherited class.  Once I changed my DWP to reflect the XML root of the WebPartBase, it sprang into life.

Then sudden realisation, well this will be the same for the MS webpart class. So a bit of reflector and I find MS XmlRoot and try the Height attribute in my DWP.

<Height xmlns=”http://schemas.microsoft.com/WebPart/v2″>100<Height>

Hurrah !!!!!!

This should work for any of the inbuilt base settings, (provided they take strings) other types have given me problems on my own default settings.

Now no longer do I need my proxy property to acheive this.

You know sometimes this Sharepoint stuff makes sense.