I'm looking into using SharePoint (WSS 3.0, specifically) for the document library and discussion board functionalities.
I'd like to ask those of you who have experience in SP (MOSS or WSS, since we might upgrade in the future) for a list of the items that ticked you off or required a difficult workaround.
Here's one from me - I found when I implemented forms authentication that a lot of the built-in integration with Microsoft Office disappeared, and I was also unable to use explorer view.
As long as you are in Internet Explorer, a lot of the built-in stuff will work flawlessly.
I think it's a great product but my only "complaint" is that when you try to customize the hell out of it, you need to learn the API properly before doing things right.
So beside the learning curves, I think that WSS 3.0 is great at what it is doing. If you need more than WSS, SharePoint's licence is not for the "Personal" user. Quite expensive.
If you try to customize the layout and color of the sharepoint websites this can be a nightmare.
I also found troubleshooting difficult. There are different logfiles to search for the error, and it's never clear where to look.
Troubleshooting can be 'interesting'. A resource I've found useful is SharePoint Debugging and Logging Tips and Tricks. Also, this MSDN article, Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 contains some great info.
It's extremely Windows-centric. If you have any developers who like Firefox, or the Mac, or if you ever want to get those kind of developers, then Sharepoint will be a big problem. Also, its "wiki" is hardly a wiki at all: it's as if some marketing guy said, "I hear wikis are big, can we do that?", and they labeled an HTML editor "wiki".
In general, Sharepoint is good if you are a completely Windows shop, and like looking at documents as if they were stored on your disk (folder-heavy, list views). If you want to experience information management the way the rest of the software community does, Sharepoint will be a hindrance.
I'm not even sure where to start:
As we are forced to use this for documentation over the previous system, CVS, which was vastly superior in every respect (despite CVS's own problems), I find all of these extremely annoying.
I'd also like to voice my displeasure at trying to customise the stylesheets etc.
We use Sharepoint as our development wiki and trying to skin this involved extreme hackery.
Also not being able to replace the "HTML" editor (and I use the phrase loosely as it is a memo) in the wiki is frustrating.
As this is a Developers Site, let's talk development:
And one not development related issue:
Microsoft calls Sharepoint "A maturing Product", which essentially means: It does do a LOT of things really well on the end-user side, but on the Developer and Sysadmin side, I think I have thrown more profanity at Microsoft than on any other company in history... And given the fact that Sharepoint is so expensive, I had expected a bit more from a product that first launched in 2001...
But overall, I think I'm happy with it, because as long as you use Internet Explorer and Office 2007, it offers a really neat and tight integration.
SharePoint is a big server product, but it is marketed like a tool you can just install and use.
It really requires people to manage it who really know the system and more than one person.
It needs informed server/hardware management to make sure that it is installed correctly and the underlying server and databases will run correctly.
It requires people who know SharePoint well so they will be able to avoid the pain described by people here (and elsewhere), not only for customising the look and feel, but even simple seeming customisations to functionality can end up being complicated.
On top of that, there are still very few people available with the knowledge of the product.
The upshot is that any first time install is going to have problems while people learn "SharePoint". Plan for server rebuilds and lots of learning time on your project , (then double it)?.
The discussion boards are rubbish. The community kit for sharepoint has an improved install for Discussion boards and I would reccomend installing this and evaluating against requirements.
The document storage of SharePoint is great, but there is some serious work needed to do outside of SharePoint in the management of document growth and organisation or SharePoint will rapidly devolve into a massive cluster f&*%.
http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx
It really requires people to manage it who really know the system and more than one person.
It requires people who know SharePoint well so they will be able to avoid the pain described by people here (and elsewhere), not only for customising the look and feel, but even simple seeming customisations to functionality can end up being complicated.
Nat brings up great points which need to be heard by many.
I've found that the best way to deploy an application in sharepoint is to adapt sharepoint to your needs and not to adapt your application to sharepoint. The second will lead to headaches and customization difficulties.
They use tables all over for layout, but not consistently. The 508 accessibility is not good.
Late to the party here, but one small, simple thing that makes life with Sharepoint harder is the fact that Microsoft have decided to use terminology for things in Sharepoint based on really common words that mean other things in the rest of the world. So for example, if you want to create a custom add-on for Sharepoint it is a "Feature", forms and customised list entries are "Content Types" and so on. Once you get your head around it that's not too bad when you're working with Sharepoint, but the minute you need to put it into google, searching for "features" or "content types" is going to get you loads of stuff that has nothing to do with Sharepoint and quite possibly a bunch of stuff that is to do with Sharepoint but isn't to do with the context you are looking for.
I'm sure they were trying to be user friendly with that, and for some kinds of user maybe they succeed, but for anybody who ever needs to use a search engine it's a pretty irritating fail.
EDIT: And another thing: Why are the form elements mostly given guids for names? That is really annoying if you need to add any extra Javascript for whatever reason...
My first real exposure to Sharepoint was in a training session at a Microsoft building. Having did a view source and seeing nested tables to the nth power, I later tried to be diplomatic in asking one of the Microsoft employees, "How is it for disabilities?"
"If you mean like screen readers, it SUCKS" was his answer.
Sharepoint has incredible capabilities, though. Oh, wait, I mean it's documentation promises incredible capabilities.
I'd be much happier with only half of the features if they all actually worked.
The overriding problem is that Microsoft seemed to care more about the marketing of SharePoint that it's use. They knew they couldn't make SharePoint do everything well so they decided to make it do everything 1/2 assed. Wikis, Blogs, Language support with variations sound great - until you actually try to use them.
Alot of things are just too buggy or simply don’t work well enough out of the box. To get a content query web part to recognize a list of links, I have to export it to my machine, change some property I can only see in the xml, re-import it and drag it onto the page? SharePoint is complicated enough and already destined for complexity, but because it was shipped before it was QAed in any kind of real use scenario it's far too easy to just explode into a useless mess.
Another overriding problem with SharePoint is getting data out of it. To aggregate data from SharePoint sites I either have to use a bizarre xslt model with content query web parts or list my sources individually with an kludgey data view web part. The architecture around content types is great, if they are actually implemented properly, but I wish I could use that data more easily. Starting to think that maybe I should auto generate sql views on the backend...
Of course the development model. I have to develop on a server? Really?
I just wish Microsoft would have focused more on the core of the product, QAed it properly, and given everyone a solid foundation to work on with good documentation. Maybe they could have partnered with 3rd parties to get all the little bells an whistles in this version if they felt they had to. I sincerely hope that MS does not continue to plop on use-less features in the next version and instead tries to firm up the foundation. It's not just the product that suffers, it's the legecy of messy implemenation that get created.
SharePoint is very promising and I hope it does become the shinning hub of Microsofts app platform, but It will have to become alot clearer and cleaner before it does.
Dealing with Sharepoint since STS days and the following have been gotchas for us:
Perhaps most importantly: If you don't put some structure to your site(s) up front, and guidance for your users then anarchy rules. Files can end up anywhere and in any site. Compound this with the ability to create sites from Office, meeting workspaces from Outlook and soon you have a site map from hell. And Sharepoint can't generate a decent site map so you've no idea how bad things are getting.
Still, if you're in a corp environment and want to move up the food chain, you can do far worse than get involved with Sharepoint.
Like others have said, the development experience is a complete nightmare. Expect any development to take 3 times as long as similar ASP.NET dev.
That being said, I think it works well for information storage in a corp environment. Unfortunately, my experience is that no one ever wants to use it just for that. In fact, most people expect it to be like developing for any regular ASP.NET site and will ask developers to make it do crazy things it was never intended for (and the MS marketing team seems to push this too, which doesn't help).
Microsoft.
I'm not an anti-Microsoft guy, but really I think that "Microsoft" in this case sums it up for me. If you're going to use Sharepoint, then you're locked in to the Microsoft way. You'll be running a Windows Server, accessing it with Internet Explorer and Microsoft Office, and developing with Microsoft-specific non-free tools.
For a "portal" type solution, I would prefer to work on something that is sensibly managed using standard, widely available tools (and have a wide choice of tools). I prefer working on Unix-based servers. I prefer being able dig into configurations in text files for those times when "standard installations" or "standard upgrades" go south. I prefer knowing where everything is installed and what the dependencies are. I prefer being able to choose the database that I'd like to run. I like being able to setup test machines without worrying about licenses.
That said, I have yet to see a solution that provides as much as Sharepoint, as simply as Sharepoint, and as cheaply as Sharepoint... especially in a Windows environment.
I work full-time with SharePoint, and here's what I run into the most:
Addendum:
Also, a lot of development issues have been resolved in SP2010, but I haven't worked with it enough to figure out what is working now.
I agree with a lot of the other users here have mentioned. One thing I might add is the poor performance of lists that contain many items. We once managed to get three million items into a single list, but after that happened it was impossible to clear those items or delete the list from the web GUI and from the SharePoint API. We managed to get rid of the list by applying batch CAML (yuck!) delete queries to the list.
Oh, and another major complaint that a lot of my customers have: SharePoint Search doesn't support wildcard (i.e. substring) search in the out-of-the-box Search Centers. This means that if you look for the word "share" it will not find "sharepoint". You have to rely on third-party software or code something yourself to fix this.
Considering the fact that SharePoint is positioned by Microsoft as a strong (enterprise) search solution this is a major shortcoming.
Sharepoint suffers from performance issues. Other portal solutions do a lot more with less impact on the user. How often does iGoogle reload the page? It's not nearly as often as when configuring Sharepoint web part pages.
Searching and indexing is a little bit unmature. Noone can explain why indexing takes so much time
Lack of transaction support, referential integrity... a lot of things are just to complex to manage...
In short, Sharepoint's HTML is not W3C compliant, and this is a BIG hindrance when you start customizing the UI. It is extremely difficult to apply any type of sophisticated CSS as there is an overuse of HTML tables for the web parts. Also, there are very limited use of DIV's. Fire up Firebug and inspect a web part - all you see are nested tables, with no footers so good luck applying rounded corners to the top AND bottom of the web part.
Another BIG short coming is all the inline javascript, and this makes it hard to determine when the DOM is ready for manipulating.
If you have customer base like we do, you find that want to introduce a Web 2.0 interface, and you can integrate jQuery into the frame work. This takes a lot of effort, but it's worth it when you get it working. My team found the jQuery articles at EndUserSharpoint to be key for us gaining control of the DOM.
Sharepoint doesn´t think about some internet Connections. It´s hard to load the pages and it´s a challenge to deal with performance in the plataform!
We have a Customer that always asks the consulting firm about the performance and how slow is the front page.
I hope Sharepoint 10 can deals better with this Slow mode on!
tks ernesto
After considering all the various issues mentioned in the specifics, I guess I'd summarize it by saying that the biggest problem is that you end up working on SharePoint instead of working on the problem you're trying to solve.
Just plus nuances:
My inner-question was always as SPS developer: why so much for SPS marketing, and why so little for SPS development?
My biggest complaint is the development experience as a whole. Everything from setting up a development environment to deploying customizations to simple tasks like trying to customize the styles. To sum things up, developing anything for Sharepoint will take 3x as long as will end in failure.
sealed (enough said, and yes, I know the source is available, but still, how do you stuff that one up!)IMHO sharepoint is a good idea ruined by an awful implementation, but I can't say I've noticed sharepoint developers are any stranger than the rest of us.
well there's many reasons but here are the most common I hear about.
Sharepoint is very restrictive. You have to work within a very specific set of confines which can make trivial tasks seem impossible at times.
Working with the security model is complex. It's an enterprise security model with enterprise complexity.
You're essentially working within a hosted environment which can vary greatly from production to test to development. You need to make sure your development environment resembles exactly the production environment or you're going to have pain.
There are so many extra steps to setup, administer, configure and deploy your sharepoint code. It's not easy to automate builds and it's also hard to replicate settings across multiple environments.
I'm no expert in SharePoint but my guess is that 1) it is very unopinionated and 2) sets extremely high expectations amongst business stakeholders.
Edit: after an additional 18 months of leading one of the largest Sharepoint WCM deployments in the world, are these reflections still true? Yes.
I can't speak for all developers, only myself (but I suspect I'm not the only one). I have been working deep down in the EWCM side of Sharepoint/MOSS for about two 3.5 years now, and it has been the most wholly unpleasant of my career from a technical standpoint. I love my job, my company, my coworkers, my environment but the platform is a nightmare.
I struggle to fully articulate objective reasons why this is the case, but ultimately it's just not rewarding. Most of the time we developers tackle a problem and get satisfaction out of mastering the system. However, the more I learn about Sharepoint and the more I feel I've "mastered" it, the more I wish I didn't know anything about it. (Whether it can actually be mastered is another discussion altogether).
It's fun and easy to knock the product as crap, but I don't know the people who wrote it or why they designed it the way they did, and they may have had good reasons. It is a solid document sharing/collaboration platform. However, Microsoft has tried to make it so much more than just that. At an architecture astronaut level, it might seem like the fundamental patterns of a document management system are also the good basis for things like, say, an enterprise web content management system - so they built that on top of it. But in practice that may not be the case, and indeed there is a good bit of friction trying to force an EWCM paradigm to fit the Sharepoint model.
Sharepoint is touted as an application platform, but its usefulness ends at making very simple, basic web-part-widgets that get dropped on to a page. If you need to do deep, core application development using Sharepoint and MOSS as the foundation, it is extremely painful.
It was also shipped prematurely. Important things like application lifecycle management, maintenance and enhancements for systems built on top of Sharepoint seem to be afterthoughts at best. Nothing was built with post-deployment changes in mind. It also breaks some really useful things that come out of the box in ASP.NET, like donut caching.
Tools support is only now starting to catch up. Visual Studio 2010 will have some nice tools for Sharepoint development, but that means the community has spent more than 3 years hand-tweaking hundreds of overly sensitive XML fragments and using the command line for complex deployment work.
Architecturally, the system is extremely fragile. It's a black box, with many moving parts which are clearly loosely coupled, but the precise nature of the interactions between various subsystems is opaque at best, and it is alarmingly easy to take a MOSS site down. A bit anecdotal, but out of the maybe few dozen production deployments we have done so far, something different has gone wrong inside MOSS every time. A timer job fails to kick off, one of the servers in the farm doesn't get all the right files, the content database gets locked or worse.
I could go on and on (I might come back and add some more) but I think my point is clear - Sharepoint is great to pop straight out of the box and onto a server for collaboration and document management. Nothing else. The attempts to make it do more than that is precisely what has broken the souls of so many developers.
I have worked with SharePoint ever since the 2001 version (if you thought 2007 was bad, 2001 tops that easily).
I see developers struggle with SharePoint daily, it seems a lot of people have problems with the steep learning curve. Yes there is a lot to learn. If you know SQL and ASP.NET you are simply not there yet. It is hard for a single person to know 'everything' about SharePoint. It's a bit like the ads of companies that are looking for a PHP developer that knows ASP.NET very well, masters Flash, Photoshop and can talk to clients about requirements. Unlikely.
Community support for SharePoint has been high; there are loads of community sites, people creating tools, add-ons, etc. Someone mentioned terminology, type in "SharePoint searchterm" in google and you rarely miss, even if your searchterm is something generic such as "page" or "content type". Uptake with companies seems equally high, many use it as their Intranet platform and not only the small ones.
I for one like working with SharePoint. I would not want to go back to building Intranets or document management type applications from scratch. Yes you have to have some infrastructure in place; a Windows Server to develop on. Still I can do 'create webpart' in Visual Studio, choose 'deploy' in Visual Studio and be looking at my code rendering on a SharePoint page 2 minutes later. I won't say getting this set up is trivial but it is not that hard either. Also, WSS is free (if you have Windows Server).
If do have a question.. I'll admit to being very biased towards Microsoft & SharePoint because thats what pays my bills but what would the alternative be? (There is no single answer to this question because SharePoint can be used in many ways, I know.. still wondering though)
Lots of people complain about the fact that you have to develop on a SharePoint server within the farm (unless using SP or custom web services.)
But SharePoint is an ASP.Net framework. If you were developing a stand alone ASP.Net site you would also have to develop it on an ASP.Net server (it would just be your local machine), there is nothing stopping you from installing SP on your own VM and developing your solutions there. The only limitation on developing on your desktop machine is the OS (this is a server based product after all.)
That it's quirky and its quirks are badly documented. For example, editing a web.config file locally with SPD was a logical enough thing to want to do, until I discovered it had covertly created a ton of folders to stay frontpage-compatible, without telling me (I found a tip in big, bold letters in a SP book - Professional Sharepoint Development, I think, along these lines - "Don't, whatever you do, use SPD locally, but only remotely via http!!!"
And secondly, when deploying a workflow .dll with SPD, if you leave SPD open, it will cunningly cache the .dll by renaming it, so what you think you just deployed to the GAC, is not actually what the SP is using.
If you want to debug SharePoint errors, then you're going to need Windbg since all you'll usually get is 'An unexpected error occurred' or something useless like that.
Cheers. Jas.
The most frustrating thing so far for me having not customised the sites much is the idea that i attach an AD group to a Sharepoint group and yet the AD group is listed as a Sharepoint group in sharepoint.... I dont want to see hundreds of AD groups in sharepoint, just the groups that are directly associated to the sites... it just makes life complex when browsing the site groups... pian in the arse....
What gets me most are the whiners. This product is powerful and flexible enough to pretty much achieve anything you could ask for in the enterprise collaboration/CMS arena. Developers just have to get their heads around the fact that there is a relatively steep learning curve involved. But that's what we get paid for, right? ;-)
SharePoint is full of love, the kind of love that hurts.
1) SharePoint's calculated columns would have been a great idea if Microsoft had allowed us to extend/add functions. For some reason though you get limited to a small subset of Excel functions.
For example, to replace 0 to 4 spaces in a calculated column we had to write something like this. Not only that, but the level of nested calls is limited to 8 making it quite difficult to avoid complexities.
=IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))))
2) Importing and Exporting sites containing WorkFlows is a mission because items attached to workflows will not persist this information after importing. (EDIT isue may have been fixed with the latest service pack)
3) You can't do joins with CAML. CAML itself is a big limitation.
4) You can't use a lookup column or a people column in a calculated column.
Where to start. Guys if you're out there holding your heads, and nearly crying in frustration, you're not alone. I've worked with a department of SharePoint developers, and I've never seen a product stab moral like SharePoint.
here are my observations
But the worst thing with MOSS is that there is an unwritten rule only to ever query MOSS through its terrible CAML or web service methods. So any junior who might think it would be a good idea to write some ADO.net to get list items or any other sharepoint object - will get shot down!
I really hope 2010 takes the MOSS out of MOSS. Its the only technology I truly despise.
SharePoint has only one absolute truth.
"If something works on the Framework, DOES NOT means it will work inside SharePoint."
Living by that you won't end up making tests/implementations outside SharePoint with the "Then I'll just copy the code inside that webpart" mindset.
I cannot stress this idea enough, get a good development environment, talk smoothly to your CAS restrictions, understand the impersonations done inside the 12 folder (14 in 2010) and know beforehand that the API probably HAS that one method you need but they ensured it was marked as internal just to test your reflection skills. (GetListByName() being the best example I have in mind).
SharePoint needs a Windows 7 take for the future. Redone from the ground up, no unmanaged STS COM to talk to the database and better structure in the todays homebrew Object Model/API.
Perhaps to illustrate SharePoint 2007 frustration when it comes to customizing its look..
<table>
<table>
<table>
<table>
<table>
Hello, SharePoint!
</table>
</table>
</table>
</table>
</table>
Luckily, Microsoft has heard/learned and 2010 will be full of enjoyable divs...
It versions files, but doesn't make comparing versions easy. Even text files or Word files that you figure Microsoft can handle. You can't (as far as I know) revert unchanged files.
It is just incredibly complex, compared to what it achieves (compare to N2 CMS for example).
And who came up with the idea that in order to derive a content type from another, you assign the id to be <id of parent>00<new id>? I really hope that person is not working on anything I will have to touch again.
I was going to keep a running list of grievances in a Word document but I'll just do it here instead. Not evening touching on the user experience aspect of it, here are just a few of the infuriating issues that you WILL encounter if you touch the API:
UserList.Contains(user).ParserEnabled with, guess what... little to no documentation.item["fieldName"]? Nope. Try item[item.Fields.GetFieldByInternalName("internalName").Id].Hidden, Title, etc, which are common across many SharePoint classes are NOT encapsulated within an interface, but are instead declared separately in each class. So if you want to do something like show all hidden stuff on a SharePoint site, well you have to cast everything separately.I did some research into the history of SharePoint in order to understand why it is what it is, and stumbled upon some gems:
All of this leads to the following conclusion: SharePoint is the frankenstein progeny of FrontPage Server Extensions, plain and simple. That's why its API stinks so badly and why it has a host of nasty COM objects at its core. I would even wager a guess that large blocks of code at the heart of the SP code base are the original ones that Microsoft stole... er, acquired from Vermeer. In other words, it is likely that parts of SharePoint are over 16 years old! No wonder those error messages are so cryptic. This is technology from 1995! Its roots are plain for all to see: vti = "Vermeer Technologies Inc". When I came to this revelation I didn't know whether to laugh or cry.