SharePoint Consulting and Codeless Solutions

Special Character Problems in DVWPs and InfoPath Managed Code

2010-10-20T08:54:00.000-04:00

There are a couple of instances where we've run into problems with SharePoint-related technologies handling of special characters. Whether in InfoPath forms or DVWPs, there are sometimes glitches with converting fields, URLs, or filenames with special characters like &, ', %, etc. This article discusses some specific examples of workaround code that we have applied.
Data View Web Parts

DVWPs can be a powerful way to work around some of the limitations of TOCs and CQWPs. For example, on our public website, we have two DVWPs in the News and Events > Press Releases > Pages area.

The issue surfaced when we entered an article with an apostrophe in the title. What was happening was that SharePoint was trying to auto-encode the URL of the page, and thus converting the aprostophe to it's own special code equivalent. Unfortunately, that made the URL invalid and the user would receive a 404 error. So in order to bypass the auto-encoding, The following code in the DVWP Title hyperlink code had to be replaced:

Line 212:

<a href="{@FileRef}"><xsl:value-ofselect="@Title" /></a></td>

Was changed to:

<a href="./{@FileLeafRef}"><xsl:value-of select="@Title" /></a></td>

To explain further, the {@FileRef} attribute is a reference to the full URL path of the article. When employed, Microsoft technology tries to be "smart" and auto-encode the url beause it recognizes that it is a URL. But sometimes you really don't want it to be "smart", and this is one of those cases. So we construct the URL manually by using "./" to indicate the current site path (relative reference) and adding {@FileLeafRef} which is basically the attribute which stores the page file name. For some reason, it doesn't try to auto-encode the 'Leaf' attribute, just the full path attribute.

InfoPath Managed Code

We ran into a very similar problem a little while ago an application site. In there, we use a administrator-deployed, 2007 InfoPath form with managed code, which contains C#/xpath code to connect to the SQL Data Warehouse, look up a Facility by ID Number, and return the facility's official name. The problem was when it tried to bring back a facility name (or factility type, or any other field) with a special character like an ampersand (e.g. Tom & Joe's Clinic). We were not able to successfully determine how to remove the auto-encoding, so instead we found another short-term workaround. Now I'll try to briefly describe the code change employed.

After setting up some XPathNavigators to point to the secondary datasource fields, the code then defines local variables to store the retreived field values. The original code was as follows:

{
myFacName = DWfacName.Value;
myFacCity = DWfacCity.Value;
myFacState = DWfacState.Value;
myFacType = DWfacType.Value;
}

The modified code used the variable.value.replace() function to strip out the auto-encoded special character for the ampersand and replace them with an actual ampersand.

{
myFacName = DWfacName.Value.Replace("&", "&");
myFacCity = DWfacCity.Value;
myFacState = DWfacState.Value;
myFacType = DWfacType.Value.Replace("&", "&");
}

Now obviously, this is not the ideal solution, as it does not take into account all special characters--only the ampersand. But in this case we only really needed it to handle the ampersand. And the solution will likely be retired in the next six months or so and replaced with a SP2010 solution. So it's not worth digging much deeper into at this point.

What are SharePoint 'Codeless Solutions'?

2010-04-06T23:38:00.000-04:00

One of the popular aspects of SharePoint is how much power it puts into the end user’s--or perhaps more accurately--the power-users’s hands. This is a formula Microsoft has employed before. You might remember when Microsoft Office came out and suddenly business users could create databases and spreadsheets and eventually even build their own ad-hoc applications with macros and forms. Today business users can build their own collaborative environments with SharePoint. But this capability also comes with a whole new set of risks.

Codeless SharePoint development is a way of building actual web applications, using tools which do not require compilable code. Codeless solutions can usually be built in shorter time frames than traditional development cycles. This is not to say that a certain level of technical knowledge is not required, but given the extent of information available on the internet, it is easier to self-teach than ever before.

For example, traditional application developers use tools like Visual Studio to write code which they then compile and deploy for user consumption. The development process requires a dedicated technical resource as well as a configured environment for creating the executable code. It is not the kind of thing which is accessible to most business users and it requires a certain technical education and experience level to perform this kind of development.

Codeless development uses tools which are commonly accessible to users, such as SharePoint Designer and InfoPath. Technically one could argue that other Office products are also part of this toolset. Any innovative power-user can learn how to develop full-functioning applications using these tools, if they have the inclination.

On a cautionary note, one should consider the axiom that ‘just because you can do it, doesn’t mean you should’. There is no replacement for planning and thought. One of the risks with any highly accessible tool is that it opens the possibility for ‘junk’ solutions, as well. One still needs to have a well thought-out design plan, and take the time to weigh the risks of the software you’re creating. Have you considered how your solution handles data integrity? Are you building logical flaws into your system? Will the solution be scalable over time?

If your organization is considering utilizing codeless solutions, do some research on the pros and cons specific to the toolsets you want to employ. For example, here is a good article about SharePoint Designer.

Is SharePoint Right for You?

2010-04-05T14:24:00.009-04:00

