Comparing Against Other Fields/Properties

The comparison type drop-down allows you create a filter that compares by property. This lets you compare two fields from the same record. After you choose the Property option, LightSwitch displays a second drop-down box that allows you to specify the comparison property.

Figure 6-7 shows a query that allows you to find issues that have overrun by returning issues where the close date exceeds the target end date.

Passing Arguments into a Query

Rather than using a hard-coded literal value, you can make queries more reusable by creating parameters. To create a parameter, choose the Parameter option from the comparison type drop-down list. After you select the parameter option, a second drop-down box appears that allows you to either create a new parameter or select an existing parameter (if one exists).

If you choose to create a new parameter, the parameter appears in the Parameter section in the lower part of the query designer.

You can make parameters optional by checking the Is Optional check box. If the user doesn’t set the value of an optional parameter at run time, LightSwitch won’t apply the filters that use the parameter. Optional parameters are ideal for creating search queries that filter on multiple fields. If the user doesn’t supply search criteria for any given field, LightSwitch simply omits the filter clause during execution.

Filtering by Global Values

If you filter by the Date or DateTime property, you can choose to filter by a set of global values that LightSwitch provides. These include Today, Start Of Week, End Of Week, and several others. (See Figure 6-8.)

If you filter on a DateTime property, take care when applying the equals operator with the Today global value. For example, the Issue table contains a field called ClosedDateTime. If you want to create a query that returns all queries that are closed today, the filter ClosedDateTime=Today won’t work.

This is because Today returns today’s date with a time of 12:00:00am. To apply the correct filter, you have to use the is between operator and filter the ClosedDateTime property between Today and End Of Day.

Therefore, the Start Of Day option is perhaps a better description for the value that’s returned by the Today global value.

Sorting Data Grids

When you display data on a grid, users can toggle the sort order by clicking on the column headings. The column header includes an arrow that indicates the sort order that’s currently in use (as shown in Figure 6-10).

LightSwitch retains the column header sort sequence between sessions, and it even restores the sort sequence after the user closes and reopens your application.

The problem with this behavior is that a user can’t clear the grid sort order and return to the initial sort sequence that you intended.

To give an example, let’s say you’ve created an Editable Engineer Grid screen that uses a query that sorts the data by surname followed by first name. If the user opens this screen and sorts the data by priority, there isn’t any way for the user to return to the initial sort sequence of surname followed by first name.

Therefore, if you create grid screens that use queries that are sorted by multiple properties, it makes sense to disable sorting to prevent this problem from occurring. To do this, uncheck the Support Sorting check box for your query in the screen designer.

Examining User Setting Files

To explain the grid sort behavior, LightSwitch retains the user settings for your application in the following path, which appears below your Documents folder (or My Documents on a Windows XP machine): MicrosoftLightSwitchSettings

In this folder, there’ll be a subfolder for every LightSwitch application that you’ve run on your computer. Inside each application folder, you’ll find a .SortSettings file for each screen in your application. (See Figure 6-11.) This is an XML file that contains the user sort orders for the screen. Users could manually clear their sort settings by deleting this file.

In this folder, you’ll find various other files. If a user resizes the widths of the columns on a data grid, LightSwitch persists these settings between sessions in the .ColumnSettings file. LightSwitch uses the remaining files to retain the state of the application, navigation, and ribbon settings. To illustrate one of these XML files, Listing 6-1 shows you the contents of the Application.OutOfBrowser.WindowSettings file. LightSwitch uses the data in this file to reopen your application in the same screen position as your last session.

Listing 6-1.  Contents of Application.OutOfBrowser.WindowSettings

<?xml version="1.0" encoding="utf-8"?>
<OutOfBrowserWindowSettings
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Top>10</Top>
  <Left>360</Left>
  <Width>1077</Width>
  <Height>604</Height>
  <WindowState>Normal</WindowState>
</OutOfBrowserWindowSettings>

Understanding LINQ Syntax

