Monthly Archives: October 2013

Site Collections

Thumbnail for 597When you access a SharePoint site with any type of client application, including the browser, you are first accessing a site collection that contains the site you ultimately want to access.

A site collection contains one top-level, or root, web, and zero or more subsites. The site collection acts as the root unit of authorization for all the webs it contains and it can exist at the root of a Web application or under another site collection.

A very important difference between a site collection and a web is that the site collection acts as a boundary for both security and aggregations. This distinction often trips people up and can cause some frustration. SharePoint has a number of mechanisms for querying and aggregating information, but they are generally limited to the confines of a site collection.

Most SharePoint items with which a user interacts exist within the context of a site collection, and an individual user can have permission to access many site collections. However, each site collection has different permission sets. In this respect, you can think of query visibility as similar to the data in two different databases that you want to aggregate by using a SQL query. In the case of databases, you generally have to use some sort of extension or intermediate step to create the correct result set. The same is true of data in two site collections.

Logical Site Hierarchy Example

It is tempting to think of a site collection as the top of a hierarchy of webs, as shown in Figure 1, because a site collection is assigned a URL when a user creates it, but this is not correct.

SiteCollections1Figure 1. A site is not the root of a hierarchy of webs.

Single Site Collection Example

A more accurate depiction of a site collection is as a container that has one or more webs. The root web uses the URL that the user specifies during the site collection’s creation.
Consider a simple company portal that is configured as follows:

  • Mycorp.com
    • Mycorp.com/Accounting
    • Mycorp.com/HR
    • Mycorp.com/HelpDesk

This topology is certainly functional, but what if the Accounting web needs a different security model and is the property of the accounting department including responsibility for user management? If so, it is possible to preserve the URL scheme with a little extra configuration and use multiple site collections instead of a single site collection containing every subsite.

Partitioning with Site Collections

By default, when you create a new site collection using SharePoint Central Administration, the URL will be something like http://myserver/sites/newsite.

The sites portion of the URL is called a managed path. Conversely, the page to create a new subsite allows you to specify the URL without the sites element, and if you want to create newsite as a subsite instead of a site collection, the URL will be http://myserver/newsite.

Consider the example shown in Figure 2. This URL scheme requires additional configuration to implement, but duplicates with site collections the URL scheme of the subsite for the accounting web.

SiteCollections2Figure 2. Managed paths allow control
when using multiple site collections in a 
single Web application.

You can duplicate the URL scheme used for a subsite with a site collection by defining a managed path.

doug (frame 367 of smile clip)This post is an excerpt from the online courseware for our Microsoft SharePoint 2010 for Developers course written by expert Doug Ware.

Doug Ware is a SharePoint expert and an instructor for many of our SharePoint 2007 and SharePoint 2010 courses. A Microsoft MVP several times over, Doug is the leader of the Atlanta .NET User Group, one of the largest user groups in the Southeast U.S., and is a frequent speaker at code camps and other events. In addition to teaching and writing about SharePoint, Doug stays active as a consultant and has helped numerous organizations implement and customize SharePoint.

MVC, Ajax, and jQuery

Screen Shot 2012-10-18 at 11.46.55 AMMany people see Ajax as the technology that saved the web, that made it possible to create much richer Web 2.0 applications than was ever possible using just HTML and plain old JavaScript. Part of the key to Ajax’s success is that it uses standards-based, widely implemented technologies instead of proprietary tools like Flash, Air, Silverlight, and many others that have sprung up to overcome the perceived limitations of HTML. Ajax has the benefit of ubiquity: all modern browsers have an implementation of JavaScript and
include the key object used to make asynchronous calls to the server, XmlHttpRequest.

Ajax is a powerful web technology because it makes pages far more interactive to the user, performing actions and updating parts of the page without requiring a full page refresh and accompanying flash of a blank page. This is one of the biggest visual differences between a web application and a rich client application, and gives the illusion of running on the client machine even though it is in a browser. An “Ajaxified” page feels faster to the user and reduces the load on the server by requesting small chunks of data and HTML rather than the content of full pages on every user action. Ajax is inherently asynchronous, so it leaves the user interface responsive to the user even if the last operation takes a while to complete.

