Article: Master Advanced List Editing in SharePoint

Robert Bogue November 23, 2005 1 Comment

SharePoint’s built-in tools are good at providing a basic interface for adding and editing data, however, there are times when the included editing features aren’t enough. There are applications where the SharePoint list will work, except for one small detail. For instance, you may need to ensure that one of the fields in your list matches a back-end data source. This might be accomplished by creating a drop-down that is populated from a back-end system, or perhaps it’s some custom validation that ensures that the data that the user enters is in the back-end system.

Tearing open SharePoint to find a facility for these additional features is difficult. It requires an understanding of how SharePoint works overall as well as how it handles drawing a list. However, by the end of this article you’ll understand the overall architecture, the details that make it work, and you’ll have a framework for creating your own custom list editing solution.

One Little, Two Little, Three Little Web Parts
You know that SharePoint is built on Web parts, however, the extent to which SharePoint utilizes Web Parts internally may surprise you. Nearly every page that you see in SharePoint—from the default.aspx on every site to the forms pages at the heart of each list—is a Web Part Page.

http://www.devx.com/webdev/Article/30026/

Article: Concrete Code for a Quick Configuration

Robert Bogue October 26, 2005 No Comments

In my last article, ” Caught Up in Code, or Quick Configuration”, I proposed that you build more configuration based software solutions and less software that is governed by the relatively rigid rules of code alone. That article focused on the concept of configuration-based development. In this article the focus is on using the patterns for implementing a configuration-based solution.

A Few Examples

Before we drop into the details of a code sample, here are a few quick examples of how you can apply the configuration based pattern in the code you’re writing.:

Factory Pattern – Using reflection, generics, interfaces, and a configuration file, you can create a strongly typed factory that can generate objects of any type. You wouldn’t have to worry about ever building another factory class.
Optional Display – User Interface trimming, in other words, removing items from a menu when the user doesn’t have access to them is a time consuming process. However, a control can be built uses a list to determine the menu options and performs the security check as a part of drawing the menu. You wouldn’t have to worry about trimming my UI because the control manages security automatically.

http://www.developer.com/tech/article.php/3558711

Article: A Sensible Framework for SharePoint Intranet Navigation

Robert Bogue October 24, 2005 1 Comment

It’s never the first thing that I get asked on an engagement. It’s never the burning question in the minds of my customer as they seek out a consultant to help them with SharePoint. However, sooner or later it eventually comes to the topic of navigation. Although the fundamental concepts behind a sensible navigation framework are simple, they are not well understood by developers or designers. This article is designed for both audiences as they seek to make SharePoint usable.

Foolish Consistency is the Hobgoblin of Little Minds

Emerson (who said “Foolish consistency is the hobgoblin of little minds”) is a personal favorite author of mine;
however, he didn’t have to train hoards of users how to use a new interface. There’s definitely something to be
said for creating the kind of navigation that users are accustomed to. In the world of the Web that means
navigation belongs on the top and on the left.

Nearly every non-marketing Web site will follow a pattern with navigation on the top and on the left-hand side.
While what is on the top and left side differs, the fact that these spaces are reserved for navigation normally does
not. So if you’ve got a wild side, or feel like training scores of users, you can move the navigation — otherwise
we’re more or less stuck with the accepted norm.

Please enjoy a free copy of this article, also located on our Gifts page

Article: Caught Up in Code, or Quick Configuration

Robert Bogue October 18, 2005 No Comments

Many new programs are starting to blur the lines between something that should be enforced through specific flow control in code and when it’s the right decision to allow some decisions to be made by the configuration of the software. Here, you’ll explore that line and how it impacts your development.

Code is Well Known

Most developers and architects default to creating solutions for their problems directly in code. They put an “if…then” statement in the code and call it business logic. For example, if there is a specific property available, then the application must show an additional link. If the property shows that the user is a member of a certain group, then an additional menu may need to be displayed.

Situations like these arise every day. Creating a simple “if…then” statement is the obvious solution to the problem. But is the obvious solution always the right one?

Configuration Is Quick

Configuration, rather than a quick “if…then”, maybe the answer. Configuration is focused on creating ways to simplify individual business logic into a set of values that can be stored as configuration rather than hard coded into the logic of the program. Configuration is converting hard-coded logic into data that the program can operate on.

http://www.developer.com/tech/article.php/3556616

Troubleshooting Web Parts and Deployment

Robert Bogue September 28, 2005 No Comments

This isn’t the article that I set out to write. While researching another article (coming soon) I soon realized there just isn’t a lot of good material on how to troubleshoot Web part deployment, or even precisely how Web part deployment via STSADM even works. This article is designed to explain the moving parts of the deployment process and describe what can go wrong. Hopefully, it will help a few people get their implementations up and running more smoothly.

Why Deploy with STSADM?
Before getting too deeply involved in fixing STSADM Web part deployments, it’s important to understand what STSADM is and why it’s a good platform for troubleshooting Web part deployment.

STSADM is a ‘utility knife’ type of tool that ships as a part of Windows SharePoint Services. It does a wide range of things from site creation to Web part pack installation. If you have SharePoint Services, you already have this utility; it is typically found in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Bin.

http://www.devx.com/webdev/Article/29352

Article: Five questions to ask before buying a new tool

