If you’ve heard of LightSwitch before today, you may know that LightSwitch apps support both rich client out-of-browser and in-browser web applications. It does this because the primary user interface of LightSwitch applications is rendered in Microsoft Silverlight. Silverlight is an application framework for writing Rich Internet Applications (RIAs). It takes a subset of the .NET framework and Windows Presentation Foundation (WPF) and makes it available across Windows and Macintosh platforms.
While Silverlight is a mature application framework, LightSwitch is designed to support multiple clients for each application project. In the Visual Studio 2012 release of LightSwitch, Microsoft has the Silverlight clients available. In the Visual Studio 2012 Update 2 release a new HTML5 Client is added, designed for mobile and tablet touch scenarios. The model-driven architecture of LightSwitch allows additional clients to be added in the future allowing you to extend your application’s reach, creating user experiences that take advantage of the platform on which they run.
The Silverlight-based user interface is the most sophisticated today, designed to allow users to have multiple windows open at a time and switch between them with tabs. We’ll focus on the Silverlight desktop experience, which may be more comfortable for today’s .NET developers, knowing that we are insulated from changing technology standards by LightSwitch model- and service-driven architecture. At any point in the future you can add an HTML client and reuse the data, services, and business logic in a new mobile optimized application.
If you are familiar with the Silverlight presentation framework, you might be expecting to write some XAML to design your user interface. Unlike writing a Silverlight application, when developing in LightSwitch you don’t need to know XAML. The LightSwitch screen designer saves the layout of the screen and generates Silverlight controls based upon your layout and data types.
The added advantage of this design pattern is that you really just describe the data and the layout in the LightSwitch modeling environment. As technologies evolve, new output types may be added to future releases of the LightSwitch product. The HTML client adds to LightSwitch the ability to automatically generate touch-optimized HTML and JavaScript applications with a Model-View-ViewModel (MVVM) architecture. While it’s not possible to claim an application is future-proof, the model-driven development environment of LightSwitch captures your data, logic, and layout in an XML file and auto-generates the application code for you, insulating you significantly.
When you need more control of the UI, you can drop down to the XAML level by plugging in some custom code called a Silverlight user control. While this extensibility is very powerful and gives you unlimited control over the user interface, you may need to revisit these customizations in future releases of the LightSwitch product as you are actually writing code.
In the previous chapter, we defined the entities that represent the structure of our data. In this chapter, we will define the user interface, which is composed of one or many screens to lay out the data in our entities. With that introduction, we are ready to go. Let’s build some screens.
You should still have the project open in Visual Studio from the previous section where you created your data model. In the Visual Studio Solution Explorer, go ahead and right-click and choose Add Screen. This will bring up the Add New Screen dialog where you can choose from a number of professionally designed screen templates, as you see in Figure 6-1.
As you can see in Figure 6-1, we’ve chosen to create an Editable Grid Screen for our Tickets data. You can always change the name of your screen if you need to. We’re going to leave the default screen name for now because we can always set a Display Name for the page when we edit the navigation later.
When you click OK, the screen designer loads with your newly created page. In this case, you want this to be a read-only grid for tickets with a pop-up dialog box for adding or editing new tickets. LightSwitch makes it easy for us to turn the editable grid into a read-only grid. In order to make this happen, select the Data Grid Row for the ticket on the left and click on Use Read-only Controls in the Properties window on the right (see Figure 6-2). You’ll notice that the icons next to each of the controls in the control hierarchy change as the TextBoxes automatically change to Labels and the DateTimePickers become DateTimeViewers.
It’s that simple to create a screen. Let’s repeat the process and create a screen for our People entity.
Right-click on Screens in the Solution Explorer.
Choose Add Screen.
Click on Editable Grid Screen.
Choose People from the Screen Data drop-down list.
Click OK.
Choose Data Grid Row | Person from the screen designer on the left.
Click Use Read-only Controls in the Properties window on the right.
That’s it! You created two screens that will allow you to browse and do some basic CRUD operations. You’ve successfully built a multitier application with a database, WCF Data Services, and a Silverlight user interface. You didn’t open SQL Server Management Studio, didn’t write a single line of Transact SQL code, and you didn’t create a web services project, write a Web Services Definition Language XML description of our service (WSDL), or configure service endpoints. You also didn’t create a Silverlight project, consume those services, write a view model, write some XAML screens, or configure security across all these tiers. It would take you a week at least to do all these things even if you were an expert in all these technologies.
Before hitting the Play button to start debugging, let’s go ahead and add one more Editable Grid Screen for Queues following the same steps we completed for the People grid screen. Figure 6-3 shows the environment in which you can do this; we won’t break out the exact steps again.
Each of the controls you see displayed above is a part of the screen controls hierarchy. The default control is automatically selected based on the type of the property and whether it is part of a relationship. When LightSwitch visualizes a related property, by default it will provide an auto-complete box based on the Summary property in the related entity. If you had thousands of people in your system, an auto-complete box might be slow or overwhelming due to the number of entries. In that case, you can customize the Manager auto-complete box and choose to display it as a Modal Window Picker. The Modal Window Picker allows you to pop up a dialog box where you can search a related entity. Given the small size of this application, just leave the default auto-complete here.
When you start debugging, you’ll notice that a new Windows rich-client application is started. As mentioned earlier, Silverlight apps can either run in a browser or be hosted in the Silverlight launcher process that you see in Figure 6-4.
Let’s add some sample data starting with some people. Select the Editable People Grid from the Tasks menu on the left. Then click on the plus to add new items.
Note
Because we selected Email Address as our Business Type when we designed the entity, LightSwitch automatically added validation logic to ensure that the entered string matches the format of an email. This logic is generated both in the service layer and in any screens that consume the entity automatically.
Let’s try out some of the validation and user interface enhancements offered by business types in LightSwitch. In Figure 6-5, we attempted to enter an invalid email address of “georgeW@whitehouse,” but we did not include a domain suffix after the period. The field is highlighted as invalid and an error is added to the collection of validation issues at the top of the screen, as you can see in Figure 6-5. All of this is done without any additional effort by the developer. Simply selecting a Business Type allows us to greatly enhance our application with proper validation.
In addition to validation, Business Types can also provide custom user interface interaction. Take a look at the phone number example in Figure 6-5. After entering a 10-digit number, the LightSwitch screen automatically formats the number with parentheses and a dash.
When you click the drop-down to the right side of the field, a custom editor is displayed that provides inputs for Country Code, Area Code, Local Number, and Extension. These inputs are automatically combined and stored in a string with proper formatting. Once again, no code or additional development is needed to add this to the screen. Just by selecting the Business Type in the data entity designer, you defined this string as a Phone Number Business Type and LightSwitch did the rest.
Let’s just fix up the sample data we entered so that we have valid data, and add a couple of rows. You’ll notice that each of these rows in Figure 6-6 has an indicator to the left of it. This indicates that even though we’ve added these rows to the grid, they have not yet been saved back to the database. If we were to close this window, LightSwitch would prompt us to save our changes before doing so. We could have also clicked Save on the toolbar after adding our data, but LightSwitch provides this additional check to make sure we don’t lose any data.
Had we been writing this application in ASP.NET or most other platforms, we would have needed to add additional JavaScript to implement our data in the client, run validation checks, highlight unsaved rows, and provide a user interface to execute a save. LightSwitch automatically generates all this functionality for us, which allows us to focus on the business logic.
After we save our entries into the People table, it’s time to go
ahead and create a couple of tickets. Notice that we can see that our
status successfully defaulted to new based on the one line of code we
wrote in the created event of our Ticket entity during the “Setting
Default Values” section of Chapter 5. Looking at
Figure 6-7, we can see
that we automatically have a drop-down list of Requestors based on our
related Person entity. LightSwitch has automatically rendered this
related table as a drop-down list and shown us the FullName property as the Summary property.
Not a bad user interface for free, but there are some things we’ll want to clean up. We should not let the user select the date created, date updated, or date closed—these need to be automatically managed. We should also do some further automation around status. While we have the right default status, when the ticket is assigned to someone, we need to flip the status to assigned. Let’s stop the debugger and go back to Visual Studio to implement these changes using a custom dialog box called a modal window.
In addition to the automatic layout and rendering of screens, Visual Studio LightSwitch allows you to create custom grouping of controls and choose how they are displayed. One style people commonly use to lay out controls is a modal window. You may want to show a custom modal window when adding or editing records to make efficient use of screen real estate as this window will pop up over your screen just like a dialog box.
Highlight the top of the control hierarchy on the screen designer and drop down the Add menu. You’ll see this is the list of items you can add to the screen below the Data Grid (see Figure 6-8).
We’re going to add a new group into which we can place the controls for our custom modal dialog or what we might call a pop-up window. When we add this new group to our screen layout, we’ll see it default to a rows layout.
A rows layout basically amounts to a vertical stack panel in SilverLight or a group of controls that will be arranged each on a separate line stacked vertically. This is not quite what we’re looking for, so we’ll click on the drop-down list and select Modal Window, as shown in Figure 6-9.
A rows layout is just one type of formatting that can be applied to a collection of controls known as a control group. Figure 6-9 shows several types of styles that can be applied to a control group. These control groups are how you lay out and style groups of controls within your pages. They can also be nested within each other to create complex layouts. For example, you can use a modal window to create a new ticket, and then have a rows layout to arrange each of the fields as a separate row.
Once we’ve added the new group and selected a modal window as shown in Figure 6-9, add some controls to a group as shown in Figure 6-10 by dragging the selected item of the Ticket entity from the list of data items on the left to just underneath the modal window layout control on the right.
Because we chose to drag on a selected item that has multiple fields, LightSwitch needs to create a group to lay out those fields. When we drop the selected item, Visual Studio will automatically create a rows layout group inside our modal window and add each of the controls. If there are controls that we don’t want to display, we can delete just them or toggle their visibility.
Using the Properties window on the right, uncheck the visible flag on DateCreated, DateUpdate, and DateClosed. We don’t want our users to manipulate them or even see them when creating a new ticket. In Figure 6-11, you can see that the dates are not visible.
You can also see that the Properties window shows that we set the Description to have a height of five lines. Leaving the controls in place and toggling visibility acts as a reminder to make sure we’ve added the code to manage these dates correctly, which we will do in Chapter 7.
By default, Status would be rendered using a picker control because it’s related from another table. Using the drop-down control picker on the screen designer, we can also change the Status to be a label, making it read-only on this modal window.
In this section, we learned about the role of screens within LightSwitch to display the data from our entities. We’ve learned how to manage the layout of data via control groups, which can display data as rows, columns, in a modal window, or in a variety of other ways. Finally, we learned how to manipulate the display properties of the individual controls using the Properties window. In the next section, we will enhance our application by implementing business logic.