LINQ is used throughout LightSwitch, so it’s important to understand how to construct a query with LINQ. Once you start learning LINQ, you’ll soon discover that you can express queries using two different types of syntax: Query Syntax and Method (or Lambda) Syntax.  

You’ll commonly find Query Syntax in documentation, and it’s generally more readable. (It looks a bit like SQL.) You’ve already seen some examples of Query Syntax in this book. The screen code that undeletes records in Listing 5-10 is one example.

Figure 6-14 shows a snippet of Query Syntax code and highlights the parts that make up the query. The query belongs in an engineer details screen and is designed to return a collection of open issues sorted in date descending order.

Every query needs a data source, and in this sample, the Engineer.Issues navigation property is the data source. Because the code belongs in a details screen, Engineer refers to the Engineer query that’s created by the details screen template.

The engIssue variable is called the range variable. This behaves just like the iteration variable in a for-each loop, although no actual iteration takes place in a LINQ query. This variable allows you to reference each element in the data source and conditionally filter the results by using a where clause.

The compiler infers the data type of engIssue. Therefore, there’s no need for you to explicitly declare this as an Issue object.

The select clause at the end of the statement specifies the type of each returned element. This allows you to return only a subset of properties from the Issue entity, if required.

An important point about LINQ is that queries are executed when the code first tries to work with the query, and not on the line that contains the select clause. This characteristic is called deferred execution.

In this example, the query’s data source is the Issues navigation property on a local property. Therefore, LightSwitch will carry out the filtering locally on the client.

Understanding Method (Lambda) Syntax Code

Although Query Syntax is generally easier to read and write, there are certain operations that you can perform only with Method Syntax. Retrieving the element with the maximum value in a source sequence is an example.

Method Syntax queries are characterized by lambda expressions, and you’ve already seen a few examples in this book.

Figure 6-15 illustrates the same query as before, but expressed using Method Syntax rather than Query Syntax.

Standard Query operators define the operations you want to perform, such as filtering or ordering. You can control the way that many of these operators work by supplying a lambda expression.

Using Standard Query Operators

Standard Query operators are extension methods on top of the objects that implement the IEnumerable or IDataServiceQueryable interface. The operators you can use depend on the data source that you’ve chosen.

There are over 50 Standard Query operators you can apply when you’re working with navigation properties. As well as the where and orderby operators, there are many other useful operators that you can use. For example, you can apply various aggregate operators, such as count, min, max, and average.

Filtering Data with Lambda Expressions

Let’s take a closer look at the where operator and lambda expression from Figure 6-15:

C#  Where(engIssue => !engIssue.ClosedDateTime.HasValue)
VB  Where(Function(engIssue) engIssue.ClosedDateTime.HasValue= false)

The where operator expects you to pass in a Func delegate that returns a Boolean. The return value indicates whether the supplied value (engIssue) meets the criteria for inclusion in the where clause.

engIssue is called the lambda parameter. This represents a single issue in the collection of issue responses that you’re working against. This code uses .NET’s implicit data-typing feature, which saves you from having to define the data type of engIssue. You could equally write the expression like this:

C#  Where((Issue engIssue )=> !engIssue.ClosedDateTime.HasValue)
VB  Where(Function(engIssue As Issue) engIssue.ClosedDateTime.HasValue= false)

If you want to construct more complex query expressions, you can do so by using the navigation properties that your lambda parameter exposes.

In the C# version, the lambda parameter must be enclosed in brackets if you’re not using implicit typing. Brackets must also be used if you want to specify more than one lambda parameter.

In C#, the => operator is called the lambda or goes to operator. This separates the lambda parameter or parameters from the actual expression.

In Visual Basic, the Function keyword specifies the lambda expression and the lambda parameters are defined inside brackets following the Function keyword. Visual Basic developers might find it strange to see the Function keyword used without a function name being specified. For example, a typical function in Visual Basic looks like this:

Public Function GetIssue (issueId  As Integer) As Issue

As you can see, the function name here is called GetIssue. In the lambda expression code, you can omit the function name because the syntax uses a feature of .NET 3.5 called anonymous methods. Before .NET 3.5, methods had to be explicitly named, which would have resulted in you having to write more code.