Ajax is not, however, a panacea. It is a bit past its prime as the buzzword du jour of the last decade, but it is still too easy to get carried away with it and use it as though it solves all web problems. Here are a few of the problems:

  • Ajax requires that JavaScript be enabled on the client browser, not something you can assume in this day and age of security threats.
  • Unless you plan carefully to hook your pages into the browser’s history, the user won’t be able to use the back button to return to a previous page state. This is something that can be a bit unsettling to a user, when the back button takes them to an entirely different page rather than an earlier state of the same page.
  • By default, users also won’t be able to bookmark a link to the one product out of your entire catalog that they want to buy for their kid’s next birthday. This is because the application has to build in support for supporting page state through the URL.
  • Sites that make heavy use of JavaScript may come with many hundreds of thousands of bytes of script files. Even with caching, that can slow things down dramatically.
  • It also doesn’t help that JavaScript is notoriously slow, although modern browsers are improving performance.

Nevertheless, a well-designed site can handle most of these problems, both through careful design and judicious use of Ajax and other client-side features. The vast improvement to the user experience on sites that use Ajax can easily be worth the potential negatives, particularly since careful design can largely negate the problems.

In the purest sense, it may seem like nonsense to talk about MVC and Ajax together, since they occupy entirely different worlds within a web application. MVC is a server-side technology: the browser rendering pages doesn’t have a clue about models, views, and controllers. All that the browser sees is HTML and whatever the view embeds in the page it sends to the browser. Likewise, Ajax is a client-side technology that makes clever and sophisticated use of JavaScript and HTML’s document object model (DOM) to make pages far more interactive than is possible with just HTML. Of course, Ajax makes calls to the server to receive data used to update the page in response to user actions, but most of the time that is a clean, well-defined interface, often using some kind of web service implemented on the server. On the face of it, it doesn’t seem like there should be much to cover in a joint MVC/Ajax chapter, right?

Well, no, not right (as you probably guessed, based on the fact that this chapter exists). It turns out that there are some nice synergies in using the two technologies together. This is because MVC includes features that make it easier to implement custom Ajax features in a web page and because Ajax on the client can interact with action methods on the server to more effectively respond to user requests. This chapter will introduce you to these two broad ways that MVC can work together: on the server, mostly through features you can include in view definitions, and on the client in the client-side JavaScript you can include in a page. One nice thing about using these technologies together is that you can avoid writing much, if any, JavaScript code if you want, or you can write as much as you want to really make your pages come alive for users!

James Curtis

This post is an excerpt from the online courseware for our MVC 4.0: Validation and Working with Ajax written by expert James Curtis.

James Curtis  is a .NET Developer that primarily works in the UX space. He has worked on and for several large projects alongside Microsoft Consulting. James has spoken at several code camps about UX development for ASP.NET and SharePoint. He is an active participant in the development community tweeting and blogging about several topics in the UX area. James is an active consultant and is also assisting in several Start-ups contributing his UX experience.

Creating XML Using the XmlDocument Class

Most developers have used the XmlDocument class when creating new XML content, and it works fine. The problem is that its use is somewhat opaque. That is, the code isn’t readable (it’s difficult to discern what the resulting XML will look like as you read it), and it’s not always obvious how to create the XML content that you need.
Imagine that you need to create just this simple bit of XML content:

You might think creating this content would be simple, if you hadn’t worked with the XmlDocument class, but it actually requires a bit of code. The XmlDocument object requires you to take several steps each time you need to add a new node to the root document. Given a reference to the XML document, you must:

  • Call a method of the root node (CreateProcessingInstruction, CreateElement, CreateComment, and so on), creating the new node. You must pass necessary values to the constructor of the new node to initialize the node.
  • Append the new node as a child of an existing node, by calling the AppendChild method of the node.

The sample procedure, CreateXmlDocument, demonstrates creating the XML shown previously, using the pre-LINQ XmlDocument class:

 

The code starts by creating a new XmlDocument object, the root of the XML content:

 

