|
|
|
|
Sharing is Caring > Categories
|
4/01/2009
 Wow, talk about an unexpected, and humbling start to the new year!
Today I received the news that I'm a SharePoint Server MVP for 2009. I'm very honoured to be given this award alongside so many incredibly clever and devoted people, all of whom I have an infinite amount of respect and admiration for.
Thank you to all those in the community, the Christchurch and New Zealand SharePoint User Groups, and in Microsoft who have helped me in my journey to this point. I want to send a special thanks to Chan and OJ who have been incredibly supportive and helpful over the last couple of years, as well as to Darryl and Jonathan at Microsoft NZ, both of whom have been very supportive not only of the Christchurch SharePoint User Group but also of me personally, including the opportunity to speak at TechEd for the first time last year. Thanks so much also to Gary, my partner-in-crime at the C-SPUG.
I'm looking forward to continuing with, and also ramping up my contributions to the community this year. As I'll be out of New Zealand for at least 6 months, I'm going to have to do some of this in different ways to last year - but I have some exciting community projects to ramp up and look forward to speaking at user groups wherever possible. As I also mentioned in the pre-Christmas-post, I'm also looking forward to ramping up this blog with some in-depth content, so please stay tuned :)
I seem to be looking forward to a lot... but I'm also really looking forward to meeting new friends, as well as sharing a drink with a few old ones (watch out Bob and Ben!) at the MVP summit in March. Happy Times!
:) Matt 21/12/2008
Here's the last Week That Was before Christmas... exciting!
Before we get into it though, a few questions: do you find this valuable? Would you like me to continue this after one-blog-per-day-until-Christmas (this is #48) ends? If so, how would you like it improved? In the absence of any comments or e-mails, I will assume... "no", "no", and "don't bother"!
SharePoint Infrastructure and Platform
SharePoint Development and Customisation Tips and Techniques
Architecture, Planning, Design, and other Fluffy Stuff
- Adam posted on when best practices aren't really best practices. In short: best practices don't necessarily account for industry verticals, company culture, or teach the underlying process.
- Provide a Feedback Loop so that users can tell you what they need from a site. This article describes using the Site Contact Web Part, but any loop will do.
3rd Party and Community Tools, Solutions and Web Parts
Beyond SharePoint
:) Matt 20/12/2008
Day 46... hang in there, only a few craptastic posts left until Christmas!
The Problem
It's not so much a problem, but a common scenario that is just crying out for some out-of-the-box support. Often in our taxonomies and data models we have the need for a drop-down or choice list where the lookup values should, are, and will always be consistent across the organisation. For example, selection of a region, or specific office for a global organisation.
Now, this sort of field cries "Site Column", but in a server farm with more than a single site collection, this won't necessarily be satisfactory. Unless you use one of the "workarounds" below, you're forced to duplicate your lookup lists (or if you're naughty, choice field lists) in multiple places.
Possible Solution
Introducing Candidate One for your consideration... the Server Site Column. This puppy is defined in Central Administration and then available to every single site collection in the farm. This would definitely allow you to have a global Choice field... though lookups (which is what we really want, so we can get version control and other features around the lookup values) would be a little trickier. If Server Site Columns could lookup lists defined in Central Administration and this data would remain available (and perhaps even cached for performance) in each site collection, that would be super.
Candidate Two would be some sort of "Global Lookup" concept, whereby the columns would still be defined at each Site Collection, but would retrieve data from either "central choice lists" in Central Administration, or perhaps even via extending lookups to be capable of peeking across Site Collection boundaries. Either way, it would need to be simple for users to generate and then link in one of these globally managed lists.
Workarounds (For Now)
Here's just a few ways to achieve this:
- Build or buy a cross-site Lookup column capable of retrieving its data from a list in Central Administration.
- Build or buy a replication tool/scheduled job/workflow that would allow Lookup values to be specified in a central location, and then push those changes out to a local copy in the site collections that require it.
- Re-archiect your farm to use a single Site Collection. (Yes, I'm joking!)
:) Matt 19/12/2008
Back to your regularly scheduled vNext Wishlist programming, Dear Reader: here is blog 45 of one-blog-per-day-until-Christmas.
The Problem
Connecting SharePoint lists and libraries to Outlook is cool. It's usually easy to wow-the-socks-off-a-colleague by simply showing them a connected Calendar with two-way data sync. What? I can make changes in Outlook as well!?
Despite this coolness, a common misconception I've seen from Exchange users is that they expect this connection to be maintained on multiple machines. Sorry dudes, the data is synced as an old-fashioned PST file on the local disk, so you'll need to "Connect to Outlook" on every single instance of Outlook. This also makes it difficult for your IT chaps to push down a sync to force - err - make available - a connection to all users.
Possible Solution
Add a "Connect via Exchange" option or similar that allows the sync to be maintained and hosted in the user's exchange store, so that the synced data is available everywhere. The Outlook data would then sync with Exchange, which itself would perform the sync with SharePoint (possibly even once for all users with a few smarts). This would also provide more reliability if SharePoint was down or unavailable - the Outlook syncs would still work as they would be against Exchange, not SharePoint itself.
Another cool benefit of this approach would be in "cloud" scenarios where users may not even use the Outlook client, only the web client. The synced data could be easily delivered via Outlook Web Access, something that isn't possible with the current sync.
And while I'm at it, why not have a completely generic and simple-to-extend connection architecture? Dare I say it... "Connect to Google Apps"... "Connect to Facebook"... "Connect to Cloud Service X"... you get the idea. This could even be "Connect via Middleware Application" (substitute your favourite middleware tool here) where the logic of the mapping and sync could be easily defined in an external application with knowledge of SharePoint. A generic sync mechanism would open up even more opportunities for SharePoint to be a data aggregator/presentation tier in the enterprise and beyond.
Workarounds (For Now)
This one isn't really a showstopper.... just train your users. (I never said it would be easy!)
:) Matt 18/12/2008
According to a bunch of KB articles posted by a lil' company called Microsoft, WSS Service Pack 2 will ship with an Upgrade Checker designed to warn you about all those customisations that ain't gonna work in vNext.
Amongst these, my ears and eyes and other body parts pricked when I read about something called an " XSLT-based field type". Pretty interesting... is this the end of CAML as we know it? Or at least a major improvement in the custom field rendering architecture?
Either way... make sure you read this stuff because it may help avoid unnecessary upgrade work when 4.0 rolls around. I know I've got some work to do since I frequently customise the RenderPattern in my field types. Doh!
:) Matt
PS Yes, that was day 44. It counts! 17/12/2008
Day 43 of the pre-Christmas blogathon, and we're back to another vNext Wishlist cheatpost. Not long to go now!
The Problem
When creating or modifying a view on a List or Library, if you remove the Title or Name column, you'll no longer get the typical context menu on the List Item, which can make it pretty hard to work with the view. There's no obvious way of adding this drop-down to the other columns.
Technically, this is because the rendering patterns and alternate fields are associated directly with the Title column, and don't simply get dynamically attached to, say, the first field in the view. Dang!
Possible Solution
Allow a column in a view or list to be identified as a key column, or as a column that has the edit menu shown against it. Dynamically attach the drop-down rather than making it part of the column definition itself.
Workarounds (For Now)
Well, you could extract the list definition/fields and modify the rendering patterns yourself... or, you could write some funky JavaScript/JQuery to dynamically add the menu where you want it. Without this, however, your only real option is to add the title field back, or perhaps use the "Edit (link to edit item)" button to go to the edit page from where many (but not all) of the context-menu options can be clicked.
:) Matt 15/12/2008
Day 42 – and if only this post was the answer to the ultimate question of life, the universe and everything. Sorry – it's just another vNext Wishlist rant.
The Problem
Lookups can become orphaned – lose their connection to the target list that is – for many reasons. Waaaay back on day 29 (you were reading then, weren't you?) I moaned about a couple of these. Another common scenario is caused by the lack of referential integrity – you can easily delete the target list without the source list knowing about it or even getting the opportunity to say goodbye.
Now you might think I'm suggesting the actual problem here is this brutal break-up in the first place, but no, I'm accepting that this might be unavoidable in certain scenarios. The real subject of this particular rant is the inability to remap lookups from the browser. You just get an empty "Get information from:" in the edit page for the column without any additional options or advice.
Possible Solution
Add a "remap lookup" facility to the browser interface to allow lookups to be re-united with their parents, or at least given a new home. I'm imagining you would click a button, then select the new target list. For bonus points, this feature could even detect discrepancies in existing data that no longer matches an item in the target list, and allow those to be wiped, or set to a default, or perhaps even mapped to new values. At the very least, this feature should not automatically wipe the lookup values since the remapping might correct this.
Workarounds (For Now)
Delete then recreate your lookups (if you don't care about or have any existing data – lucky!) Otherwise, see day 29.
:) Matt 14/12/2008
Day 41... must... finish... stupid... goal... at all... costs...
SharePoint Infrastructure and Platform
- Microsoft released Oxite, an open source, standards compliant, highly extensible content management platform based on MVC. This isn't really a SharePoint Infrastructure and Platform topic, but the point is, it should be!
SharePoint Development and Customisation Tips and Techniques
Architecture, Planning, Design, and other Fluffy Stuff
3rd Party and Community Tools, Solutions and Web Parts
Beyond SharePoint
- Want to know everything about a website? Then you need QuarkBase, where the tag line is... everything about a website!
- Thumbtack from MS Live Labs sure looks like an interesting way to collect and share snippets from over the interweb. Will this see the light of day?
:) Matt 13/12/2008One-blog-per-day-until-Christmas reaches the forties - #40 infact. Yup, you guessed it, another vNext Wishlist!
The Problem
Out of the box, standard list view web parts can only be added on the same site. So you've got a nice list at a top-level site that you want to render in sub-sites... bad luck. At least, not with a list view web part anyway - and let's face it, a large number of SharePoint users won't have access to SharePoint Designer, or just want to add web parts in that friendly browser-only drag-and-drop fashion, and without thinking about any of the workarounds listed below.
Now I can understand why certain technical limitations may prevent web parts from showing across site collections given their inherent boundary points. But, within a site collection, and definitely within a site in the same branch of a hierarchy, it's just a data source, man! What's the big deal?
Possible Solution
In the "Add Web Parts" dialog or advanced tool pane, add the ability to browse to other sites within the same site collection and add list view web parts from those sites. Or, perhaps, show each site in the branch as having its own gallery (and maybe even give each site its own gallery, rather than one per-site collection). Or, perhaps show a "List View Lookup" web part or similar in the gallery that allows users to then select a list from the site collection after adding it to the page, rather than having this effectively done for us by the enumeration of all local lists and libraries at the top.
Workarounds (For Now)
Here's just some of the ways this can be achieved, in my order of preference (though it depends on the requirement):
- Use a Data View Web Part in SharePoint Designer
- Use a Content Query Web Part in the browser
- Buy a third party product that effectively gives you browser-editable Data Views, such as Bamboo's or Lightning's
- Use an RSS Viewer Web Part
- Write a custom web part with its own data source.
Not all of these will give you the same rendering options or look as out-of-the-box list views, or at least not without getting into some funky XSLT (not a bad thing necessarily, but not as easy to use as dragging a list view onto the page, which I think is my point :)
:) Matt 12/12/2008On the 12th day of Christmas, my true love (SharePoint) gave to me, one-blog-per-day-until-Christmas #39. (Songs don't have to rhyme, you know...)
The Problem
Once you break inheritance on a securable object in SharePoint, that inheritance is forever isolated from the parent, making it very difficult to manage security additions that are intended to flow downwards. Yet often breaking inheritance is unavoidable, as individual security rules cannot be set or changed at a lower level - it's all or nothing, man.
For example - List "Christmas Gifts" is secured to and can be read by Bob and Jo (though of course, you've used groups in real life haven't you!?) Item "Bob's Christmas Gift" has inheritance broken so that only Jo can read it. But if Thomas comes along and is granted access to read the list "Christmas Gifts" also, he won't by default by able to see "Bob's Christmas Gift".
Compare and contrast to the file system. Bob and Jo can access folder "Christmas Gifts". Bob is denied access on document "Bob's Christmas Gift", so only Jo can access it. Thomas is then given access to folder "Christmas Gifts". Because he isn't denied at the lower "Bob's Christmas Gift" document level, he'll be able to see that as well.
Not sure about you, but I find the latter much more flexible and intuitive.
Possible Solution
Make SharePoint security inheritance like file-system security inheritance, or at least add the option of "break inheritance and stay broken" vs "merge inherited rules" or similar.
All of this would require the abilty to explicitly Deny privileges, which can only be done through security policy in Central Adminstration (AFAIK). I think it would be flippin' useful.
Workaround (For Now)
Plan your security structure very very carefully to minimise inheritance breakages, including extensive use of groups. Perhaps try something like this free access checker web part to improve visibility - or something more comprehensive.
:) Matt |
|
|
|
|
|
|
|