The final part of the lambda expression tests to see if the ClosedDateTime value is null. If true, the query returns the record in the results.

Using the Any and All Operators

Two useful Standard Query operators that you can use are the Any and All methods. The All method returns a Boolean that indicates whether or not all elements of a sequence match a condition, whereas the Any method returns whether or not any element satisfies a condition.

The code in Listing 6-2 finds whether or not there is at least one issue in the database with a priority set to high. Because the data source is the outstandingIssues query (shown in Figure 6-15), the query searches only open issues.

If you want to run the code that's shown in this section, the first part of Chapter 7 will give you more detail. In Chapter 7, you'll find out how to display your query results on your screen by adding local screen properties.

Listing 6-2.  Using the Any Standard Query Operator

VB:
File:HelpDeskVBClientUserCodeEngineerDashboard.vb
  
Dim highPriorityExists As Boolean =
    outstandingIssues.Any(
        Function(engIssue) engIssue.Priority.PriorityDesc = "High")
C#:
File:HelpDeskCSClientUserCodeEngineerDashboard.cs
  
bool highPriorityExists =
   outstandingIssues.Any(
         engIssue => engIssue.Priority.PriorityDesc == "High");

The code in Listing 6-3 returns whether or not all issues that have been open for more than seven days are closed, and it demonstrates the use of the All query operator.

Listing 6-3.  Using the All Standard Query Operator

VB:
File:HelpDeskVBClientUserCodeEngineerDashboard.vb
  
Dim oldIssueExists As Boolean =
    Engineer.Issues.Where(
        Function(engIssue) engIssue.CreateDateTime < DateTime.Now.AddDays(-7)).All(
            Function(engIssue) engIssue.ClosedDateTime.HasValue)
C#:
File:HelpDeskCSClientUserCodeEngineerDashboard.cs
  
bool oldIssueExists =
   Engineer.Issues.Where(engIssue =>
      engIssue.CreateDateTime < DateTime.Now.AddDays(-7)).All(
         engIssue => engIssue.ClosedDateTime.HasValue);

Performing For Each Logic

A neat little method that you can use is the ForEach extension method. This allows you to supply an Action delegate that defines some logic that you want to carry out against each element in a sequence.

Listing 6-4 shows you how to build a string that shows the top-5 oldest issues.

Listing 6-4.  Using the ForEach Operator

VB:
File:HelpDeskVBClientUserCodeEngineerDashboard.vb
  
Imports System.Text
  
Dim sb As StringBuilder = new StringBuilder()
  
outstandingIssues.OrderByDescending(
    Function(engItem) engItem.CreateDateTime).Take(5).ToList().ForEach(
        Function(engItem) sb.AppendLine(engItem.ProblemDescription))
C#:
File:HelpDeskCSClientUserCodeEngineerDashboard.cs
  
using System.Text;
  
StringBuilder sb = new StringBuilder();
  
outstandingIssues.OrderByDescending(
    engItem => engItem.CreateDateTime).Take(5).ToList().ForEach(
       engItem => sb.AppendLine(engItem.ProblemDescription));

The first part of the code retrieves the top-five oldest records by ordering the issues in date descending order and calling the Take method to retrieve the first five records in the sequence.

The ForEach extension method belongs to the type List<T>, so you need to call the ToList method to return a list of issues.

The code inside the ForEach method then builds a list of the issue descriptions by using a StringBuilder object. At the end of this process, the code would display the contents of the StringBuilder object on the Engineer Dashboard screen.

Querying Data Remotely

When you’re writing queries, it’s important to consider where the query executes. Take a look at the code that’s shown in Listing 6-5.

Listing 6-5.  Querying Data Collections

VB:
File:HelpDeskVBClientUserCodeEngineerDetail.vb
  
Dim startOfYear = New DateTime(DateTime.Now.Year, 1, 1)
  