Robert Bogue September 20, 2005 No Comments

Before buying a tool, make sure that you understand the problem, all of the alternative solutions to the problem, what else you’ll need to implement the solution, and whether it’s a problem you should even try to solve on your own. Developing a routine before buying tools will help to prevent purchasing tools that you’ll never use.

My father is a tool guy. He has more tools than any sane person should have. I learned that there are a dozen different saws—each for a different purpose. I’ve inherited this love for tools, although I get more crazy about gadgets than power tools. I realize that I’m not alone. Often times I recognize an automatic instinct in clients towards buying a software package to solve a problem — and occasionally even a hardware purchase. Unfortunately, the tool—whatever it is—is just a tool. It can’t solve the problem by itself. It needs to be wrapped in a solution to solve any problem. Here are five questions to ask before you buy a tool to try to solve a problem.

Do you understand the problem?

Most of the time IT professionals are so pressed for time that they don’t make sure that they fully understand a problem before they try to solve it. We talk about requirements for big projects but we often forget that the same principles apply to smaller purchases.

For instance, a recent client was confronted with a group that needed Act!. Of course, that was a solution, not the problem. The problem was a basic contact management problem. They needed to keep basic details of contacts for a group of people. The client already had Exchange — but ended up purchasing Act! because the requirements weren’t understood. The group that Act! was purchased for is slowly moving back to an Outlook and Exchange public folder solution. (To be clear, there are some problems for which Act! is the right solution — it just wasn’t a good fit for this organization.)

http://www.techrepublic.com/article/five-questions-to-ask-before-buying-a-new-tool/

When you do and don’t want Shelfware

Robert Bogue September 13, 2005 No Comments

No matter the size of your organization, you can be sure you have old software sitting on a shelf somewhere. Robert Bogue talks about how to reduce the shelfware in your company.

Every organization has “shelfware” (software that has been put on a shelf). Whether an organization has 100,000 people or only one person, you can be sure there’s software sitting on a shelf somewhere in the building. In some ways, shelfware is like cholesterol. There’s a good kind of shelfware and a bad kind of shelfware. The trick is to increase the good shelfware and reduce the bad shelfware.

How does shelfware become shelfware?

There are actually a few different kinds of shelfware, some shelfware was never used or never returned the value that was intended. Other shelfware was retired to its position only after it had performed its service and was no longer needed.

For example, I once licensed a program called LinkBot Pro from Watchfire that validates web references. This tool was invaluable in helping me validate links in older versions of Que Publishing’s Official Internet Yellow Pages. I bought the license, used it for the project, and then it became shelfware. This is a good form of shelfware —software that more than provids its value and is then peacefully put out to pasture.

http://www.techrepublic.com/article/when-you-do-and-dont-want-shelfware/

How to Gather Windows SharePoint Services Requirements

Robert Bogue September 3, 2005 2 Comments

Getting good requirements for a SharePoint project is in some ways more critical than for a project that’s based on more widely understood technologies. The fact that SharePoint isn’t widely understood by clients — whether internal or external — means the potential for misunderstandings is much greater. For this reason, it’s more critical to discuss each feature of SharePoint to understand of how the feature works out-of-the-box and to understand how the organization envisions those features. Whether you choose to design and architect your SharePoint technologies solution yourself or decide to work with an outside partner to perform the architecture and design steps, you’ll find that having a foundation in solid requirements makes the development process run smoother and results in a better solution for your business needs.

http://my.advisor.com/doc/16797 [Article removed from the website]

Harnessing Properties in SharePoint Search

Robert Bogue September 2, 2005 1 Comment

Most users of SharePoint Portal Server rapidly become enamored with the ability to add new fields (containing meta data) to documents in the document library. All of the sudden it becomes possible to associate information to a file beyond the file name that we’ve been limited to since the beginning of the computing era.

Few users, however, have the opportunity to understand how this meta data is used by SharePoint for searching. This leads to problems when users decide that it’s necessary to use SharePoint Portal Server Search to search on information contained in a field that they have added. In this article you’ll learn how SharePoint uses document library fields to create properties that are searchable and how to enable searching on those properties.

Article reposted here: Retro: Harness Properties in SharePoint Search

Creating Artifacts — what you don’t know

Robert Bogue August 30, 2005 No Comments

[Authors Note: There’s a very interesting discussion brewing about what artifacts are good and what artifacts are bad. Check it out.]

Just as artifacts from ancient times give us information about early man, the documents and presentations you create in IT can give insight into your technology initiatives.

We know relatively little about the humans that were roaming the earth thousands of years ago. But because we have the artifacts they left behind–pots, arrowheads, and so forth–we have a glimpse give us a glimpse into their daily lives and who they were.

Artifacts (documents, Powerpoint presentations, spreadsheets, etc.) also allow a glimpse into the processes that are happening in your IT organization. Learning how to encourage the creation of artifacts is an essential part of managing an IT department.

The power of the artifact

An artifact is anything crafted by human hand that is left behind. This can be a product, a training manual, help documentation, project management documentation, or anything else which is tangible. Most of the time artifacts are documentation or diagrams of some sort but they can also be the finished product or some piece of the finished product.

http://www.techrepublic.com/article/creating-artifacts-what-you-dont-know/

Public Speaking