Many companies have embraced the 'We are a Microsoft shop' mantra. As a result of this, some have been sold on the SharePoint products even before they knew what it really was. I personally get a lot of inquiries along the lines of: 'how can I do (fill-in-the-blank) in SharePoint'? Upon questioning, I usually determine that they do not have a clear plan of approach and often not even a clear business need. This is a case of putting the cart before the horse, or more accurately, picking a tool before defining the requirements of the tool. Would you use a hammer to insert a screw in the wall, just because you already bought the hammer?

First, in order to determine if SharePoint is right for you, you need to assess three things.

1. What is your business driver or drivers and does SharePoint cover them?
2. What is your budget level?
3. What is your tolerance for technology and culture change within your business?

Now there are some more detailed feasibility questions you will eventually need to get into such as compatibility and integration needs, supportability, scalability, and others. But first we need to know more about what the product is and is not, and whether it can theoretically fulfill some or all of your needs.

Let’s start at the top, with identifying your business drivers. Take a few moments to consider your needs. Do you need things like tools to support web development, content and document management, and general business collaboration and communication? Do you have a specific project or goal in mind, such as starting a company intranet or building a sales management tool? If so, then this tool may meet your needs. If you’re looking for an out-of-the-box total business solution, such as a CRM, or if your primary need is document management or data management, this may not be tool for you. SharePoint does have these capabilities, but its power is in doing a combination of these things moderately well, rather than being an expert product for specific niches. It is not the best document management product available, for example.

The first thing you need to know is that SharePoint is not just a single product, but more of a product line, or suite of products. It has two main components, WSS and MOSS.

WSS stands for Windows SharePoint Services. WSS is a free framework component which, in essence, gives you the ability to use SharePoint features in your Microsoft Windows network environment. It gives you the ability to create collaborative websites for your business teams with document sharing, Outlook and Office integration, and built-in organizational tools like announcement lists, discussion boards, contact lists, calendars, etc. Here is a Microsoft TechNet article which will describe some of the Features of WSS.

The challenge with using WSS without MOSS is developing a scalable and supportable implementation. WSS is really just a loose collection of features without good administrative cohesion, when used without the MOSS portal product.

MOSS stands for Microsoft Office SharePoint Server. MOSS is the commercial SharePoint server product, and it is usually what people are thinking of when they think of “SharePoint”. Depending upon factors like your licensing and feature needs, it can be a costly undertaking. Understanding the Microsoft licensing options can also be a challenge. If you decide to invest in MOSS, expect to spend some time and resources on research, planning activities, and possibly hiring a consulting resource to help shorten the learning curve. To learn more, view Microsoft’s product overview for MOSS.

Now onto question number two, your budget level. Up until recently, SharePoint was not well known or adopted amongst the small to mid-sized business levels. There were several significant large corporate implementations, some with SharePoint proper, and others with Microsoft products which were later incorporated into SharePoint, like MS Content Management server. Nowadays, SharePoint is marketed as a single suite of tools, much like Microsoft Office. And it’s also much more broadly adopted, mostly because many mid-sized and larger businesses are finding tremendous potential value in the features it offers. But if you don’t need the whole suite or can’t afford it, that doesn’t mean you’re completely out of luck. If your needs are simply to increase collaborative abilities within your organization, and you’re willing to put some design planning time into it, you may be able to use WSS. If your need is for a modest public website, you might consider OfficeLive. OfficeLive, or www.OfficeLive.com, is a Microsoft-hosted web site which offers free SharePoint-based websites for both commercial and non-commercial use. Yes, that’s right, free for commercial use. And of course there are non-Microsoft alternatives, as well, but which I won’t get into here for brevity sake.

Lastly, what is your business’ level of tolerance for technology culture change? The reason I bring this up as one of the three key questions, is because the SharePoint decision is, in my opinion, far more than just a simple product purchase. It can also be a new way of doing business, which can have dramatic effects on your existing business processes and systems. I have done full-scale, enterprise implementations several times, and what I’ve seen is that when business users ‘catch on’ to the possibilities of the tool, your SharePoint environment takes on a life of its own. It becomes an organic, evolving entity which is developed and run by its business users. The power of the platform lies in the power it puts into the average user’s hands. Now users can build their own websites and sometimes even their own automated solutions. If you do not plan your implementation well, you may find yourself in over your head very quickly.

A successful SharePoint implementation requires 1) a business environment which is flexible and agile; ready for change and new ways of communicating and sharing information; 2) technical and business experts who are proactive thinkers and dedicated to solving business needs; and 3) clear, efficient business processes modeling and strategic planning. You should expect to spend time and resources on handling direct and indirect impacts to your existing business processes when you choose this tool. You may find that once users have better access to business data and better communication tools, existing process gaps and data integrity flaws become a lot more visible. You may find that user demand increases not only technical staff utilization but also marketing and other business units’ staff utilization significantly. And you may also find that the system quickly becomes different than you planned, hopefully better than you planned, as your solution morphs to fit your real business needs rather than just your perceived ones.

If you determine that SharePoint is the right option for you, you may find the following governance planning resource links useful:

Office SharePoint Server 2007, SharePoint Governance Checklist Guide

The SharePoint (MOSS) Plan

If you'd like more information about choosing a web/communication platform, this article has a nice usage graph and accurate info. I've also found the author to be a fairly unbiased source of information, although I do not have any personal familiarity with the company or its services:
The best 2.0 technology for your intranet