'Query 1
Dim issuesLastMonth =
    Engineer.Issues.Where(
        Function(issueItem) issueItem.CreateDateTime > startYear).
            Count()
  
'Query 2
Dim issuesLastMonth2 =
    Engineer.IssuesQuery.Where(
        Function(issueItem) issueItem.CreateDateTime > startYear).
            Execute().Count()
  
  
C#:
File:HelpDeskCSClientUserCodeEngineerDetail.cs
  
DateTime startOfYear = new DateTime(DateTime.Now.Year, 1, 1);
  
//Query 1
var issuesLastMonth =
    Engineer.Issues.Where(
        issueItem => issueItem.CreateDateTime > startOfYear).Count();
  
//Query 2
var issuesLastMonth2 =
    Engineer.IssuesQuery.Where(
        issueItem => issueItem.CreateDateTime > startOfYear).
            Execute().Count();

This code exists on an Engineer details screen, and both queries are designed to return engineer issues that have been created since the start of the year. Although query 1 looks very similar to query 2, there’s a big difference between the two code samples.

The data source for query 1 is a navigation property. Navigation properties are of type EntityCollection<T>, and any queries that you perform on a navigation property are executed by LightSwitch locally.

The code in query 2 calls the <CollectionName>Query method. This returns an IDataServiceQueryable, and LightSwitch remotely executes any filtering that you define against this object.

Considering that each engineer could be associated with hundreds or even thousands of issues, it’s much more efficient to perform this specific query remotely. However, a common pitfall with remote queries is that they won’t include any entities that have been added locally. Therefore, you’ll need to consider this behavior when you’re writing remote queries.

Figure 6-16 shows you the actual SQL that’s executed by SQL Server by highlighting the output from SQL Server Profiler. This output proves that when you use <CollectionName>Query as a data source, SQL Server carries out the filtering, not LightSwitch.

Querying Data Locally

Although it might seem more efficient to perform your querying remotely, there are good reasons to query your data locally. If the data that you want to use is already loaded on the client, it’s quicker to query the data that’s already loaded.

Also, not all standard query operators support remote execution, or there might be application features that you want to create that can be achieved only with a local query.

To demonstrate such a feature, here’s a screen that allows engineers to enter the time that they’ve spent on issues. This screen includes a button that merges time entries that refer to the same issue. Figure 6-17 illustrates how the screen functions.

To create this example, carry out the following steps:

1. Add the TimeTracking table to your project. You’ll find the schema of this table in Appendix E.
2. Create a detail screen, and base it on the Engineer table. In the Add New Screen dialog, make sure to include the TimeTracking data collection.
3. When the screen designer opens, add a new button and bind it to a new method called MergeDuplicateIssues. Add the code that’s shown in Listing 6-6 to this method.

Listing 6-6.  Querying an EntityCollection

VB:
File:HelpDeskVBClientUserCodeEngineerTimeTracking.vb
  
Dim duplicates =
    From timeEntry In Engineer.TimeTracking
    Group timeEntry By timeEntry.Issue Into issueGroup = Group, Count()
    Where issueGroup.Count() > 1
    Select issueGroup                                                           
  
For Each dup In duplicates
   Dim totalDuration = dup.Sum(Function(timeEntry) timeEntry.DurationMins)
   Dim firstLine = dup.First
   firstLine.DurationMins = totalDuration                                       
   dup.Except(New TimeTracking() {firstLine}).ToList().ForEach(
      Sub(timeEntry) timeEntry.Delete())                                        
Next

  
C#:
File:HelpDeskCSClientUserCodeEngineerTimeTracking.cs
  
  
var duplicates =
    from TimeTracking timeEntry in this.Engineer.TimeTracking
    group timeEntry by timeEntry.Issue into issueGroup
    where issueGroup.Count() > 1
    select issueGroup;                                                          
  
foreach (var dup in duplicates)
{
    var totalDuration =
        dup.Sum(timeEntry => timeEntry.DurationMins);
    var firstEntry = dup.First();
    firstEntry.DurationMins = totalDuration;                                    
    dup.Except(
        new TimeTracking[] { firstEntry }).ToList().ForEach(
        timeEntry => timeEntry.Delete());                                       
}