As mentioned earlier, for each node you create, you must take two steps, creating the node and then appending it as a child of its new parent. The sample procedure starts by creating and appending the XML declaration:

 

Then, it creates and appends the comment node:

 

Finally, the code creates the document element, named Customers, and appends it as a child of the document:

 

To show how to create an XML file, the code calls the Save method of the XmlDocument object, and then displays the contents of the file:

 

NOTE The sample application contains several different overloaded versions of the DisplayResults method, and a few overloads for the DisplayFormattedResults methods. The sample procedures call these “helper” methods, and each displays output in the Console window. The DisplayFormattedResults method calls the
String.Format method for you, given a template in the first parameter. If you’re interested, you can investigate these methods.

ldn-expertkgetzThis post is an excerpt from the online courseware for our Microsoft LINQ Using Visual C# 2010 course written by expert Ken Getz.

Ken Getz is a Visual Studio expert with over 25 years of experience as a successful developer and consultant. He is a nationally recognized author and speaker, as well as a featured instructor for LearnNowOnline.

Review of DataSets

VisualStudio2010ADO.NET provides the ability to retrieve data from any number of data sources and to work with that data in memory. The DataSet object represents a local cache of data that is disconnected from the original source. The DataSet object can provide a relational view of data: It can contain tables, columns, rows, constraints, and relationships. The DataTable object represents one table of in-memory data. It supports rows and columns with schema information, much like an array, but it’s far more powerful. You can retrieve a DataTable by retrieving data from a data source, or you can create and fill the DataTable manually. The DataTable class exposes collections of rows and columns, where a row represents a reference to an actual row of data, and a column contains information about the schema for one of the columns of data. A DataTable’s Rows property contains a collection of DataRow objects, and its Columns property contains a collection of DataColumn objects. You can access and manipulate data in a DataTable’s rows by using a DataRow object. When you work with the Rows property of the DataTable, you can:

  • Access a DataRow object within the Rows collection by index, enumerator, or lookup.
  • Iterate through all rows, using a DataRow object as the iterator.
  • Iterate through all the rows, using an integer as the indexer.
  • Use the NewRow method of the Rows collection to add a new row, which returns a new DataRow object.

DataSets can be untyped or typed. When you directly instantiate the DataSet class, as shown in the following code, you will have an untyped DataSet.

A typed DataSet inherits from the DataSet class. It contains strongly typed properties for each DataTable. This means you can refer to tables and columns by names. If you are using an untyped DataSet, you can refer to the Products table by using myDataSet.Tables(“Products”). You can refer to the ProductID column in the Products table by using myDataSet.Tables(“Products”).Columns(“ProductID”). If you are working with a typed DataSet, you can use myDataSet.Products to refer to the table and myDataSet.Products.ProductID to refer to the column. When you create a data source via the Data Source Configuration Wizard, Visual Studio creates a typed DataSet that includes the tables you specify.

ldn-expertkgetzThis post is an excerpt from the online courseware for our Microsoft LINQ Using Visual C# 2010 course written by expert Ken Getz.

Ken Getz is a Visual Studio expert with over 25 years of experience as a successful developer and consultant. He is a nationally recognized author and speaker, as well as a featured instructor for LearnNowOnline.

Advanced Query Techniques

Thumbnail for 578

The T-SQL INSERT, UPDATE, and DELETE statements provide a lot of power and flexibility for maintaining data in a relational database. But they can also be unwieldy. Say that you have a table with rows that you need to use to update another table. Depending on the data in the source table, you might have to update or delete an existing row or, if no related row exists, insert it into the table. This can be unwieldy, requiring several statements to perform the various actions. And it can be a pain to get all the comparisons working just right.

The MERGE statement addresses this issue. It lets you insert, update, and delete table data with just a single statement, based on the similarities and differences in the data. It joins a data source table with a target table or view to perform the various actions. The operation it performs depends on the results of the join:

  • If data exists in both the source and the target, update the changed data in the target.
  • If data in the source doesn’t exist in the target, insert data into the target.
  • If data exists in the target but not in the source, delete the data from the target.

