Best Practices for Creating Solutions

Article
05/05/2014

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This topic describes best practices for creating solutions for Microsoft Office Live Small Business customers.

Lists

When working with forms and datasheets, remember that SOAP calls, ISAPI code, and Web Services do not perform server-side validation to see whether a field is required, nor do they validate the data type required for a column. Validation for required columns and column data types is enforced only with appropriate code in the user interface for forms.

Web Parts

Do not include Web parts that you have created on a Windows SharePoint Services 3.0 server in an application that you plan to save in a solution for use in Office Live Small Business. Custom Web Parts cannot be added to the Office Live Small Business server and will not function correctly in an application created from the solution file.
Avoid adding a List Rollup Web Part to an application that you plan to save as a solution. If you do so, the List Rollup Web Part in a new application created from the solution template will point to the original application. You will have to reconfigure the Web Part in the new account where the template is deployed.

Views and Charts

List views of any kind affect the performance of an Office Live Small Business site. If you include list views in your site, test the site's performance often.
Gantt charts will slow performance of an Office Live Small Business site to some degree.

Server-side Programming

Do not add server-side code when using Microsoft Office SharePoint Designer 2007, because server-side code cannot be interpreted when the page opens on an Office Live Small Business site.

Client-side Programming

You can use client-side scripting with Office Live Small Business applications. However, when these applications run in the HTTPS protocol instead of HTTP, users receive two warnings before the item is displayed.
To improve download performance, Office Live Small Business servers have a handler that caches JavaScript files with the .js extension for as long as 24 hours. This can prevent developers from immediately seeing the impact of code changes to JavaScript files that affect either the public-facing Web site or a business application. Traditional methods for clearing the file cache may fail to solve this problem.

The easiest way to avoid caching is to rename the file extension. For example, you could change the .js file extension to .jsn or .jsx. However, this may prevent your code editor from recognizing the file.

Another solution is to use the code below to dynamically make your file unique for every server request so that it is perceived as new by the handler. The code uses a function that appends a timestamp as the value for the querystring parameter version.

<!--
    function includeJS(src)
    {    
        document.write("<script type=\"text/javascript\" language=\"javascript\" src=\"" + src +
            "?version=" + new Date().getTime() + "\"></script>");
    }
-->
</script>

<script type="text/javascript" language="javascript">
    includeJS("js/stuff.js");
    includeJS("js/goo.js");
</script>

To improve download performance, Office Live Small Business servers have a handler that crunches JavaScript files. Crunching refers to removing unnecessary comments, characters, and white space to reduce weight before a file is transmitted. However, crunching can make script debugging difficult for developers. The simplest solution is to rename the file extension before you open the file in your debugger.
If you change your JavaScript file extension or add code to troubleshoot caching or crunching problems, you should change it back when you are done writing the code to take advantage of the JavaScript caching and optimize performance for your visitors.
Consider using a method of tracking the versions of your JavaScript files, such as a naming convention like example_1.js and example_2.js. This helps ensure that proxies and browsers do not cache old versions of your JavaScript files.

Security Considerations

The Data View Web Part does not provide a high level of security. It retrieves XML data from a data source and then formats it using an Extensible Stylesheet Language Transformation (XSLT). To do so, the Web Part requires that you define a query and data source from which to retrieve XML data, such as an Office Live Small Business list or an external Microsoft SQL Server database. Remember, however, that when the Web Part connects to the database server, the server’s login and password are stored in clear text in the page that hosts the Web Part. As a result, any other user who has server-side access to the page can view the server's login and password.
Any item that is placed in the root Web of the business applications area in an Office Live Small Business account can be discovered by anyone who is authorized for the business applications and workspaces. Do not place sensitive information in this folder.

Accessibility

As you develop solutions for Office Live Small Business customers, keep in mind the accessibility recommendations found in Accessibility in Office Live Small Business.

Share via