This code uses several of the features that you’ve covered in this section. The TimeTracking table stores the amount of time that an engineer has spent on an issue. The first part of the code groups the TimeTracking records by issue and selects groups that contain more than one time-tracking record .

The second part of the code loops through the collection of grouped records, sums the total duration into the first record , and deletes the remaining records in the group .

Notice how the code uses the Except operator, along with the ForEach operator that you saw earlier.

Filtering by Related Child Items

If you create a query that uses the issue table, the graphical designer allows you to filter the results by engineer. In other words, the graphical designer allows you to filter by parent records. Working in the other direction, however, a query that’s based on the engineer table can’t be filtered by a property in the issue table. Figure 6-18 illustrates how the drop-down box in an Engineer query doesn’t contain an entry for Issue.

To filter by child items, you’ll need to write some custom code. To demonstrate this, here’s how to create a query that returns engineers with outstanding issues.

Right-click on the Engineer table in Solution Explorer, and create a query called EngineersWithOutstandingIssues. Click on the Write Code button, and select the PreprocessQuery method. When the code editor opens, enter the code that’s shown in Listing 6-7.

Listing 6-7.  Filtering by Child Items

VB:
File: HelpDeskVBServerUserCodeApplicationDataService.vb
  
Private Sub EngineersWithOutstandingIssues_PreprocessQuery(
   ByRef query As IQueryable(Of Engineer))
  
     query = query.Where(Function(engItem) engItem.Issues.Where(
       Function(issueItem) issueItem.IssueStatus.StatusDescription = "Open").Any())
End Sub
  
  
C#:
File: HelpDeskCSServerUserCodeApplicationDataService.cs
  
partial void EngineersWithOutstandingIssues_PreprocessQuery(
    ref IQueryable<Engineer> query)
{
    query = query.Where
        (engItem => engItem.Issues.Where(
            issueItem => issueItem.IssueStatus.StatusDescription == "Open").
            Any());
}

The PreprocessQuery method includes a parameter called query that allows you to reference the query’s output. So to further customize your query, you would append your additional query operators to this parameter. Notice how this example uses the Any operator that was covered in Listing 6-2.

Exists, In

This example demonstrates how to perform an exists or in type query. This type of query returns records where related child records exist. For example, you can use this type of query to find issues that are associated with one or more records in the issue document table. If you’re more conversant with SQL, Listing 6-8 provides the SQL equivalent to illustrate what this example strives to achieve.

Listing 6-8.  SQL Equivalent of the Exists Query

SELECT  *
 FROM Issues
WHERE IssueID IN (
    SELECT IssueID FROM IssueDocuments)

To create this example, create a query called IssuesWithAttachments. Click on the Write Code button, select the PreprocessQuery method, and enter the code that’s shown in Listing 6-9.

Listing 6-9.  Returning All Issues with Related Issue Document Records

VB:
File: HelpDeskVBServerUserCodeApplicationDataService.vb
  
Private Sub IssuesWithAttachments_PreprocessQuery(
   ByRef query As IQueryable(Of Issue))
    query = query.Where(Function(issueItem) issueItem.IssueDocuments.Any())
End Sub
  
C#:
File: HelpDeskCSServerUserCodeApplicationDataService.cs
  
partial void IssuesWithAttachments_PreprocessQuery(
    ref IQueryable<Issue> query)
{
    query = query.Where (issueItem => issueItem.IssueDocuments.Any());
}

Not Exists, Not In

As a natural progression of the previous example, this example shows you how to perform a not exists or not in type query. This type of query returns records where no related child records exist.

This example demonstrates a query that returns all issues without any issue-response records. Just like before, Listing 6-10 shows the equivalent SQL that you would use to perform this query.

Listing 6-10.  SQL Equivalent of a Not In Query

SELECT  *
 FROM Issues
WHERE IssueID NOT IN (
    SELECT IssueID FROM IssueResponses)