You have full control over how you define whether and how each of these actions will occur for a particular row in the source table. The MERGE statement is transactional, so you don’t need to explicitly define a transaction.
If any of the operations fails, the entire statement rolls back.

  • The MERGE statement uses five clauses:
  • The MERGE clause specifies the target data, such as a table, view, or other query.
  • The USING clause defines the source data.
  • The ON clause specifies how to join the tables, much like a regular JOIN clause.
  • One or more WHEN clauses define the actions to take based on the join matching.
  • The OUTPUT clause returns a row for each action taken.

The WHEN clause is where all the actions occur, and you’re likely to have more than one in a typical MERGE statement. The WHEN clause has three forms:

  •  WHEN MATCHED [AND condition]

Here is where you either update or delete an existing row in the target
data. You can have at most two of these clauses, and if you have two,
one must have a condition associated with it. You can define either an
UPDATE or DELETE statement in this clause. If you’re using an
UPDATE statement and more than one row in the target matches the
statement, you get an error, and you can’t update any row in the target
more than once. Similarly, you can’t update and delete the same row.

  •  WHEN NOT MATCHED [BY TARGET] [AND condition]

This is where you can use an INSERT statement, when a row in the source doesn’t match any row in the target. You can have only one of this WHEN form in any MERGE statement. The BY TARGET clause is optional, because it is the default.

  •  WHEN NOT MATCHED BY SOURCE [AND condition]

This form of the WHEN clause kicks in when rows in the target don’t match a row in the source; in this case you can either update or delete the row in the target. You can have at most two of these in a MERGE statement, and the second must have a condition associated with it. 

The optional condition on some of the versions of the WHEN clause can be  just about anything you can include in a WHERE clause. You have to include  at least one WHEN clause in the MERGE statement, although the order you include the different forms doesn’t matter at all. What does matter is that if you include the same form with and without a condition, the clause with the condition must be first.

Any triggers that exist on the affected target table will fire normally, but there is no guarantee of the order in which triggers fire if multiple operations are performed on the target table. So be careful of side effects. All normal permissions apply, so the user or security context must be able to perform the various actions.
ldn-expertdkielyThis post is an excerpt from the online courseware for our Microsoft SQL Server 2012 Developer course written by expert Don Kiely. 

Don Kiely is a featured instructor on many of our SQL Server and Visual Studio courses. He is a nationally recognized author, instructor and consultant who travels the country sharing his expertise in SQL Server and security.

LINQ to SQL Read-Only Queries

If you are looking for maximum performance, you can execute your queries in read-only mode. To do that, you can set the ObjectTrackingEnabled property of the DataContext to false. This turns off change tracking, which has some overhead. Because LINQ to SQL does not track changes in this mode, performance improves.

When you select Read Only Queries in the chapter’s sample application, you
will execute two queries. The first retrieves a list of customers in the United
States.

The second query illustrates an important consequence of setting
ObjectTrackingEnabled to false: It sets DeferredLoadingEnabled to false and
therefore turns off deferred loading.

Figure below shows the result of running this code.
TopicLINQtoSQLimg1
Figure above Deferred loading is disabled, so the number of orders does not display.

The code first executes a query to retrieve information for a customer. It then displays the customer’s name, city, and region. Next, the code displays the number of orders for this customer. In the previous example, LINQ to SQL then generated a SQL statement to retrieve the customer’s orders. However, when you turn off change tracking you turn off deferred loading, so in this case, LINQ to SQL does not send the SQL statement to retrieve the customer’s orders.

The code next defines the following query to retrieve the ID and value for each order. However, customer.Orders is empty, so LINQ to SQL does not generate the SQL statement to retrieve the data.

 

TIP: Use read-only queries with caution. The absence of deferred loading means you will not retrieve all of the data you would otherwise. If your code relies on the missing data, you could receive runtime errors.

ldn-expertkgetzThis post is an excerpt from the online courseware for our Microsoft LINQ Using Visual C# 2010 course written by expert Ken Getz.

