A while back I posted about the book I am writing with Kailash Awati (Beyond Best Practices). If that project wasn’t taking enough time, dedication and brain cells, I have just finished an undertaking that has essentially consumed me for four months (some 450 man hours). This week it was delivered and the student responses far surpassed my expectations and made it all worthwhile.

I created a 4 day SharePoint 2010 Governance and Information Architecture training course as part of Microsoft New Zealand’s Elite initiative. (760 pages of SharePoint governance and IA goodness!) If you are not aware of the Elite initiative, it is a novel initiative by Microsoft in New Zealand to improve the quality of SharePoint practitioners in the Microsoft partner ecosystem. Now I tell you – Darryl Burling and his team down there at Microsoft have their ear to the ground – and really do listen to their customers. They initiated this program to allow local solution providers to take the next step beyond technical knowhow and turn it into deeper proficiency.

The SharePoint Elite Partner Initiative is designed to recognise those New Zealand Partners who have built skills excellence and a track record for success with SharePoint into their business. When it comes to SharePoint, these are the elite – the best of the best. If you are looking for a partner who can help you plan and deploy your SharePoint implementation, these are the best in the business.

This Elite program is unique in its focus and via the insight of those who conceived it, allowed me the flexibility to create a course that was a balance of technical labs, sensemaking, governance, critical thinking and user engagement. I was going through the course feedback just now and the key trend from it all was that the students really enjoyed the softer stuff that I teach, more so than the “here is a SharePoint feature and look at what it can do!” type material (they can get that sort of material anywhere).

So all in all it was a great week, which made all the effort, sweat and tears leading up to it worth it.

So thanks attendees, it was a great 4 days. For other readers, hopefully the course might come to a city near you in the not too distant future.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

Hi

It’s review week here at CleverworkArounds, and the next one on my list that I have been meaning to speak about is an application called Balsamiq Mockups. Mr Mindmapper himself, Ruven Gotz first turned me onto this application some time back, and I have found it very useful in taming RBO (rampant branding obsession).

Although I have written various posts on SharePoint branding, most of the time I find it a tiresome task that for many sites, is pushed way too far up the priority list to the point that much more critical success factors are overlooked or given lip service. Now in saying that, I will admit straight up that although I know how branding *should* be done from a sustainable governance point of view, I suck royally at making a site look good myself and I compensate by relentlessly pummelling SharePoint branding governance best-practices onto completely unsuspecting web designers.

Such fun

Balsamiq Mockups has adopted a visual based site wireframing approach that takes the opposite approach to the “Photoshop” approach to site design. A web designer using a tool like Photoshop will attempt to create an accurate visual representation of a site based on a stakeholder’s tastes (or lack thereof). The risk here with SharePoint is that the branding vision that is created using Photoshop can often be quite tricky to achieve in SharePoint without being “governance naughty”, particularly for collaborative sites that make extensive use of web parts, application pages and document libraries.

Some of the most difficult SharePoint recovery jobs that I have had to do were a direct result of seemingly innocent “customisations” that came from branding requirements.

So, how can Balsamiq help?

For a start, a complete design-challenged person like me can actually produce something useful .

More importantly, however, it is designed on a completely different premise than the Photoshop style approach to design. This tool works on a principle of emulating hand-drawn designs, supplying you with a bunch of drag-and-drop widgets and interface elements which allow you to construct the basic structure of a site in minutes. Out of the box, there are around 70 elements that can be used to construct a web site and you can see the results of my 5 minute effort in the image at the start of this article.

Want to see how easy it is? Then check the video below (assuming your IT department has not blocked Youtube).

Although the video shows how easy it is to create a mock up, you may be wondering if there are any SharePoint specific design elements. Out of the box there are not. But fear not, there is a flourishing community around this product that creates additional elements for you to use. SharePoint is well represented here.

Want to drop a SharePoint document library onto the page? Too easy.

Did someone say calendar, tasks or search?

This application does not take much of an investment in learning. One can pretty much learn the product just by watching the Youtube video and learning how to import other design elements is just a matter of clicking the help menu and choosing the “Download More Controls” option.

Would hard-core web designers may find the application cramps their artistic style? Maybe – I can only speculate. But for me, I spend most of my time in a PM, training, architect or advisory role. As a result, Balsamiq Mockups is perfect for me because, it above all else, it is quick to produce results. I can flesh out a SharePoint basic site design without having to fiddle around with master pages, SharePoint designer or CSS files (and for that I am eternally grateful!)

I can then export the mockup to a PNG file and use that in documentation, presentations, and best of all, my issue and dialogue maps which makes great strides in achieving the all-important goal of shared understanding among project participants.

Try Balsamiq Mockups out. It’s a great tool to add to your armoury.

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

No Tags

But there is also another colleague of mine who you may or may not know – Tommy Segoro, who is one of those mild-mannered guys who simply gets down to it and produces great things.

Tommy has released a free, open source CMS that sits on top of WSS. Publishing pages, page layouts, the page editing toolbar, all on WSS, without having to upgrade to MOSS at great expense to get the publishing feature.

http://www.codeplex.com/completesharepoint

http://www.completesharepoint.net/Home/Pages/Default.aspx

check it out for yourself!

No Tags

Hi again and welcome to part 6 of my series on the factors of why SharePoint projects fail. Joel Oleson’s write-up a while back gave me 5 minutes of fame, but like any contestant on Big Brother, I’ve had my time in the limelight, been voted out of the house (as in Joel’s front page) and I’m back to being an ordinary citizen again.

If you have followed events thus far, I covered off some wicked problem theory, before delving into the bigger ticket items that contribute to SharePoint project failure. In the last post, we pointed our virtual microscope at the infrastructure aspects that can cause a SharePoint problem to go off the rails.

Now we turn our magnifying glass onto application development issues and therefore application developers. Ah, what fun you can have with application developer stereotyping, eh! A strange breed indeed they are. As a group they have had a significant contribution to the bitter and twisted individual that I am today.

The CleverWorkarounds tequila shot rating is back!

for a project manager in denial

for the rest of us!

Leave us sensitive developers alone already!

Oh please.. I could make insultingly broad, sweeping generalisations about developers to make people laugh, but you guys hate each-other more than you do the rest of us! So any insult that I come up with will be water off a duck’s back and you will no doubt have a good come-back insult loaded up and ready to shoot me down

Case in point? Go and read this hilarious post by Mark Pilgrim – an oldie but a real goodie. Warning: there is profanity there. I’d dearly like to repeat it here because it’s pure gold, but I wear a suit now and I am supposed to sound all "impressive and wise". Got to keep up appearances

Mark’s post is mandatory reading for anyone following this series. Stop now and read! (It’s cool – I’ll wait for you).

** cue elevator music **

All done? Excellent. Let’s move on!

Mark is the sort of developer who would be worth his weight in gold. What is great about the above post is that it is actually an excellent example of the social complexity of projects and why it is so incredibly challenging to get a project team (stakeholders and user reference group included) to see a common version of the truth. Although Mark nails his fellow developers to the wall here, an equally witty project manager, information worker or senior executive could write the same sort of post for their discipline area.

In common with what I said during the infrastructure oriented post, a lot of application development issues are simply a manifestation of wicked problems that have not been recognised earlier. Although everything I have outlined in posts 1-4 is where you will find your root causes, in an organisation with a low maturity level the project team likely has been largely oblivious to the warning signs up until this point. Suddenly once we are cutting code, problems start to become apparent and it’s all those damn developers fault of course!

So once again, for the rest of this post we have to do a suspension of belief. In part 5 we went to Homer Simpson’s land of chocolate. So for this post, how about we can all pretend that we live in a world where teenyboppers do not exist and therefore people’s minds haven’t turned to jelly from being bombarded by crap music – so let’s blame Britney Spears for 99% of project failures.

In the world without Britney Spears

In this world, the stakeholders all agree with each-other. They have a tacit and deep understanding of the organisation’s vision, strategy and exactly how that strategy is to be executed. Therefore, they have clearly and unambiguously articulated this vision to the project team. This information in turn has been understood at all levels by the project team and after much investigation, soul searching and deep analysis, the entire team agrees completely that SharePoint is the perfect fit.

After reading all of the insightful information in the CleverworkArounds’ "Learn to speak to your CFO" series , a project management plan has been put together and agreed upon and signed off by all stakeholders. Scope, constraints and assumptions are reasonable and clear. A work breakdown structure has been developed and signed off with well developed budget and accurate, confident estimates.

What could possibly go wrong?

Thinking your developers are developers

Jeremy Thake wrote about "organisational responsibility" recently, and my new "homie" Joel made his feelings known when he wrote about the folly of "Thinking your developers are administrators". This needs to be analysed further however. I prefer to use the title "Thinking your developers are developers". The world is rife with what one would term "bad programming". The term is something of a misnomer though. I work with a great free WCM system called Joomla, and it has a devoted community of developers writing add-on modules for a dizzying array of options. Most are very well written, but some of these modules I have hacked away at the source and quite frankly they are pretty bad (and coming from a part time developer like me, that’s saying something).

Wishing your developers are admins?

That term "bad programming" is misleading and potentially unfair, because bad programming can contain tight, readable code that would satisfy industry standard conventions. In actual fact I’m not really all that fussed about the source code unless it’s *monumentally* stupid. Instead it is all about the thought process that went into the development. Here is a real world example from my past of what I mean.

A system developed by a former employer of mine relied extensively on DNS aliases, that our customers had to add into their DNS. So when our application looked for its "server", it queried DNS for that alias. I suggested that this was not a good idea, and we would be much better served via a registry setting that could override this, centrally controlled via group policy in Active Directory. The suggestion was met with general disinterest until some time later, we had an install at a site with several physical locations.There would be a server at each location, but the customer’s Active Directory set-up was a single DNS namespace. Thus we could only add a DNS alias for 1 server, yet we had several sites where servers resided. The system couldn’t handle the fact that a DNS can spread over multiple sites.

One quickly convened meeting later and suddenly the penny dropped on the logic of my suggestion. (But it took a real world emergency for that to happen). The next problem was the developers immediately chose the wrong location for registry key. Microsoft have a guide that tells you *where* in the registry to place your modification and they didn’t know there were recommendations and didn’t think to check for such a recommendation. Fortunately I caught that one in time and got it sorted.

That example highlights that "bad programming" was actually more like lack of awareness of important external considerations. I named the title of this section, "Wishing your developers are admins", more for the example that I cited than a statement of fact. Certainly, infrastructure administrators are very crap coders, (despite what they think of their efforts). But they do have a greater affinity for integration oriented governance issues than their pure development counterparts because of the nature of their role.

Sniggering infrastructure people who are feeling superior now should stop and take note. Experience has shown me time and time again that greater awareness about governance and integration rarely translates to actually running their environment to the ideals they espouse however .