To carry out this example, create a query called IssuesWithNoResponse and add the code shown in Listing 6-11 to the PreprocessQuery method of your query.

Listing 6-11.  Returning Issue Records Without Any Issue Responses

VB:
File: HelpDeskVBServerUserCodeApplicationDataService.vb
  
Private Sub IssuesWithNoResponse_PreprocessQuery(
   ByRef query As System.Linq.IQueryable(Of LightSwitchApplication.Issue))
      query = query.Where(Function(issueItem) Not issueItem.IssueResponses.Any())
End Sub
  
  
C#:
File: HelpDeskCSServerUserCodeApplicationDataService.cs

  
partial void IssuesWithNoResponse_PreprocessQuery(ref IQueryable<Issue> query)
{
    query = query.Where(issueItem => !issueItem.IssueResponses.Any());
}

Filtering by Date Elements

The ability to filter by date elements is a common scenario. Finding people who were born on a given day and month is a typical example.

This example shows you how to create a query that allows users to find all issues that were raised during a specified month and year.

To allow your user to specify the month and year, create a query on the Issue table called IssuesByMonthAndYear and create two integer parameters, called IssueMonth and IssueYear. (See Figure 6-19.) Set the Is Optional property of both of these parameters to true.

Now add the code that’s shown in Listing 6-12 to the PreprocessQuery method of your query.

Listing 6-12.  Filtering by Month and Year Parameter Values

VB:
File: HelpDeskVBServerUserCodeApplicationDataService.vb
  
Private Sub IssuesByMonthAndYear_PreprocessQuery(
    IssueMonth As System.Nullable(Of Integer),
    IssueYear As System.Nullable(Of Integer),
    ByRef query As System.Linq.IQueryable(Of LightSwitchApplication.Issue))

  
    If (IssueMonth.HasValue And IssueYear.HasValue) Then
        query = query.Where(
            Function(item) item.CreateDateTime.Month = IssueMonth.Value AndAlso
                item.CreateDateTime.Year = IssueYear.Value)
  
    End If
  
End Sub
  
C#:
File: HelpDeskCSServerUserCodeApplicationDataService.cs
  
partial void IssuesByMonthAndYear_PreprocessQuery(
    int? IssueMonth, int? IssueYear, ref IQueryable<Issue> query)
{
    if (IssueMonth.HasValue && IssueYear.HasValue)
    {
        query = query.Where(
            item => item.CreateDateTime.Month == IssueMonth.Value &&
            item.CreateDateTime.Year == IssueYear.Value);
    }
}

To create a screen that uses this query, you can simply create an editable grid screen that’s based on this query. As with all other parameterized queries, LightSwitch automatically creates text boxes that allow the user to supply the required values.

Top N Records

This final example shows you how to create a query that returns the top n records from an entity set. To demonstrate this technique, this example shows you how to create a query that returns the top five issues with the highest feedback rating.

If you’ve not done so, create a (zero-or-1)-to-many relationship between the Issue and IssueFeedback tables. (You’ll find the schema for the IssueFeedback table in Appendix E.) Create a query based on the Issue table called IssuesWithHighestFeedback. Now add the code that’s shown in Listing 6-13 to the query’s PreprocessQuery method.

Listing 6-13.  Query to Return Issues with the Highest Feedback

VB:
File: HelpDeskVBServerUserCodeApplicationDataService.vb
  
  
Private Sub IssuesWithHighestFeedback_PreprocessQuery(
   ByRef query As System.Linq.IQueryable(Of LightSwitchApplication.Issue))
  
    query = query.OrderByDescending(
        Function(issueItem) issueItem.IssueFeedback.Average(
            Function(feedback) feedback.OverallRating)).Take(5)
End Sub

  
C#:
File: HelpDeskCSServerUserCodeApplicationDataService.cs
  
partial void IssuesWithHighestFeedback_PreprocessQuery(
   ref IQueryable<Issue> query)
{
    query = query.OrderByDescending(
    issueItem => issueItem.IssueFeedback.Average(
        feedback => feedback.OverallRating)).Take(5);
}