Ken Getz is a Visual Studio expert with over 25 years of experience as a successful developer and consultant. He is a nationally recognized author and speaker, as well as a featured instructor for LearnNowOnline.

Record Management in SharePoint 2010

Thumbnail for 597

 

SharePoint 2007 supported only the Records Center site template for records management, and did not provide support for records management for individual libraries on non-Records Center sites. The fact that SharePoint 2010 now has this in-place capability does not do away with the need for the Records Center site template. You would continue to choose the Records Center template for the following scenarios:

  • A centralized approach to records management is preferred to simplify auditing and reporting tasks.
  • The need exists to perform records management on entities other than document library members, such as email messages or SharePoint list items.
  • The need exists to organize archived material without requiring human intervention on submitted items.

Organizing Content

When using the centralized approach of the Records Center site, it is likely that multiple libraries will be needed for archiving records, particularly in a case that will include many thousands of documents. There are three particular problems that must be overcome in such a case:

  • Thousands of documents must be routed to the proper library to support a well-organized site, but the routing must be carried out without the burden of human intervention.
  • Users must be blocked from ignoring the routing mechanism and choosing their own destination libraries.
  • The archive site must be organized in such a way that folder content does not exceed recommended maximum capacities.

The Content Organizer feature, which is automatically enabled for Records Center sites, is designed to address these very challenges. The Content Organizer creates a special library named the Drop Off Library. This library is the central location for submitting documents to the Records Center site. Documents submitted to this library are routed to another library based on defined rules. When you author these rules you specify the following:

  • One or more conditions to determine if a submitted document matches the rule.
  • A destination library where matching documents are routed.
  • A priority value, to indicate which rule should be applied in a case where more than one rule matches a document.

If a document is submitted that does not match a rule then the submitter and the owner of the site are notified. In addition, the document remains in the Drop Off Library until the site owner intervenes with a new rule.

In addition to applying rules for routing, the Content Organizer feature also provides the Folder Partitioning capability. Folder Partitioning provides an automatic mechanism to ensure that folders do not contain an excessive number of items by automatically subdividing a folder once it reaches a certain threshold.

While you can create your own destination libraries in the Records Center site, there is a library already created for you named Record Library. The significance of this library is shown in Figure 1: Documents added to this library will automatically be declared as records.

RecordManagementinSharePoint2010img1

Figure 1. The Record Library automatically declares a document as a record.

In Place Records Management permits a user to manually indicate that a document is a record and subject to records management rules. In the case of the Record Library, the declaration is automatic: simply placing a document in this library implicitly declares that it is a record.

Managing the Records Center

While all of the settings for the Records Center site may be configured via the Site Settings page, the Records Center site template includes a dedicated page (see image below) for convenient access to site management tasks such as defining rules, organizing libraries, and generating reports.
RecordManagementinSharePoint2010img2

The Records Center Management page provides
convenient access to standard configuration tasks.

John.UnderwoodThis post is an excerpt from the online courseware for our Microsoft SharePoint 2010: Enterprise Content Management course written by expert John Underwood.

John Underwood is a technical evangelist for a SharePoint consulting company, with 30 years of programming experience, including 20 years on the Microsoft platform and 10 years with .NET. John also has extensive experience using, configuring, and programming SharePoint.

 

 

Data Annotations

One of the many benefits of separating the concerns of the models, views, and controllers in an MVC application is that each of the three components is able to contain all of the code with which it is concerned. This means, for example, that the view is only concerned with the user interface, and contains only the code that displays a page and data to the user. It doesn’t have any business logic, data access, or any other code unrelated to the user interface.

In the same way, an MVC model is concerned only with data and business logic, nothing else. It interacts with a data store, such as SQL Server, and takes care of all the CRUD operations for maintaining data. In theory, this helps maintain a clean separation of concerns with the other MVC components.

But not everything is always so black and white or neatly partitioned. One issue that would seem like it crosses the component boundary is data validation. On one side, a relational database has certain requirements for data, such as a ProductID that is an integer, and that a company name is a string of one to fifty characters, no more and no less. It may also mandate that every product be assigned to a non-null product category, and that a U.S. Zip code be either five or nine characters in length.