Read my Choose Your Own Adventure post for a more offbeat and sarcastic take on that issue.

Planting wicked seeds..

In part 5, I had a section entitled "Infrastructure and Product Skills", and I suggested that a lack of product awareness and skills among infrastructure designers did not always manifest themselves into pain and suffering until later down the track. In the application development discipline, this is even more of a problem, and the remainder of this post focuses pretty much on this area, since if things do go down this road, it is simply going to end up being one of the root causes of the next, even more wicked problem to try and solve.

The impact of a bad design decision today can in particular have far reaching consequences into the future. Microsoft have this problem at a level that would blow your mind if you have been around long enough know your history (and your security . Remember than in 1973, what Rittel said of wicked problems: "There is no immediate and no ultimate test of a solution to a wicked problem", and by that he meant any solution, post implementation will generate "waves of consequences" that may yield utterly undesirable repercussions which outweigh the intended advantages.

The thoroughly depressing thing about that statement is the implication that a wicked problem can arise from the unexpected aftermath of a perfectly innocent "non wicked" problem!

So let’s see where SharePoint and the systems it relies upon makes life hard for developers and can blow out projects.

The obvious way is usually the dumb way

I am going to start by showing you some C# code. Non programmers, don’t be scared, it’s not too bad and in honour of Ms Spears I have kept the theme going. It is opening a SharePoint list programmatically, looking for anything with a title of "Oops I did it again" and if it matches that term, informs you that you must "Wash your mouth out!".

foreach (SPListItem item in list.Items)


{

if (item.Title == "Oops I did it again") {

console.Writeline("Wash your mouth out!");

}

}

{

font-size: small;

color: black;

font-family: consolas, “Courier New”, courier, monospace;

background-color: #ffffff;

/*white-space: pre;*/

}

.csharpcode pre { margin: 0em; }

.csharpcode .rem { color: #008000; }

.csharpcode .kwrd { color: #0000ff; }

.csharpcode .str { color: #006080; }

.csharpcode .op { color: #0000c0; }

.csharpcode .preproc { color: #cc6633; }

.csharpcode .asp { background-color: #ffff00; }

.csharpcode .html { color: #800000; }

.csharpcode .attr { color: #ff0000; }

.csharpcode .alt

{

background-color: #f4f4f4;

width: 100%;

margin: 0em;

}

.csharpcode .lnum { color: #606060; }

Easy enough – aren’t lists sooo easy to work with! Let’s just say you used this sort of logic in a web part that displays only list items that have "Oops" in the title. A few minutes later, you have coded and tested the web part, and it works a treat. Into the change control it goes, and into production it finds itself.

Fast forward 4 weeks and now the list has 400 items in it. Now a refresh of the page containing your web part is taking 10 seconds and getting worse. Naturally ‘the network’ must be the problem, right? Of course it’s not. In this example every list item is being enumerated and a comparison is made. This is well documented as the most inefficient way to query a list.

Putting on my old Cisco hat for a second, I am going to repeat an oft said mantra that people who know me will have heard many times over the years and what all self respecting Cisco nerds know. It’s not the %$^%$ network alright! It’s never been the network, it’s your $%%$ code!

You think the example above is made up? It’s not! On one SharePoint project where I was the information architect, a developer from a well respected Australian integrator did exactly what I described above, and proceeded to blame the infrastructure, the architecture, the network – basically anything that wasn’t their component. Of course, their development environment only had 10 items in the list and thus it seemed fine to them!

If you go back to my real-world example of the DNS/Registry issue, it was a design decision that was probably given half a thought at best, only to turn out to be a major constraint down the track. My SharePoint specific example above shows that for an inexperienced developer, even a "hello-world" style example is potentially a landmine just waiting for you to innocently step on. The issue is that, to the uninitiated, the SharePoint ecosystem has even more virtual land mines to avoid than being Lindsay Lohan’s publicist.

Simply put, if you do not have a broad depth of knowledge that can only come from time, pain and experience, you are inevitably going to get blown up time and time again. What’s that old saying? There are old SharePoint developers, and there are bold SharePoint developers, but there are never any old-bold SharePoint developers

If I listed all of the examples that I could think of, this post would get out of hand, so instead, Jeremy Thake sent me his diigo link that aggregates blog posts tagged with "SharePoint and performance". That should give you some idea of what developers are getting themselves into.

Junk DNA

John Kominetz wrote a great blog post that is highly relevent to this discussion. It has nothing to do with SharePoint in the slightest, yet if you substituted the word "Documentum" with "SharePoint" we would all be nodding our heads in collective agreement. It examines Documentum, a product that was already a mature player in the ECM space way before SharePoint had even made it to a little red box on a Redmond whiteboard.

Kominetz looks at Documentum’s heritage and describes it in terms akin to a living organism. He makes the observation that its "genome" has evolved over many years and carries with it plenty of junk DNA and "evolutionary dead ends". This is completely unavoidable, despite what any idealistic whinger about "bloatware" would like to believe. Another Joel (are all Joel’s in this world clever?), has a blog that is mandatory reading for anyone who is prone to making idealistic statements about security, bloat or complexity. I urge you to read his "Martian Headsets", "Architecture Astronaut" (where he picks on Groove ), as well as his "Things you should never do" posts. Joel is a wise man, indeed.

Quick history lesson for the uninitiated. SharePoint actually started as SharePoint Team Services (STS) and actually used the file system as the content store. (And I predict they will eventually go back to it too but that’s another story). Next Microsoft trotted out SharePoint Portal Server (SPS) where some bright spark thought that the Exchange "web storage system" (information store) would make a lovely document repository (probably because of the replication potential). Over the next couple of years there must have been a big ugly turf war between the Exchange storage team and the SQL team because, lo’ and behold, with SharePoint Portal Server 2003, SQL Server was now the document store. In this major architectural change, we actually lost some functionality. In addition to this, the 2003 version leveraged the recently released  .NET Framework, and provided a richer object model and platform for SharePoint to sit on (although then it was not a completely cohesive fit).

Roll on 2007 and we have a slew of new technologies and features, too many to name. And just to make it more interesting, Microsoft decided to change terminology (again) as ASP.NET was leveraged much more heavily. Thus, "webs" and "areas" are gone. But their evolutionary signature remains. Whether it’s the SDK, the choose-your-own-adventure Technet documentation, blogs or even the STSADM command, it is very easy to spend a lot of time going down the completely wrong path in the quest for a solution to a problem because you get mired in junk DNA. Worse still, you get there, realise you solved the problem the ‘old’ way, say "stuff it" and deliver it as-is.

Web Parts are a great case in point. There are actually two types of web parts in the object model. The one that was introduced with SharePoint 2003 and the one that comes with ASP.NET 2.0 (which SharePoint 2007 uses). When I was writing my hide control web part, almost all the technet examples as well as blogs on the subject did not make it clear which type of web part and the distinction between them. It turned out of course I was using the right web part class, but following the wrong online documentation. A couple of XML irregularities had be scratching my head for hours.

Infrastructure, security and governance awareness (again)

I sort of covered this at a high level in the "Wishing your developers are admins" section and it’s been said before on many blogs that SharePoint blurs the lines between developer and administrator. Both sides have to shift ground (as do project managers and stakeholders too). Administrators really need to gain more development competencies and visa versa. I won’t spend too much time reinforcing what has already been said, but always remember this: Despite all the advances in Windows 200x, IIS, SQL Server, fancy multi-layered security, richer object model via ASP.NET Version x and the like, every developer has it in his/her power to render even a tightly managed SharePoint farm a train wreck. A lack of a simple null-check can render a site un-viewable. Choosing the wrong way to execute a query on content can chew excessive amounts of CPU and memory, an ill-thought design decision can cause a good idea to be lost in the frustration of the user experience. When it all comes down to it, it is the end user acceptance, adoption and evangelism that determines whether a project has been a success or failure.

But it goes beyond performance. What about security considerations? As developers, do you stop and ask yourself whether your chosen course of action has implications on security? What is your definition of security anyway? (Because it is just as much about smart, re-usable design as it is about using passwords with non alphanumeric characters in them – google "the CIA triad").

A major problem area I have seen that has manifested itself in project management time frames is the difference between the development and production environments. SharePoint development environments tend to have a short shelf-life due to the amount of crap you have to install, remove, reinstall, etc. Therefore, they are best served via a single Windows 2003 Virtual Machine with Office 2007, Visual Studio 2005, SharePoint Designer, Reporting Services, SQL Server and all of the other associated paraphernalia. Give each developer their own so they don’t kill each-other

Without question, it is exceedingly likely that the developer is an administrator of their VM, and those that have a low security acumen tend to hit problems when they migrate their solution to the test or production environment. SharePoint has that many service accounts, application pools, web applications, site permissions, GAC DLL’s, .Net Trust levels, web.configs, etc that it is very easy for something to break into the transition to production.

Remember, everything works when you run it all as the administrator! You will not get much sympathy from your bitter and twisted infrastructure architect if you complain about it.

Project managers and stakeholders need to also be held to account here, as developers routinely cut corners when faced with unrealistic deadlines based on poor assumptions. But don’t worry developers, I’ll nail their asses in part 7!

Solutions and Features

The next two topics have caused me real-world pain. I had an argument with a developer a while back who felt extremely inconvenienced by my audacity to mandate that their web parts, DLL’s and web.config modifications be packaged up as a solution that activates the functionality via a feature.

But to be fair to the developer, if they have a low governance acumen, their point of view is completely understandable. SharePoint application development governance takes time to learn and is often not accounted for in project planning phases. Tools like STSDEV have gone a long way to improving the situation, but at the end of the day, developers who hate all the additional governance overhead associated with SharePoint are buck-passing risk to a place where it is ill afforded.

Branding…

Don’t get me started! (I’m drinking a scotch as I write this so please forgive the vitriol )

I’ll come back to branding in part 7 of this series, because to be fair, the developers are beholden to stakeholders who obsess over the location of a pixel. In many SharePoint scenarios (not all) this is mis-focused because their success criteria is not how good it looks, but how much the organisation has gained in bottom line.

But from a developer’s perspective, this is another area where I see serious abuse. My entire branding series came from the experience of having to clean up after a "consultant" who decided he did not have to research into the techniques to customise SharePoint in a sustainable, governable way. He completely butchered the _layouts files with no backup or consideration to the implications of future service packs or updates and ignored built in features like the site collection style library. Instead he reinvented his own solution. As I mentioned in the previous section, I asked him to package his work up into a solution for ease of deployment and rollback and I was met with resistance and tension.

The whole concept of ‘CleverWorkarounds’, comes from the pragmatic acceptance that hacks are a part of life. You can’t avoid them, and sometimes you are forced to resort to them. But there is a huge difference between a workaround and a ‘clever workaround’. Most of the various hacks and workarounds that I describe in the more technically focused articles of this blog (like the JavaScript stuff) always come from the philosophical perspective of leaving a environment where the next administrator or developer doesn’t curse your name for eternity.

Miscellaneous considerations…

Jeez, branding got me riled up – I guess the scars are still fresh on that one!

No-one can know everything. Everyone has governance deficiencies in one way or another. I remember in 2003, a shattered project manager came into my office. A client meeting had gone very badly, blown up in his face in fact. He came to me and his classic line to me was "All I did was tell them to modify their Active Directory schema!". If you know Active Directory, you would know what sort of landmine he just stepped on. It’s like telling Mr T. that his "bling" really brings out his feminine side!

Thus, the branding hacks manifest themselves in other areas too. Pretty much any time you delve into the guts of the 12 Hive (tech guys and devs know what I’m referring to here), you have to be very mindful of governance, security and re-use. Ask yourself this question

Does the change I am making have any chance of being undone or unduly affected by a future patch or service pack?

Is the answer is yes, then stop and get some advice!

Developers in general get frustrated with their project managers. The PM’s nag, don’t have a deep enough understanding of the intricacies and nuances of application development and set unreasonable deadlines based on what you see as incomplete requirements and assumptions. However, as I have said in the second post, their world is just as frustrating as yours. Shared understanding this is the key to dealing with it.

So, if your project manager gets upset because their deadlines stretch because you feel some more research is required to determine the best course of action, tell them to read this series from start to finish (whenever it finishes). Chances are they will be squirming with embarrassment way before they have even gotten to this post.

At the end of the day, it is in both your collective interest to keep the stakeholders happy and ensure that the project is successful.

Conclusion

This post covered a lot of material, and I appreciate you sticking with me. Judging from the reaction from Joel’s endorsement of the series, it also seems to have tapped into a common vein of frustration felt by many IT professionals all around the world.

The next post will round off the "people" aspects with an examination of the stakeholder and project sponsor and senior management perspective. Like the developer and infrastructure post, the key is to recognise that their perspective of the world is just as valid as yours, and just as much as you see them misinformed and contributing to a wicked problem scenario, you need to accept the fact that you do not have the full picture either.

Having said that, they get paid way more than we do and therefore that makes them fair game for some serious nailing to the wall Roll on part 7!

No Tags

Note: version 0.2 posted with minor bugfix 15th March 08!

Note2: Only works with MOSS 2007 sorry as you WSS guys do not have audiences targeting

This is my small contribution to the SharePoint world. It is a web part that once added to a web part page, allows you to customise the display by adding JavaScript to selectively hide controls on the page . Ever needed to hide a field from display/edit for a certain audience? Well here is a way do it without requiring SharePoint Designer and having to break a page from it’s site definition (unghosting).

Before and after shots below (look ma – no top button!)

To fully understand what is being done here, I suggest you read my series of articles on the use of JavaScript in SharePoint. Part 3 in particular will show you how to safely add this web part to pages with editing disabled (NewForm.aspx, EditForm.aspx and DispForm.aspx)

The full series can be found here: Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6.

Kudos to Jeremy Thake for feedback and some code contribution. Despite being seriously metrosexual, he is otherwise otherwise very cool .

Now two important warnings:

Warning 1: This is an alpha quality release and I may never touch it again So you very likely *will* break it. If there is enough interest, I am happy to pop it on codeplex

Warning 2: This web part should NOT be considered as a security measure and thus used in any security sensitive scenario (such as an extranet or WCM site). JavaScript by its very nature can be trivially interfered with and thus other methods (server side) should be employed in these scenarios to prevent interference at the browser.

You can download by reading the disclaimer and clicking the button below..

THIS CODE IS PROVIDED UNDER THIS LICENSE ON AN “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER

Use at your own risk!

To install perform the following commands

1. stsadm.exe” -o addsolution -filename CleverWorkAroundsHideFields.wsp
2. stsadm.exe” -o execadmsvcjobs
3. stsadm.exe” -o deploysolution -name CleverWorkAroundsHideFields.wsp -immediate -allowgacdeployment -allcontenturls
4. stsadm.exe” -o execadmsvcjobs

To remove/reinstall perform the following commands

1. stsadm.exe” -o retractsolution -name CleverWorkAroundsHideFields.wsp -immediate -allcontenturls
2. stsadm.exe” -o execadmsvcjobs
3. stsadm.exe” -o deletesolution -name CleverWorkAroundsHideFields.wsp
4. stsadm.exe” -o execadmsvcjobs
5. stsadm.exe” -o addsolution -filename CleverWorkAroundsHideFields.wsp
6. stsadm.exe” -o execadmsvcjobs
7. stsadm.exe” -o deploysolution -name CleverWorkAroundsHideFields.wsp -immediate -allowgacdeployment -allcontenturls
8. stsadm.exe” -o execadmsvcjobs

No Tags

God help me, I’m up to part 6 of series about a technology I dislike and still going. For those of you that have just joined us, then you might want to go back to the very beginning of this series where I used JavaScript to improve the SharePoint user experience. Since then, I’ve been trying to pick a path through the thorny maze of what you could term, ‘sustainable customisation’.

By that, I mean something that hopefully will not cause you grief and heartache the next time a service pack is applied!

So no mood for jokes this time – I want to get this over with so let’s get straight to it and finish this thing!

So where are we at?

• Part 1 looked at how we can use JavaScript to deal with the issue of hiding form elements from the user in lists and document libraries.
• Part 2 examined some of the issues with the part 1 JavaScript hacks and wrapped it into a web part using the content editor web part.
• Part 3 then examined the various issues of adding this new web part to certain SharePoint pages (NewForm.aspx, EditForm.aspx and DispForm.aspx). I also covered using SharePoint Audience targeting to make the hiding/unhiding of form elements personalised to particular groups of users.
• Part 4 started to address a couple of remaining usability issues, and introduced ‘proper’ web-part development using Visual Studio and STSDEV. I created a project to perform the same functionality in part 3, but would not requiring the user to have any JavaScript knowledge or experience.
• Part 5 then used STSDEV to create a solution package that allowed easy debugging, deployment and updating of the web part developed in part 4.

So what could we possibly have left to cover? Basically this article will revisit the web part code and make some functionality improvements and then I will cover off some remaining quirks/issues that you should be aware of.

[Quick Navigation: Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6]

Code Enhancement 1 – Debug Breakpoint

One thing that can be annoying when using this web part is debugging. A small typo in the list of columns to hide and the functionality can break and be difficult to troubleshoot. I have two enhancements that improve this situation.

The first is very simple. If you add a line like this in your JavaScript code

debugger;

When script debugging is enabled on your browser, a number of 3rd party debug tools such as Microsoft Script Debugger, Microsoft Script Editor, Visual Studio.Net and Venkman will treat this as a breakpoint and allow you to step through the code and perform client side debugging. This is handy of course, so wouldn’t it be nice for the web part to have a property that enables a breakpoint?

The code for this is insanely easy. We define a boolean property in our web part that optionally outputs the line ‘debugger;’ just before the rest of our code runs. Using the XML Serialisation as described in Part 5, we can expose this property as a checkbox in the web part properties when used in SharePoint.

Below is a code sample of the property and its use.

private bool _breakpoint;

// Create a custom category in the property sheet.
[Category("Custom Properties")]
[Personalizable(PersonalizationScope.Shared)]
[WebDisplayName("Enable Breakpoint?")]
[WebDescription("Add's breakpoints to Javascript code for script debuggers")]
[WebBrowsable(true)]
[XmlElement(ElementName = "BreakPoint")]
public bool BreakPoint {
    get
    {
        return _breakpoint;
    }
    set
    {
        _breakpoint = value;
    }
 }

In the render method, where applicable, we then add this line

if (_breakpoint)
{
      output.WriteLine("   debugger;");
}

So after rebuilding and redeploying this project using STSDEV, the web part properties now reflect this new property.

Check the “Enable BreakPoint” box and click okay. If your browser has script debugging enabled (found in Internet Options/Advanced tab in IE), you will be prompted to launch a debugger then the breakpoint is executed. Below you can see both the IE property page that controls script debugging and the prompt to debug the page when Visual Studio is installed.

Choose a new Instance of Visual Studio and you will then be able to see and step through the JavaScript code as shown below

Code Enhancement 2 – Debug Log Window

Sometimes, you will not have the benefit of being able to use a JavaScript debugger and you need a simpler method to display debug information. How about we add a debug log window that can conditionally be invoked when it is enabled in the web part properties?

Fortunately for us, Bret Taylor has done the hard work for us with a complete JavaScript debug log function.

So in JavaScript code, we can for example, add a line like:

log("This is log message ");

So once again, we can set this as a boolean property. If the property is set to true, the webpart can write the JavaScript log function to the browser and then call that function at various places in the rest of our code.

Below is a code sample of the property and its use

private bool _DebugLogWindow;

[Category("Custom Properties")]
[DefaultValue(false)]
[Personalizable(PersonalizationScope.Shared)]
[WebDisplayName("Use Debug Log Window?")]
[WebDescription("Select to set value to True.")]
[WebBrowsable(true)]
[XmlElement(ElementName = "DebugLogWindow")]
// The accessor for this property.
public bool DebugLogWindow
{
    get
    {
        return _DebugLogWindow;
    }
    set
    {
        _DebugLogWindow = value;
    }
}

The next section of code outputs the log function itself. I know this looks ugly but thats what you get when using one programming language to write the code of another.

if (_DebugLogWindow)
{
    output.WriteLine(@"function log(message) {");
    output.WriteLine(@"if (!log.window_ || log.window_.closed) { ");
    output.WriteLine(@"   var win = window.open("""", null, ""width=400,height=200,"" + ");
    output.WriteLine(@"   ""scrollbars=yes,resizable=yes,status=no,"" + ");
    output.WriteLine(@"   ""location=no,menubar=no,toolbar=no""); ");
    output.WriteLine(@"   if (!win) return; ");
    output.WriteLine(@"        var doc = win.document; ");
    output.WriteLine(@"        doc.write(""<html><head><title>Debug Log</title></head>"" +");
    output.WriteLine(@"        ""<body></body></html>""); ");
    output.WriteLine(@"   doc.close(); ");
    output.WriteLine(@"   log.window_ = win; ");
    output.WriteLine(@"   }");
    output.WriteLine(@"   var logLine = log.window_.document.createElement(""div""); ");
    output.WriteLine(@"   logLine.appendChild(log.window_.document.createTextNode(message)); ");
    output.WriteLine(@"   log.window_.document.body.appendChild(logLine); ");
    output.WriteLine(@"}");
 }

So all we need now is to invoke this function in sections of code where debug output would be useful. For example:

if (_DebugLogWindow)
{
     output.WriteLine("    log(\"We have " + _fieldlist.Length + " fields to hide \" ); ");
}

So let’s rebuild and redeploy these changes and see the effect.

The screen grab below shows the result of enabling this setting. We now have a second browser window spawned that logs to the screen all information passed to the log() function.

Code Enhancement 3 – Hide Control by ID

I cannot take the credit for this enhancement. I originally packaged up an early version of the web part for Jeremy Thake, a former colleague of mine to test on his environment before I published part 5 of this series. He in return sent me back another JavaScript function to hide based on HTML element ID’s.

Way back in Part 1, I described the JavaScript built-in method getElementsByTagName. Jeremy is using the function getElementByID. This function works on the assumption that HTML elements are assigned an optional ID attribute. e.g

<div id="CleverWorkarounds1"
     style="position:absolute; width:500px; height:150px; visibility: visible">
some DIV tag
</div>

If you look in SharePoint HTML source, you will see that this is the case.Take for example this particularly feral HTML element for the CLOSE button.

<input type="button" name="ctl00$m$g_100fd177_99ab_4755_a1d3_f064360d4317$ctl00$toolBarTbltop$RightRptControls$ctl02$ctl00$diidIOGoBack"
   value="Close"
   id="ctl00_m_g_100fd177_99ab_4755_a1d3_f064360d4317_ctl00_toolBarTbltop_RightRptControls_ctl02_ctl00_diidIOGoBack"
   class="ms-ButtonHeightWidth" target="_self"
 />

So this button can be referenced by the following ID.:

document.getElementById('ctl00_m_g_100fd177_99ab_4755_a1d3_f064360d4317_ctl00_toolBarTbltop_RightRptControls_ctl02_ctl00_diidIOGoBack').style.display="none"; 

Below is a code sample of the property and its use

private string _HideFieldByIdList;

// Create a custom category in the property sheet.
[Category("Custom Properties")]
[Personalizable(PersonalizationScope.Shared)]
[WebDisplayName("List of HTML element IDs to hide on this page")]
[WebDescription("Comma delimited list of HTML element IDs to hide on this page")]
[WebBrowsable(true)]
[XmlElement(ElementName = "HideFieldByIdList")]
public string HideFieldByIdList
{
    get
    {
        return _HideFieldByIdList;
    }
    set
    {
        _HideFieldByIdList = value;
    }
}

Next up, we have the function written by Jeremy (along with some debug log lines added by me)

if (HideFieldByIdList != null || HideFieldByIdList != "")
{
     if (_DebugLogWindow)
    {
        output.WriteLine("    log(\"Calling function hideFieldsById\" ); ");
    }
    output.WriteLine();
    output.WriteLine("function hideFieldsById() { ");
    _fieldlist = HideFieldByIdList.Split(',');
    if (_fieldlist != null)   {
        for (int i = 0; i < _fieldlist.Length; i++)
        {
            if (_fieldlist[i] != "")
            {
                if (_DebugLogWindow)
                {
                     output.WriteLine("    log(\"Looking for ID " + _fieldlist[i] + "\" ); ");
                }
                 output.WriteLine("document.getElementById('" + _fieldlist[i] + "').style.display=\"none\";");
             }
         }
    }
    output.WriteLine(" }");
    output.WriteLine();
}

So let’s test this! Redeploy the project and let’s hide the Close button on DispForm.aspx

Before screen-shot!

.

Add the ID of the “Close” button

After screen-shot! Wohoo!

Quirks and Issues

We are almost home after 6 posts in this series! No more coding for now as I think we have demonstrated enough of this idea. You can see how this can be used and extended quite easily.

There are a couple of minor points that I think are worth pointing out. One issue I covered back in my first branding series. If you deactivate this feature, the web part will not be removed from the web part library.

“That is by design. Deactivation of features does not remove data that was created when the feature was activated. if you want to “clean up” the data that was created, you need to create a Feature receiver handler and have the FeatureDeactivating() event handler manually remove the file.”

and

“Keep in mind though, data is left in SharePoint BY DESIGN. What would happen if you had deployed a page layout with a Feature and someone removed it while it was in use by thousands of pages? Oops… blamo!”

So now that we know that the web part will not be deleted, let’s see what happens when we modify it. Here is the web part as it was installed by the STSDEV solution.

Now let’s do a flashback and modify WebPart.XML in our Visual Studio Project. I have modified the Title property to “CleverWorkArounds Hide Column1 Web Part”

<?xml version="1.0" encoding="utf-8"?>
<!--Created by STSDEV at 7/03/2008 11:34:05 PM-->
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="CleverWorkAroundsHideFields" List="113" Url="_catalogs/wp" Path="WebParts" RootWebOnly="True">
    <File Url="CleverWorkAroundsHideFields.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="CleverWorkArounds" />
      <Property Name="Description" Value="Web part to selectively hide columns via JavaScript"/>
      <Property Name="Title" Value="CleverWorkArounds Hide Column1 Web Part"/>
    </File>
  </Module>
</Elements>

So let’s redeploy the solution, and even manually deactivate and reactivate the feature as well. When we re-examine the web part in the gallery, the change is not reflected.

Another inconsistency (although not a major one), is that the “Description” property is ignored completely. If you look at the Webpart.XML screen-shot above, you will notice I have set the Description property to “Property Name=”Description” Value=”Web part to selectively hide columns via JavaScript“.

But look at the web part properties above. The description is “A demo Web Part created by stsdev”.

I assume this is a bug with STSDEV, but in any event, its pretty minor and I can live with it.

Conclusion

Well gawddammit, I am finally done with JavaScript! But to round off this series, let’s summarise what we have achieved.

• No programming skills necessary
• No unghosting of Web Part pages
• Easy debug logging
• Leverage audience based content delivery
• Eliminated the requirement for SharePoint Designer
• Packaged up the functionality into an easy to deploy solution

I am well pleased, and I hope that you found some useful nuggets of information in this post.

I still hate JavaScript, but at least here we are using it in a sustainable customisation manner.

Bye for now

Paul

No Tags

If you think I write a lot on my blog, you should see my documentation and training material! I seem to be rare insofar as I actually like to write documentation and can churn out reasonable quality pretty fast. So if you need your scary SharePoint farm/infrastructure audited and fully documented, you know who to call!

Anyhow, here is the current state of play.

• Part 1 of this series looked at how we can use JavaScript to deal with the common request of hiding form elements from the user in lists and document libraries. We looked at a Microsoft documented method, then a better, more flexible method.
• Part 2 wrapped this JavaScript code into a web part which has been loaded into the SharePoint web part gallery.
• Part 3 then examined the trials and tribulations of getting this new web part added to certain SharePoint pages (NewForm.aspx, EditForm.aspx and DispForm.aspx), and then with a few simple edits, use this web part to hide form fields as desired. Finally, I demonstrated the power of combining this with SharePoint Audiences targeting functionality to make the hiding/unhiding of form elements personalised to particular groups of users.
• Part 4 introduced Visual Studio and STSDEV. I created a project to perform the same functionality in part 3, but not requiring any JavaScript knowledge or experience. By the end of part 4 I had a STSDEV project that compiled with no errors.

And now we are onto Part 5 where we turn our attention to the packaging and deployment of our web part. As you are about to see, STSDEV makes this a very quick and painless experience. If you aren’t convinced of the merits of STSDEV and the SharePoint solution framework by the time you finish this article, then I don’t know what will convince you.

[Quick Navigation: Part 1, Part 2, Part 3, Part 4 and Part 6]

So, for those of you that want to see the complete source code for an easy cut and paste into your own project, I have listed it below.

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;         

using System.Xml.Serialization;
using System.ComponentModel;         

namespace CleverWorkAroundsHideFields {         

  [XmlRoot(Namespace = "CleverWorkAroundsHideFields")]
  public class CleverWorkAroundsHideFields : WebPart {         

      private string _HideFieldList;
      private string[] _fieldlist;         

      // Create a custom category in the property sheet.
      [Category("Custom Properties")]
      [Personalizable(PersonalizationScope.Shared)]
      [WebDisplayName("List of columns to hide on this page")]
      [WebDescription("Comma delimited list of columns to hide on this page")]
      [WebBrowsable(true)]
      [XmlElement(ElementName = "HideFieldList")]
      public string HideFieldList
      {
          get
          {
              return _HideFieldList;
          }
          set
          {
              _HideFieldList = value;
          }
      }         

      protected override void Render(HtmlTextWriter output)
      {         

          // Now lets extract the list of fields from the web part properties
          if (HideFieldList != null)
          {
              _fieldlist = HideFieldList.Split(',');         

              // javascript inside C# - ugh 
              // I know this looks ugly on account of the escaped quotes. 
              // First section is the findacontrol function         

              output.WriteLine();
              output.WriteLine(@"<script language=""javascript"" type=""text/javascript"">  ");
              output.WriteLine();
              output.WriteLine(@"_spBodyOnLoadFunctionNames.push(""hideFields"")  ");
              output.WriteLine(@"function findacontrol(FieldName) {  ");
              output.WriteLine(@"var arr = document.getElementsByTagName(""!"");  //get all comments ");
              output.WriteLine(@"for (var i=0;i < arr.length; i++ ) {   ");
              output.WriteLine(@"   // now match the field name  ");
              output.WriteLine(@"   if (arr[i].innerHTML.indexOf(FieldName) > 0) { ");
              output.WriteLine(@"      return arr[i]; ");
              output.WriteLine(@"   } ");
              output.WriteLine(@"  } ");
              output.WriteLine(@"}");
              output.WriteLine();
              output.WriteLine();         

              // Now the hidefields function, which loops for each field to be hidden         

              output.WriteLine("function hideFields() { ");
              output.WriteLine("   var control; ");         

              if (_fieldlist != null)
              {
                  for (int i = 0; i < _fieldlist.Length; i++)
                  {
                      output.Write("    control = findacontrol(\"");
                      output.Write(_fieldlist[i]);
                      output.WriteLine("\" ); ");
                      output.WriteLine("   control.parentNode.parentNode.style.display=\"none\"");
                  }
              }
              output.WriteLine(" }");         

              output.WriteLine("</script>");
          } // if
      } // method         

   }
}

Now, let’s focus back on our STSDEV generated Visual Studio solution and make a couple of changes, to properly package up our code.

Edit 1: Feature.XML

You will find Feature.XML under RootFiles\TEMPLATE\Features\CleverWorkAroundsHideFields

In this example, I have modified the Title, Description and ImageUrl attributes of the <Feature> element of Feature.xml to give more meaningful, friendly descriptive text. The default image has been renamed to macgyver.jpg and you will soon see why

<Feature
  Id="8C39BCDB-9361-4412-950C-5ADE30AFF14E"
  Title="CleverWorkArounds: JavaScript Hidden Column Manager"
  Description="This SharePoint solution can be used to hide columns from DispForm.apsx, EditFormaspx, NewForm.aspx as well as custom web part pages. (http://www.cleverworkarounds.com)"
  Version="1.0.0.0"
  Scope="Site"
  Hidden="false"
  ImageUrl="CleverWorkAroundsHideFields\macgyver.jpg" xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest
      Location="WebParts.xml" />
    <ElementFile
      Location="WebParts\CleverWorkAroundsHideFields.webpart" />
      </ElementManifests>
</Feature>

Edit 2. Custom Icon Image

I decided that if I am going to create a SharePoint Feature with an icon, I’d have to use something that captures the very essence of the “clever workaround”. When you think about it, can it be anybody but MacGyver?

[if you see a broken image above then your IT staff are being anal and blocking YouTube - sorry]

Ahhh- the memories..  *ahem*, focus Paul – back to the post.

So, I have a small picture of MacGyver called oddly enough, MacGyver.jpg. I have placed this file into the RootFiles\TEMPLATE\IMAGES folder in my STSDEV project as shown below.

Now in Visual Studio, I have added this image to the project.

As you can see below, now macgyver.jpg is listed along with the default STSDEV image. You can delete the default image AfricanPith32.gif as we will not be needing it.

Edit 3. WebParts.XML

You will find WebParts.XML under RootFiles\TEMPLATE\Features\CleverWorkAroundsHideFields

In this example, I have modified the <File> element of WebParts.XML, modified the property element named “Group”, as well as added in a Description and Title property also. This XML file uses the <File> directive to put our web part into the web part gallery for any site collection where the feature is activated.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="CleverWorkAroundsHideFields" List="113" Url="_catalogs/wp" Path="WebParts" RootWebOnly="True">
    <File Url="CleverWorkAroundsHideFields.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="CleverWorkArounds" />
      <Property Name="Description" Value="Web part to selectively hide columns via JavaScript"/>
      <Property Name="Title" Value="CleverWorkArounds Hide Column Web Part"/>
    </File>
  </Module>
</Elements>

Let’s build it!

Right! If you have made it this far, then let’s do a final build using “DebugBuild” configuration. If it all compiles, we are ready to test a deployment to our development server.

Now you will get to see why STSDEV is such a damn useful tool. In the drop down window shown below, choose “DebugDeploy” as the build option, and then press F6 or build the solution via the “Build” menu.

Below is the output of the build. Look closely at the annotated output below. The web part has been packaged up into a SharePoint solution, the solution has been added to the SharePoint solution store and then activated for all web applications. (look mum, no hands!)

—— Build started: Project: CleverWorkAroundsHideFields, Configuration: DebugDeploy Any CPU ——
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Csc.exe /noconfig /nowarn:1701,1702 /reference:”C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.SharePoint.dll” /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Web.dll /reference:c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /keyfile:KeyFile.snk /out:obj\DebugDeploy\CleverWorkAroundsHideFields.dll

*** The above output is the command used by Visual Studio to compile the web part DLL.

Compile complete — 0 errors, 0 warnings
CleverWorkAroundsHideFields -> C:\VSPROJ\CleverWorkArounds\CleverWorkAroundsHideFields\bin\Debug\CleverWorkAroundsHideFields.dll
Refreshing Deployment Files…
“C:\Program Files\Common Files\stsdev.exe” /refresh CleverWorkAroundsHideFields C:\VSPROJ\CleverWorkArounds\CleverWorkAroundsHideFields\

*** STSDEV now runs and updates some of the other files in the solution required to deploy this web part (completely hands off for the developer which is great)

STSDEV – Simple Tools for SharePoint Developers
Refreshing Solution Package Files
Current Solution Name:
Current Solution Directory:
Refreshing deployment files…
Rebuilding DeploymentFiles\manifest.xml
Rebuilding DeploymentFiles\SolutionPackage.ddf
Deleting Solution Package File…
Building Solution Package (Debug Version)
“C:\Windows\System32\makecab.exe” /F DeploymentFiles\SolutionPackage.ddf /D CabinetNameTemplate=CleverWorkAroundsHideFields.wsp
Microsoft (R) Cabinet Maker – Version 5.2.3790.0
Copyright (c) Microsoft Corporation. All rights reserved..

Parsing directives
Parsing directives (DeploymentFiles\SolutionPackage.ddf: 1 lines)
20,812 bytes in 6 files                                         
Executing directives
  0.00% – manifest.xml (1 of 6)
  0.00% – CleverWorkAroundsHideFields.dll (2 of 6)
  0.00% – CleverWorkAroundsHideFields\feature.xml (3 of 6)
  0.00% – CleverWorkAroundsHideFields\WebParts.xml (4 of 6)
  0.00% – CleverWorkAroundsHideFields\WebParts\CleverWorkAroundsHideFields.webpart (5 of 6)
  0.00% – IMAGES\CleverWorkAroundsHideFields\macgyver.jpg (6 of 6)                        
100.00% [flushing current folder]
Total files:              6     
Bytes before:        20,812
Bytes after:          4,955
After/Before:            23.81% compression
Time:                     0.02 seconds ( 0 hr  0 min  0.02 sec)
Throughput:            1354.95 Kb/second

*** STSDEV now builds the web part and supporting files into a SharePoint solution (WSP) file called CleverWorkAroundsHideFields.wsp

Installing Solution…
“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe” -o addsolution -filename DeploymentFiles\CleverWorkAroundsHideFields.wsp

Operation completed successfully.

*** Now we use the SharePoint Admin tool STSADM to add the solution file CleverWorkAroundsHideFields.wsp to the SharePoint solution store. This creates a SharePoint timer job to actually perform this task.

“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe” -o execadmsvcjobs

Executing .
Operation completed successfully.

*** Now we have forced SharePoint to execute all outstanding timer jobs, thereby forcing the solution to be added to the store

Deploying Solution…
“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe” -o deploysolution -name CleverWorkAroundsHideFields.wsp -immediate -allowgacdeployment -allcontenturls

Timer job successfully created.

“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe” -o execadmsvcjobs

Executing .
Executing solution-deployment-cleverworkaroundshidefields.wsp-0.
The solution-deployment-cleverworkaroundshidefields.wsp-0 job completed successfully, but could not be properly cleaned up.  This job may execute again on this server.
Operation completed successfully.

*** These last two steps activated the uploaded solution using STSADM and then once again, executed all outstanding timer jobs. Note that in our example here, the final timer jobs had an error.

Verifying Successful Deployment

We can verify what the above log is telling us by navigating to Solution Management in SharePoint Central Administration. So let’s take a look! As reported in this log, there was an error. Note the cleverworkaroundshidefields.wsp status in in an “Error State”

Error? Oh no! What to do?

So for some reason, we have had a deployment error. So let’s retract this solution from SharePoint and perform an IISReset.

This action can be performed within Visual Studio thanks the the STSDEV functionality. Change the build type to a “DebugRetract” and press F6 or perform a build via the “Build” menu.

This time the log is much simpler, because we are not actually compiling our code this time. Instead, we are running the STSADM commands to retract this problematic solution.

—— Build started: Project: CleverWorkAroundsHideFields, Configuration: DebugRetract
“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe” -o retractsolution -name CleverWorkAroundsHideFields.wsp -immediate -allcontenturls

Timer job successfully created.

“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe” -o execadmsvcjobs

Executing .
Executing solution-deployment-cleverworkaroundshidefields.wsp-0.
Operation completed successfully.

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

So now I perform an IISReset, and then attempt to redeploy the solution again.

For the sake of readability, I have omitted most of the build log this time.

—— Build started: Project: CleverWorkAroundsHideFields, Configuration: DebugDeploy

[snip lots of log output]

Executing .
Executing solution-deployment-cleverworkaroundshidefields.wsp-0.
Operation completed successfully.

Done building project “CleverWorkAroundsHideFields.csproj”.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

This time we do not have any warning messages in the Visual Studio build log. So let’s confirm via SharePoint Central Admin.

Great! So now we have successfully deployed the solution, the site collection administrator for this web application can activate the feature

Governance Interlude

I think at this time it is very important to reinforce why packaging up code into solutions is such a mandatory governance requirement. In the above example, we had a problem with the deployment of the web part. It may have been an issue with the DLL in the GAC, changes made to web.config files for each web application, or a variety of other reasons. The point is, I was able to roll back to a known good state and start over!

I’ve said it before, but any developer who rolls their eyes at me when I tell them that their work has to be packaged up as a solution, obviously is not serious about governance.

Activating the Feature

So, now that our solution has been installed and deployed to each web application, we now have a site collection feature to activate. This feature will copy our web part into the Web Part Gallery for the site collection and thereby make it available for use.

So as a site collection owner, we navigate to “Site Actions” and “Modify All Site Settings”. Choose the option “Site Collection Features”, and you will see the results of our work in all its glory! Wahoo!

So don’t just sit there! Activate the sucker!

Testing the new web part

For this example, I am going to use the same demo site and list that I used in part 1 of this series.

The site is http://tidemo/tftp and the list to try this on is the IT Assets list. I have navigated to the IT Assets list, and opened the entry for the first item in the list (ABCRTR01)

Using the ToolPaneView hack described in Part 3, open DispForm.aspx in page-edit mode as shown below.

Click on the Main web part zone and add a new web part. You will see CleverWorkArounds as a web part group, listing our web part. (For reference, Feature.XML is the file where name and description information is set)

‘

Add our web part to the page and then click on “Modify Shared Web Part” to being up the properties screen. This is where we get to see if you did all the XML serialisation code from Part 4 properly!!

If you see the screen below, it has all worked a treat! You now have a custom web part property asking you to list the columns to hide. The below-right image shows this web part property filled in with the “Purchase Date” and “IP Address” columns listed.

Click OK and let’s see the result! Wohoo! Fields hidden!

Conclusion

So, after 5 long winded blog posts, what have we achieved? Going back over the goals they were:

• Allow hidden fields based on identity/audience
• Avoid use of SharePoint Designer
• Avoid customisations to the form pages that unghosted the pages from the site definition
• Avoid the need for site administrators/designers to have to dabble in javascript code
• Packaged up the web part into an easily deployable/retractable solution

CleverWorkAround Rating: Awesome!

Phew! Are we done yet? It seems like I have been typing these JavaScript articles for a freakin eternity! Alas no, I’m *still* not done!

I have an additional enhancement to make to this web part, and I also want to alert to you a couple of issues I had with this whole process.

So a Part 6 is in the works, but for now, I think its time for a well deserved beer! Your shout?

regards

Paul

No Tags

Hi there. As I write this post, the media are telling me that the stock market is stuffed, the US economy is going to the dogs and banks are writing down billions from sub-prime excess. I dare not check my online broker, road traffic this morning was abysmal, I was late, brought in the wrong laptop and left an important DVD at home.

Could it get any worse? Who knows, but it sounds like the sort of day to re-visit JavaScript and get frustrated with writing a web part for the first time.

So to recap on our journey thus far..

• Part 1 of this series looked at how we can use JavaScript to deal with the common request of hiding form elements from the user in lists and document libraries. It looked at a Microsoft documented method, then a better, more flexible method.
• Part 2 wrapped this JavaScript code into a web part which has been loaded into the SharePoint web part gallery.
• Part 3 then examined the trials and tribulations of getting this new web part added to certain SharePoint pages (NewForm.aspx, EditForm.aspx and DispForm.aspx), and then with a few simple edits, use this web part to hide form fields as desired. Finally, I demonstrated the power of combining this with SharePoint Audiences targeting functionality to make the hiding/unhiding of form elements personalised to particular groups of users.

All in all a pretty clever workaround so far if I say so myself.

My original goals for this JavaScript was to find an effective, easily repeatable way to customise SharePoint form pages by hiding fields or form elements when we need to. Specifically:

• Allow hidden fields based on identity/audience
• Avoid use of SharePoint Designer
• Avoid customisations to the form pages that unghosted the pages from the site definition

We achieved these goals in part three, but was I satisfied? No. The quest for more clever workarounds always goes on!

[Quick Navigation: Part 1, Part 2, Part 3, Part 5 and Part 6]

So the way I am going to structure this post is to pitch it to part-time or junior developers. If you are an experienced software engineer, this article is not going to trouble you.

Coffee rating:

Remaining Issues

One thing I was unhappy about with the web part in part three was that JavaScript still had to be edited when using the web part on a page. I wanted to take the programming completely out of the equation. Additionally, it was about time I got off my butt and learned to code a web part anyway. I’d previously blogged about the wonderful STSDEV, and decided I’d better put my money where my mouth and actually use it before I start mandating that others do.

So the first part of this post is examining STSDEV, and the joyous fun I had with my first ever web part with it, then I will get onto the first part of the coding.

The Web Part Requirements

So what are we planning to do here? Basically it is pretty simple. The JavaScript code that hides the columns from a page looks like this.

If you look closely at the above example, you will see that we have two lines that are repeated for every field we wish to hide.

control = findacontrol(“Device Type”);
control.parentNode.parentNode.style.display=“none”;

So, how about we make a web part that accepts a custom property that allows the user to list all of the fields to be hidden, and the web part can generate the complete JavaScript code for each of them to be hidden from view. This screen-shot shows the basic idea.

Note that we have listed three columns in the web part properties separated by a comma. Thus the page containing this web part would hide the existence of any of these columns.

Enter STSDEV (Take 1)

So first up, I grabbed STSDEV from its codeplex home. I installed it and ran the EXE to receive the initial screen.

On my first attempt, I created the solution in my default visual studio projects folder (C:\Documents and Settings\Paul\My Documents\Visual Studio 2005\Projects\CleverWorkarounds)

STSDEV happily accepted this and created my solution, which I opened with Visual Studio 2005 and accepted the obligatory warning as shown. But that’s cool – we trust those nice STSDEV guys!

I won’t spend too much time going into the solution created for the web part project because you can watch the videos that explain it much better anyway. But I will draw your attention to the fact that two sample web parts are included in the solution, CustomWebpart1.cs and CustomWebpart2.cs. We will rename and modify these later but first I need you to be aware of one ‘gotcha’ that I encountered.

In Visual Studio try and compile this project as it is. Make sure that the build type is set to DebugBuild and press F6 or choose “Build Solution” from the “Build” menu. Uh-oh, I got a runtime error with STSDEV… Bummer

This had me going for a while, because at first I had made changes to the solution before I attempted a build. So I spent some time thinking it was my changes that were the root of the issue. All it turned out to be was the spaces in the path to my project.

C:\Documents^ ^and^ ^Settings\Paul\My^ ^Documents\Visual^ ^Studio^ ^2005\Projects\CleverWorkarounds

Enter STSDEV (Take 2)

This time, I’ve created the project with the parent directory parameter being a path with no spaces…

C:\VSPROJ\CleverWorkarounds

Follow all the steps as per take 1 and try and compile the solution. Good – no nasty runtime burps this time.

Customising the Solution

So we have to now take this generic visual studio solution and make our changes. This consists of deleting stuff that we don’t need, renaming our class and updating references to the class name. Later we will customise the build/deploy process too. If you have experience with STSDEV or this seems too straightforward for me to blog about, then skip to the next section, otherwise read on for more detail of my specific example.

The first step is to customise our generic web part solution to our needs. We will delete CustomWebPart2.cs and rename CustomWebPart1.cs to CleverWorkaroundsHideFields.cs. When you perform the rename, you will ask if you want all project references to be renamed also. Makes sense doesn’t it?

This dialog box should not be interpreted as modifying any hardcoded references to the old file name of CustomWebPart1.cs. You will still have to do some search/replace work.

Additionally, there are two .webpart files that go with the two default class files and you have to rename/delete these as well. They can be found in the solution under RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\WebParts.

Delete CustomWebPart2.webpart and rename CustomWebpart1.webpart to CleverWorkAroundsHideFields.webpart.

Below is the result of both changes (.cs files and .webpart files)

Okay, so now this solution comes with xml files, solution files and all the other paraphernalia associated with getting a web part bundled up and installed to a farm. Now we have to delete all references to the deleted web part called CustomWebPart2 and update the references to CustomWebPart1 to CleverWorkAroundsHideFields.

Using the FIND/REPLACE tool, the entire project can be adjusted very quickly

The above operation takes care of the renaming of CustomWebPart1 in one single operation. But with CustomWebPart2 we are deleting references, so it takes a little finer surgery.

Here are the results of the *find* for CustomWebPart2.webpart

Find all "CustomWebpart2", Subfolders, Find Results 1, "Entire Solution"
DeploymentFiles\SolutionPackage.ddf(25):RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\WebParts\CustomWebPart2.webpart
RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\feature.xml(17):      Location="WebParts\CustomWebPart2.webpart" />
RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\WebParts.xml(8):    <File Url="CustomWebPart2.webpart" Type="GhostableInLibrary">
Matching lines: 3    Matching files: 3    Total files searched: 9

You will find references to CustomWebPart2 in

• SolutionPackage.ddf under DeploymentFiles
• feature.xml under RootFiles\TEMPLATE\FEATUTES\CleverWorkAroundsHideFields
• WebParts.xml under RootFiles\TEMPLATE\FEATUTES\CleverWorkAroundsHideFields

Using visual studio, open up each of these files and adjust the references. So for example in SolutionPackage.ddf I changed from:

;*** add files for CleverWorkAroundsHideFields\WebParts feature
.Set DestinationDir=CleverWorkAroundsHideFields\WebParts
RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\WebParts\CleverWorkAroundsHideFields.webpart
RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\WebParts\CustomWebPart2.webpart

to

;*** add files for CleverWorkAroundsHideFields\WebParts feature
.Set DestinationDir=CleverWorkAroundsHideFields\WebParts
RootFiles\TEMPLATE\FEATURES\CleverWorkAroundsHideFields\WebParts\CleverWorkAroundsHideFields.webpart

Now if you are thinking to yourself, what is FEATURE.XML and Solutionpackage.DDF anyway? Then I am afraid that you have some homework to do! If you are going to code anything for SharePoint, you need to understand the concepts of features and how they are used with the solution framework. Seriously, if you are blindly editing the files using this post as a guide, then you are only going to get yourself into trouble later.

For the rest of you, finish off the renames and removals of the default class names and then try and rebuild the solution. If it all builds, you can move onto the next step of actual coding the thing.Once we finish coding, you will see pretty quickly how useful and time saving STSDEV really is.

Coding the Web Part – Part 1

So, now we open up CleverWorkAroundsHideFields.cs and add our code. The first step is to add references to additional libraries that this web part will use.

using System.ComponentModel;
using System.Xml.Serialization;

What are these and what do they do? Without going into loving detail, these namespaces allow you to use XML serialisation. I had not previously coded much ASP.NET stuff, so XML serialisation took me a little getting used to. But the basic idea is this.

XML Serialisation Interlude

If you have an object instantiated from a class, with a bunch of properties set to different values, how to you send those properties to another remote object of the same class? What if it is two separate web server or web applications?

XML serialisation allows you to set properties for the object that are then stored behind the scenes as XML (this is the serialisation part). The other end gets the XML (over HTTP) and deserialises it back to the native properties for the destination object. Lo and behold, we have copied the state of one object to another object.

Now think of the code that this saves when the other end simply has to call a deserialise method and all of the properties of the object are auto-magically filled in.

Now in SharePoint, web part properties have to be persisted. When you visit a page, the look and feel of the web part is determined partly by web part properties set by the site designer. Those settings are retrieved from the SharePoint database. So when those properties are first set by the administrator (i.e change the title or appearance of a web part), SharePoint serialises all of those properties to XML and that XML is stored into the database. When the page is then later loaded by a user, a web part object is created, and then the XML properties are deserialised back to the object properties so it can appear how it is supposed to.

Make sense? I hope so because that’s all I’m saying about it! If you are still cofused, try this article.

Coding the Web Part – Part 2

So having added the two references to the XML Serialaisation and System.ComponentModel namespace, you should have the following code.

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Serialization;
using System.ComponentModel;

Make sure that there is no reference to a namespace called Microsoft.SharePoint.WebPartPages. There are actually two different web part classes available, one designed for SharePoint 2003 and the more recent one being part of ASP.NET version 2. (System.Web.UI.WebControls.Webparts).

MSDN and Microsoft code samples have a lot to answer for here! Most code samples for web parts with custom properties are based on the legacy web part class, and things have changed between old and new, especially when it comes to XML serialised properties. I wasted a lot of time here because of this!

The next step is to delete the default code in the web part class. Find the following code and delete it.

protected override void CreateChildControls() {
  Label lblHello = new Label();
  lblHello.Text = "Hello";
  Controls.Add(lblHello);
}

Serialsed XML parameters are in square brackets around sections of c# code. These are .NET attributes and tell the XML serializer where the various members of this object will appear in the XML and what they will be named. Without these, serialization cannot take place.

So the first serialised parameter is defined in between the namespace and the class itself.

namespace CleverWorkAroundsHideFields {
   [XmlRoot(Namespace = "CleverWorkAroundsHideFields")]
   public class CleverWorkAroundsHideFields : WebPart {
   }
}

Now if we serialised the code into XML now it would look like this

<CleverWorkAroundsHideFields>
</CleverWorkAroundsHideFields>

Exciting eh? So let’s now add some web part properties and serialise them as well. First up the properties of this class. If you check the section of this post titled “Web part Requirements”, I stated that the web part should accept a custom property that allows the user to list all of the fields to be hidden. So below is the property that will store this list of fields. It is about as simple as a class property can be (just store a string with a get and set method).

private string _HideFieldList; 

public string HideFieldList
{
   get
   {
      return _HideFieldList;
   }
   set
   {
      _HideFieldList = value;
   }
}

Now I need to add the parameters for XML serialsation. The above raw C# code above now changes to:

public class CleverWorkAroundsHideFields : WebPart { 

   private string _HideFieldList; 

   // Create a custom category in the property sheet.
   [Category("Custom Properties")]
   [Personalizable(PersonalizationScope.Shared)]
   [WebDisplayName("List of columns to hide on this page")]
   [WebDescription("Comma delimited list of columns to hide on this page")]
   [WebBrowsable(true)]
   [XmlElement(ElementName = "HideFieldList")] 

   public string HideFieldList
   {
      get
      {
         return _HideFieldList;
      }
      set
      {
         _HideFieldList = value;
      }
   }
}

I haven’t serialised this into XML, but you can see how all of the properties in square brackets would form an XML document describing the properties. if I did, it would look something akin to:

<CleverWorkAroundsHideFields>
<Category>Custom Properties</Category>
<WebDisplayName>List of columns to hide on this page</WebDisplayName>
<WebDescription>Comma delimited list of columns to hide on this page</WebDescription>
<WebBrowsable>True</WebBrowsable>
<XmlElement ElementName="HideFieldList">
</CleverWorkAroundsHideFields>

So now SharePoint has this in its database. When this webpart is rendered, the XML similar to above is retrieved and deserialised back to our WebPart class.

At this point it is a good idea to build the solution to ensure that you have no syntax errors or namespace issues. If you have trouble getting to this point, its best you not go any further until the project builds correctly.

Now where did I get these XML parameter values from? Go to the MSDN documentation for the System.Web.UI.WebControls.WebParts namespace and you will find all of the available properties buried there. (Either that or cheat like me and find out via here)

Coding the Web Part – Part 3

So now let’s write the code to render the JavaScript output. This is basically C# code to create the JavaScript that will render in the browser. The code is simple enough, we have looked at it in the last posts. But creating the JavaScript inside C# code makes it look worse than it really is.

First up, we need a new array variable called _fieldlist to store the individual fields (remember they come as a comma delimited list so we will split them to their individual names).

private string[] _fieldlist;

protected override void Render(HtmlTextWriter output)
{   // Now lets extract the list of fields from the web part properties
   if (HideFieldList != null)
   {
      _fieldlist = HideFieldList.Split(',');
      // javascript inside C# - ugh    
      // I know this looks ugly on account of the escaped quotes.    
      // First section is the findacontrol function
      output.WriteLine();
      output.WriteLine(@"<script language=""javascript"" type=""text/javascript"">  ");
      output.WriteLine();
      output.WriteLine(@"_spBodyOnLoadFunctionNames.push(""hideFields"")  ");
      output.WriteLine(@"function findacontrol(FieldName) {  ");
      output.WriteLine(@"var arr = document.getElementsByTagName(""!"");  //get all comments ");
      output.WriteLine(@"for (var i=0;i < arr.length; i++ ) {   ");
      output.WriteLine(@"   // now match the field name  ");
      output.WriteLine(@"   if (arr[i].innerHTML.indexOf(FieldName) > 0) { ");
      output.WriteLine(@"      return arr[i]; ");
      output.WriteLine(@"   } ");
      output.WriteLine(@"  } ");
      output.WriteLine(@"}");
      output.WriteLine();
      output.WriteLine();
      // Now the hidefields function, which loops for each field to be hidden
      output.WriteLine("function hideFields() { ");
      output.WriteLine("   var control; ");
      if (_fieldlist != null)
      {
         for (int i = 0; i < _fieldlist.Length; i++)
         {
            output.Write("    control = findacontrol(\"");
            output.Write(_fieldlist[i]);
            output.WriteLine("\" ); ");
            output.WriteLine("   control.parentNode.parentNode.style.display=\"none\"");
         }
      }
      output.WriteLine(" }");         output.WriteLine("</script>");
   } // if
} // method

The only section of code above that is of real interest is in the JavaScript hideFields() function. Here we loop for each field supplied in the list, and construct the code. So for example, if HideFieldList contained “Column A,Column B”, the generated JavaScript code would be:

control = findacontrol("Column A");
control.parentNode.parentNode.style.display="none"
control = findacontrol("Column B");
control.parentNode.parentNode.style.display="none"

Please be careful cutting and pasting this code! Quotes seem to get screwed up sometimes.

Conclusion (let’s have a break)

Once again, this post is starting to get a little long. So I’ll stop now and let you have a breather. In part 5 of this series, we will do an initial build of this solution, which will demonstrate how useful STSDEV is at speedy packaging and deployment. I’ll show you how to package up a nice, re-usable solution, and be able to test and debug quickly and painlessly.

Until then, bye for now

Paul

No Tags

So here is the lowdown so far. We are trying to find an effective, repeatable way to easily customise SharePoint form pages, so that we can hide fields or form elements when we need to. The goals were to:

• Allow hidden fields based on identity
• Avoid use of SharePoint Designer
• Avoid customisations to the form pages that unghosted the pages from the site definition

So how have we progressed thus far?.

• Part 1 of this series looked at how we can use JavaScript to deal with the common request of hiding form elements from the user in lists and document libraries.
• Part 2 wrapped this JavaScript code into a web part which has been loaded into the SharePoint web part gallery.

So let’s knock the rest of this over and pick up right from we left off…

CleverWorkArounds Coffee requirement of this post depends on how much you hate JavaScript.

Metrosexual web developer   

Socially inept technical guy   

[Quick Navigation: Part 1, Part 2, Part 4, Part 5 and Part 6]

Looking for step 1 and 2? Go to the previous post

Step 3. Adding the web part to content pages

So now we hit the supposedly simple step of adding our new web part to our display and edit forms for a list. The image below shows the page that I want to modify. In this example, it is DispForm.aspx

So it should be easy right? Just go to Site Actions menu and choose “Edit Page”.

Uh… hang on what’s going on here then. Where’s my damn “Edit Page” option?

Your first reaction is to probably say something like “okay so that sucks, how are we supposed drop a web part onto this page?”. To be honest with you, I’m still not sure why they did it in MOSS 2007, but when you think it through, I can sort of see the SharePoint team’s reasoning. These pages are auto generated and each time you add a column to a list or library, the NewForm.aspx, Editform.Aspx and Dispform.aspx are modified. The more you customise these pages, the more you risk breaking something important. Plenty of people have posted on how much of a problem this can be.

But by the same token, most of the posts I have read on customising pages like NewForm.aspx and EditForm.aspx involve making changes that requires an unghosted page, that is now different to the original site definition. Thus, why bother removing the ability to add a web part via the SharePoint browser based editor? At least doing it via the browser and web parts does not modify the page from the site definition. Seems silly not to allow browser based editing and then force people do make modifications in SharePoint Designer, likely as an unghosted page anyway.

Well, I can speculate all day, but lets get on with getting around this problem.

Workaround 1: Hacking the menu item code

The first technique that I first used to my “Edit Page” back involved using SharePoint Designer to customise the page. By default, the code to generate the “Site Actions” menu is actually defined on the master page, not the current page. However, you can override this behaviour in SharePoint designer by opening the page, clicking on the Site Actions menu and choosing “Create Custom Content” as shown below.

This will copy the code from the master page to this page, allowing you to customise it. The entire top navigation bar is now modifiable, but we are only interested in the code that controls the Site Actions Menu and specifically the menu that handles the “Edit Page” option.

You will find it easily enough in code view.

<SharePoint:MenuItemTemplate
   runat="server"
   id="MenuItem_EditPage"
   Text="<%$Resources:wss,siteactions_editpage%>"
   Description="<%$Resources:wss,siteactions_editpagedescription%>"
   ImageUrl="/_layouts/images/ActionsEditPage.gif"
   MenuGroupId="100"
   Sequence="200"
   ClientOnClickNavigateUrl="javascript:MSOLayout_ChangeLayoutMode(false);"
/>

All you have to do for this hack is to change the ID attribute of the SharePoint:MenuItemTemplate control to a different name. (Line 3 below).

   1:  <SharePoint:MenuItemTemplate

   2:     runat="server"

   3:     id="MenuItem_EditPage1"

   4:     Text="<%$Resources:wss,siteactions_editpage%>"

   5:   

   6:  />

Save this page and refresh the page in your browser. You find the “Edit Page” menu back again! Now we can add the web part in (as described in the following section entitled “Final configuration of our web part”). Once the web part has been added in, we can happily undo/remove this hack.

So, is this a good workaround? I actually don’t think so. The main problem I have with this method is the customisation of the page from the site definition. If you recall at the start of this post I talked about not wanting to use SharePoint Designer and more importantly, not wanting to modify pages from the site definition wherever possible.

CleverWorkAround Rating: Okay, but not that clever

Workaround 2: The ToolPaneView hack

This next workaround is great, because it can be done in the web browser and requires no SharePoint designer. It is exceedingly simple. For any web part page, simply append the following text to the URL:

&ToolPaneView=2

Thus, if my original URL was:

http://tidemo/tftp/Lists/IT%20Assets/DispForm.aspx?ID=2&Source=http%3a%2f%2ftidemo%2ftftp%2fLists%2fIT%2520Assets%2fAllItems.aspx&PageView=Shared

Then my new URL is:

http://tidemo/tftp/Lists/IT%20Assets/DispForm.aspx?ID=2&Source=http%3a%2f%2ftidemo%2ftftp%2fLists%2fIT%2520Assets%2fAllItems.aspx&PageView=Shared&ToolPaneView=2

Below is a screen capture of the effect. If you look carefully you see two things have happened. The page is now in Edit Mode and the “Add Web parts” window is displayed. Since we are in edit mode, we can click any web part zone and add our web part!

This time around, there is no SharePoint Designer used and no customisations to the page that require unghosting from the site definition.

CleverWorkAround Rating: My kind of hack!

Final configuration of our web part

So, we click to add a new web part to our form page (in this case DispForm.aspx). You see that the web part is listed in its own category below “CleverWorkArounds”. This is because when I uploaded the web part to the gallery, I specified the group. (I covered this back in the section “Step 2: Export the Web Part” )

Below is a screen capture showing DispForm.aspx page with our custom web part.

Now although the JavaScript is loaded, we commented out some code to make the web part re-usable. Now it’s time to uncomment the code and modify it slightly. Click on the edit drop down menu on the “CleverWorkArounds Hide Field” web part and choose “Modify Shared Web part”

Choose “Source Editor” from the web part properties and find the commented code.

Note I have now uncommented the some code from the hideFields function and specified the column to hide. So the code has changed from:

function hideFields() {
   // debugger;
   var control;
   // Add a line for each control to be hidden
   //control = findacontrol("Column Name");
   //control.parentNode.parentNode.style.display="none";
}

to

function hideFields() {
   // debugger;
   var control;
   // Add a line for each control to be hidden
   control = findacontrol("Device Type");
   control.parentNode.parentNode.style.display="none";
}

Click Save and OK and the effect is immediate, because the page refreshes and the JavaScript will be executed even in page edit mode. (Thus testing and debugging is also easy too).

Below is a version of code that hides two fields.

Below is the result. Now if you look carefully you can see I have hidden both the “Purchase Date” and “Device Type” fields and they are accordingly not displayed.

WOHOO! Is this clever yet? It has achieved the goal of re-use, as well as eliminating the need for SharePoint Designer, as well as any page customisation that requires unghosting – all a good thing. But what about personalisation?

This time its personal!

Back in part 2 I mentioned that a key requirement is to be able to conditionally hide fields from display. Well, now that this is a web part we can via audiences! Back in the properties of our web part, we have the ability to control when this web part is displayed. In the example below, I have configured this web part to only display when a member of “TIDEMO VISITORS” or “TIDEMO MEMBERS” is visiting the site.

So now when we refresh the page as the site owner, we can see that the JavaScript has not been rendered. “Purchase Date” and “Device Type” columns are now visible.

However if I log on as a site member, “Terrie”, the situation is different and the columns are hidden from view. How good is that!

So, re-examining our original goals, we have met all of them except the issue of security. As mentioned at the start of part 2, this technique is useful and effective for internal collaboration, but most definitely not recommended for external collaboration.

CleverWorkAround Rating – Pretty darn clever if you discount security

Summing Up

There are two things still bugging me about this whole thing. The first one is that code still has to be edited. Each time you drop this web part onto the form, you need to open its properties and modify the base code to specify the columns to hide. So I am thinking that part 4 of this series will be a first for me. I’ll code a custom web part that accepts the list of fields to hide as a comma delimited string, supplied via a web part property.

Below is a mockup of the idea

Now I haven’t actually done this yet, so I might be setting myself up for a big fall, but I figure that I will give STSDEV a go and see what happens.

The other annoyance is the whole reliance on client-side processing. Ideally an ASP.NET server side control could hide fields before they are rendered to the client. I’ve spoken to some ASP.NET developer friends of mine about that, and it seems doable. I’ll report about this in part 4 too.

regards

Paul

No Tags

JavaScript sucks! There I said it. Despite me hating it as a programming language, I can’t deny that in SharePoint, it does have its uses.

CleverWorkArounds Coffee requirement of this post depends on how much you hate JavaScript.

Metrosexual web developer
Socially inept technical guy
Luddite IT manager	(sorry … why are you here anyway?)

[Quick Navigation: Part 1, Part 3, Part 4, Part 5 and Part 6]

To quickly recap the first post of this series, we looked at how we can use JavaScript to deal with the common request of hiding form elements from the user in lists and document libraries. The technique demonstrated can be used for columns, buttons and whatever else you want. The method once debugged, is fairly easy to implement with SharePoint designer with and some cut and paste.

But there are several problems with the method that prevent it from getting a better CleverWorkaround rating than “Meh”. They include:

• One size fits all, fields are hidden for all visitors irrespective of need.
• You need to modify the page in SharePoint designer via cut and paste of JavaScript code
• You need to modify auto-generated pages
• You need to modify a page from its site definition
• Insecure, relying on client side to hide content/controls is not a secure solution

The first problem is obvious. The whole point of hiding fields is to prevent an audience from seeing them, but as an administrator you very likely want an unrestricted view of the world. So it would be nice to have the JavaScript code be selectively applied to a page. Right now everyone is restricted, no matter who they are.

On the second point, SharePoint designer is obviously *the* tool for serious SharePoint customisation. But ideally if we can apply this JavaScript within the SharePoint publishing feature framework, then SharePoint Designer is not required. It can all be performed via the browser, saving us costs such as SharePoint Designer licenses, user training, governance training and the biggest risk of all – people going nuts with unnecessary customisations .

On top of that, we are customising auto-generated aspx pages, namely NewForm.apsx, EditForm.aspx and DisForm.aspx – probably not such a good idea. (The fact that the “Edit Page” menu option for these files should be a hint that Microsoft are discouraging modification).

The fourth problem is a tricky one and a large topic in itself. Each time you customise a page, it no longer ‘predictable’ from an upgrade perspective, because by the nature of customisation, you are introducing variation. A future SharePoint upgrade or service pack may well make changes to the site definitions and automagically all pages created from them will upgrade fine. But any customised pages are not guaranteed to work.

So what is the result of this? Increased governance costs. Customisations need to be tracked and managed and upgrades are more complex. Thus my perspective on this is that if you can find an easy way to avoid customising pages from the site definition, then do so. Obviously, In a web content management scenario, significant site definition customisation is a likelihood, but in pure collaboration scenarios, you would be surprised with what you can get away with.

The last problem of security is a major concern. Any validation logic relying on client side JavaScript is prone to manipulation outside of your control. JavaScript can be disabled, or it can be fiddled with by debugging proxies such as fiddler. In fact I can tell you a real world example of this sort of manipulation.

Interlude – JavaScript Security – A True Story

I was assigned to do a security audit for an e-commerce site a few years ago that sold products in an online store. Believe it or, not, the pricing information for stock was in a JavaScript file! It was a separate .js file that was called when the page was loaded. I examined the .js file and could see it was auto-generated by their e-commerce system. Each night they dumped their inventory database to this .js file and then published it to the web server! So using a Paros proxy , I was able to do an on the fly search/replace of the prices in this .js as it was rendered to the browser. From there I was able to submit back to their site, orders for products that were much cheaper than in their database.

Insane? Totally – but sadly a true story.

Anyhow lets get back to the task at hand.

Wait just a dog gone second… is this supported?

Hacking away at the form pages (NewForm.aspx, EditForm.aspx and DispForm.aspx) certainly wasn’t supported in SharePoint 2003 according to Maurice. But with 2007 its harder to work this out. I’ve found nothing official, and Microsoft has a KB article talking about how to modify these pages without breaking stuff. To quote from them:

If you want to customize the controls that appear on the NewForm.aspx page, and if you do not want to show the default List Form Web Part, you can hide the List Form Web Part. To do this, follow these steps:

• Start SharePoint Designer 2007, and then open the NewForm.aspx page for the list.
• Right-click the List Form Web Part, and then click Web Part Properties.
• Expand Layout, click to select the Hidden check box, and then click OK.

Seems like a pretty clear endorsement to me! Anyway, back to business!

Re-examining the code

In the last post, I demonstrated the following JavaScript code used to hide some fields from my TFTP demo site.

<script language="JavaScript" type="text/javascript">

_spBodyOnLoadFunctionNames.push("hideFields");

function findacontrol(FieldName) {
   var arr = document.getElementsByTagName("!");//get all comments
   for (var i=0;i < arr.length; i++ )
   {
      // now match the field name
      if (arr[i].innerHTML.indexOf(FieldName) > 0) {
         return arr[i];
      }
   }
}

function hideFields() {
   var control = findacontrol("Device Name");
   control.parentNode.parentNode.style.display="none";
   control = findacontrol("Comments");
   control.parentNode.parentNode.style.display="none";}
   control = findacontrol("Options");
   control.parentNode.parentNode.style.display="none";}
}
</script>

So, we have established that having to cut and paste this via SharePoint designer is not really the ideal method if you want to promote cleverness and re-use. We also don’t want to customise the pages from the site definition, and we want it to work with multiple audiences. Can we satisfy all of these goals?

Yes indeedie .

Step 1. The Web Part

We are going to create a web part containing the above JavaScript code. I’ll do this by creating a new, temporary web part page and dropping a content editor web part onto it. So first up, go to Site Settings and create a new web part page as shown below.

File name and page layout do not matter as we will be deleting this web part page soon. Now edit this newly created page and drag and drop a “Content Editor Web Part” to one of the web part zones on the new page (doesn’t matter which)

Now, as instructed on the newly created web part, open the tool pane to the configuration screen below

Click on “Source Editor…” (make sure you do not use “Rich Text Editor… as this will escape the JavaScript code thinking it is text information”)

Paste the following JavaScript code into the input window. Note that I have sanitised it somewhat from the code example above. I have commented out the code where we need to fill in blanks later. Note that if you have never used it before, the debugger; command is damn handy, especially with Visual Studio installed.

Also, watch out for issues with quotes when you paste from here. I have seen my double quotes get screwed up breaking the code. If you uncomment the debugger line and it still never fires, you probably have screwed up quotes.

<script language="javascript" type="text/javascript">

_spBodyOnLoadFunctionNames.push("hideFields");

function findacontrol(FieldName) {
   var arr = document.getElementsByTagName("!");//get all comments
   for (var i=0;i < arr.length; i++ )
   {
      // now match the field name
      if (arr[i].innerHTML.indexOf(FieldName) > 0) {
         return arr[i];
      }
   }
}

function hideFields() {
   // uncomment the next line if you are troubleshooting
   // debugger;
   var control;
   // Add the two lines below for each control to be hidden
   //control = findacontrol("<Column Name>");
   //control.parentNode.parentNode.style.display="none";
}
</script>

Click SAVE and then OK on the web part properties screen. We now have a content editor web part with our JavaScript set and ready to go.

Step 2: Export the Web Part

The next step is to create a new web part, based on the customised content editor web part. This is an easy process that I have outlined below.

On the customised content editor web part created from step 1, click the edit drop down menu and choose “Export”

Save the web part file with a meaningful file name.

Once you have exported this web part, you can delete the web part page as we are finished with it.

The next step is to upload this exported web part into the site collection web part gallery. This is performed in site settings at the site collection level. Navigate to the web part gallery and upload the file you just saved.

In the next step, we have to set some metadata properties for the new web part. Since the web part gallery is just a document library, it can be assigned columns and content types like any other SharePoint document library. Of particular note here is the Title, Description and Group fields. The Group field is particularly useful, as when this web part is used, it is easy to find.

Conclusion

Sorry for the abrupt stop here readers, but that’s it for part 2, I was going to make one large post on this, but it’s simply gotten too big, so I’ll finish this off in part 3. But fear not, part 3 is 90% written and should be published within a day or two.

Bye for now

Paul

No Tags