Each issue item can have multiple issue-feedback records. So to calculate a value that the query can use to sort the issues, the code works out the average feedback that’s assigned to each issue. The important part of this code is the take method—this is a method that allows you to retrieve the top five records.

To improve this code further, you could add a parameter to allow the user to choose the number of records to return, rather than use a hard-coded value of 5.

Adding Your Global Value to Your LSML File

First, you need to append the global value definition to your Common project’s LSML file. Switch to File View, and open the file Common Properties Common.lsml.

Add the code in Listing 6-14 to the end of your file, just before the </ModelFragment> tag.

Listing 6-14.  Global Value Definition to Add to the LSML file

<GlobalValueContainerDefinition
  Name="GlobalDates">
  <GlobalValueDefinition
    Name="SevenDaysAgo"
    ReturnType=":DateTime">
    <GlobalValueDefinition.Attributes>
      <DisplayName Value="7 days Ago" />
      <Description Value="Today minus 7 days." />
    </GlobalValueDefinition.Attributes>
  </GlobalValueDefinition>
</GlobalValueContainerDefinition>

The name of the GlobalValueContainerDefinition needs to match the name of the class that you’re about to create. In this example, it’s been named GlobalDates.

Each global value is defined within a GlobalValueDefinition element. The ReturnType attribute specifies the data type for your global value. The acceptable values that you can use include :String, :Int32, :Decimal, and :Boolean. Appendix B shows a full list.

Note that these values are case sensitive. Visual Studio will not load your project if you get the casing wrong.

Creating the Global Value Class

The next thing to do is to write the code that does the computation. Switch to File View, and create a new class in your Common project. An ideal place to create this class is in the User Code folder (if it exists). LightSwitch creates this folder if you’ve written any entity code.

The name of your class needs to match the name that’s defined in your GlobalValueContainerDefinition element (GlobalDates in this example). Enter the code that’s shown in Listing 6-15.

Listing 6-15.  Code to Return Date

VB:
File: HelpDeskVBCommonUserCodeGlobalDates.vb
  
Imports System
  
Namespace LightSwitchCommonModule
  
    Public Class GlobalDates
  
        Public Shared Function SevenDaysAgo() As DateTime
            Return DateTime.Now.AddDays(-7)
        End Function
  
    End Class
  
End Namespace
  
C#:
File: HelpDeskCSCommonUserCodeGlobalDates.cs

  
using System;
  
namespace LightSwitchCommonModule
{
    public class GlobalDates
    {
        // The name of the GlobalValueDefinition
        public static DateTime SevenDaysAgo()
        {
            return DateTime.Now.AddDays(-7);
        }
    }
}

The new class contains Visual Basic shared or C# static methods for each GlobalValueDefinition element that you defined in your LSML. The method name needs to match the name that you’ve defined in the GlobalValueDefinition element, and the namespace of your class must be set to LightSwitchCommonModule.

Your new global value is now ready for use. Whenever you filter a query on a date-time property, you’ll be able to select 7 Days Ago as a global value.

Using Global Values in Upgraded Projects

If you’ve added an HTML client application (as discussed in Chapter 8) or have upgraded your project after installing Visual Studio 2012 Update 2, the instructions that you’ll need to follow are slightly different. Upgraded projects no longer include a Common project. Therefore, the LSML file that you’ll need to modify will exist in the following locations, depending on your project’s language:

• VB Projects: YourApp.serverMy Projectservice.lsml
• C# Projects: YourApp.ServerPropertiesservice.lsml

Locate your service.lsml file, and add the GlobalValueContainerDefinition block from Listing 6-14 to the end of your file, just before the </ModelFragment> tag. After you do this, create a folder called UserCodeShared in your server project, and add your GlobalDate class file to this folder. When you create your GlobalDate class, you need to modify the code in Listing 6-14 by changing the namespace of your class from LightSwitchCommonModule to LightSwitchApplication.