Beyond those data type sort of requirements, you may also have business logic that requires that an email address be of a format that meets the requirements of the Internet, or that no customer can receive more than five orders a year with greater than a 20% discount. All of these data and business logic rules are in place to ensure that stored data is of the highest quality and that the application doesn’t allow any violations of the rules by which the business operates.

But where and how should you define these rules? On one hand, they are the domain of the model because most underlying data stores have requirements that must be met to store data. And because an MVC model is the proper location for business rules, it seems clear that they go in the model as well.

On the other hand, however, it is usually the user interface that needs to take a hand in enforcing the rules and helping the user provide the correct data by displaying error messages when she tries to save data that is missing a field. An input field of type text for the company name might have the max length attribute set to 50, to prevent the user from even entering too many characters in the first place. The user interface clearly has a role to play in data validation.

So where should you implement data validation, in the view or the model? The good news is that with an MVC model there is a clear answer: the model. You add attributes to the properties and classes that implement the model that define the data validation rules, and you can add other data annotations that guide how the view should use the properties of the model. The view can then look at those rules and annotations, and then enforce the rules and appropriately modify how it displays the data to the user. The view’s role in data validation is to take the rules defined in the model—without defining any of its own—and provide a user interface that enforces those rules.

Best of all, since the rules are part of the model, they’ll be in effect no matter where you use the model, across all views and controllers. There is no need to duplicate the rules anywhere in the application. This is an application of the DRY principle of an MVC application: Don’t Repeat Yourself.

James Curtis

This post is an excerpt from the online courseware for our MVC 4.0: Working with Data course written by expert James Curtis.

James Curtis  is a .NET Developer that primarily works in the UX space. He has worked on and for several large projects alongside Microsoft Consulting. James has spoken at several code camps about UX development for ASP.NET and SharePoint. He is an active participant in the development community tweeting and blogging about several topics in the UX area. James is an active consultant and is also assisting in several Start-ups contributing his UX experience.

Document Sets

Thumbnail for 597When users work with documents, there are occasions where more than one document is related to a particular task or project. In the past a user might group these together within a folder in a SharePoint document library. However there are some drawbacks to using folders:

 

  • Users can sometimes find folders to be unwieldy and confusing, particularly when deeply nested.
  • Folders do not permit the documents to be acted upon as a group, but rather serve simply as a container.

SharePoint 2010 introduces a new feature, known as Document Sets, to address this situation. As the name implies, a Document Set is a special content type that allows the grouping of related documents.

While a Document Set is similar to a folder conceptually, it holds some distinct advantages over folders:

  • Document Sets appear as a single item in a library, and thus represent a user-friendly alternative to multiple levels of nested folders.
  • Document Sets support versioning, and may be versioned independently of the documents they contain.
  • Document Sets support metadata columns that can convey information about the set, such as the current state in a submission process.
  • Document Sets can be manipulated by workflows, permitting the entire set of documents to be treated as a single entity.

Before Document Sets can be used the Document Sets site collection feature must be activated. In order to use Document Sets in a particular library, the library must allow management of content types and must include the Document Sets content type.
The default behavior for the Document Set content type is to permit the user to add multiple documents to an instance of the type. However, the sets can be customized so that a specific number and type of document are automatically included in the set. As an example, a Document Set for a sales proposal might always include a spreadsheet for sales numbers, a presentation to pitch the proposal, and a document outlining the terms of the proposal. You can create a custom content type that inherits from Document Set and tailor it to meet the exact number and kind of documents needed.

Each Document Set has a welcome page associated with it. You can customize this page via the browser and SharePoint Designer to make it easy and convenient for users to consume.

John.UnderwoodThis post is an excerpt from the online courseware for our Microsoft SharePoint 2010: Enterprise Content Management course written by expert John Underwood.

John Underwood is a technical evangelist for a SharePoint consulting company, with 30 years of programming experience, including 20 years on the Microsoft platform and 10 years with .NET. John also has extensive experience using, configuring, and programming SharePoint.