Section Expanders in LightSwitch HTML

Section Expanders in LightSwitch HTML

Overview

Apps created with LightSwitch HTML client are mobile first as the UI is based on jQuery Mobile. This post introduces a way to organise form data with section expanders that are often found in desktop app scenarios.

Default Mobile First Style

In the mobile style of pages the data is typical displayed in one or two columns and related data is visualized in tab sections. Here is an example of a default View screen with details on the first tab and related information located on separate tabs.

Tab Sections in LightSwitch HTML

In many ways the styling is a matter of taste and there are several ways of presenting larger volumes of information in common use. Using the in-built View Details Screen template the screen content layout looks like this:

View Details Screen Layout

The screen content is organized into parent tabs and the tab layout uses the Columns and Rows Layout controls.

Designing the Layout and Behaviour

In desktop application scenarios the answer to how to display large amounts of data fields has often been to use section expanders. Very often for line-of-business apps a combination of tabs, expanders and pop-ups is used to try and provide an optimal user experience.

If you want to give your LightSwitch apps a more Desktop UX feel there is nothing stopping you from implementing similar styles and behaviours.

The first step is to organise the screen content layout into sections. Each section will have a visible border box to group related information. The first header section in this example will be static. Subsequent sections will be expandable and will be displayed by default as collapsed.

Screen Content Layout for Expanders

The sections are marked up: Header, Attributes and Tracking

The expandable sections contain a custom control for the expander header and the rest of the section content is (Not Visible) to start. Let us take the first example above, with the layout hierarchy:

Expander Content Items Layout

The section’s top Rows Layout will:

• Handle _tap event to toggle the section details visibility

The section’s Custom Control will:

• Render the expander header

The section details Rows Layout will:

• Block _tap events from bubbling up to its parents
• Display the section border box in _postRender

Implementing the Expander

Firstly we will attend to the rendering of the expander header:

Render Expander Header Custom Control

I have set all the CSS attributes in the _render code here for directness. You should really use a custom CSS class. You can experiment with the CSS attributes for different visual impact. The sample variable _attributeExpanderHeader should be scoped to the screen. You could include icons as part of the visual feedback.

Then complete the visual changes by adding code to the section details group content item like this:

Expander Section Details

The CSS styles place a border box around the sections details. The Tap action is bound to showTab Details – this stops the tap event bubbling up.

Then finally on to the section’s top level group control to handle the tap event to expand and collapse the section details.

Toggle the Expander Section Visibility

The toggle event flips the isVisible setting and handles the rendering of the bottom border of the expander hander. You could experiment with icons here.

Conclusion

With a little screen content layout design work, some CSS styles and a toggle event you can introduce section expanders to you control portfolio in LightSwitch TML client apps.

Advertisement

Tab Header Styling in LightSwitch HTML Apps

Tabs Style in LightSwitch HTML App

Overview

The default appearance of the tab headers in your Cloud Business Apps and LightSwitch HTML Apps can be customized to make them look more appealing and looking a lot more obvious to the end-users.

This post shows you which CSS classes and attributes to change to achieve tab headers that look like retro card index tabs.

Examples and Samples

This is the style of tab headers that we will show to create.

Rounded Corner Tabs Styling

Some simply rounding of a corner can give a card index file type appearance.

Card Index File Style Tabs

The CSS styling customizations required can be made in one place that is then picked up by all screens and pop-up dialogs. Here is a similar styling in another app but with a more rounding to blend in with the apps style.

Round Tab Headers in a Pop-up Dialog

You can see the visual impact readily. Clearly you can use any HTML5 CSS styling that you like once you have access to the classes and elements. The simplest way to do this is to override some of the CSS styling by editing the ‘user-customization.css‘ file located in the HTML Client ‘Content‘ folder.

user-customization.css in solution explorer

At the top of this file you can add a section to change the styling of your project’s tab headers. Here is the first example:

msls-screen-tab css class

The CSS classes involved are:

• msls-screen-tab
• msls-screen-tab-active
• ui-btn-inner

In this case the border-top-right-radius is setting the rounding effect. The CSS attributes needed will vary based on the complexity of your apps style sheets. In this example the existing style sheets have no border rounding.

In the second sample, where the app’s border styling is already rounded, a few more attributes need to be overridden for the full effect.

msls-screen-tab complete border rounding

In this case the border top left radius continues to be inherited from the main style sheet and so matches the apps other visual elements, such as buttons. The top right border is given more rounding to extenuate the visual effect of a card index header. To finish the look, the apps default rounded styling is overridden in the bottom border corners.

You can experiment with other attributes from font properties to background effects.

Conclusion

A simple way to add a bit of card index style to your tab headers. Not all Cloud Business Apps and LightSwitch HTML Apps need to look the same.

Using Table Value Functions to Replace ‘Get’ Stored Procedures?

I learnt so many useful techniques, tricks and pointers at this SQLBits conference in York: tally tables, common table expressions (CTEs), cross applies, query tuning techniques, parallelism, data visualisation, to name but a few. However, the most useful technique I learnt was divulged in the first couple of hours during the training session given by Rob Farley.

In amongst the banter, jokes and excursions, a la Geordie comedian Ross Noble, was a complete gem which will make a huge difference to our existing and future projects.

Put simply, never use stored procedures for simple retrieves, but replace these with Inline Table-Value Functions (TVF).

Given our love of stored procedures, this is a difficult pill to swallow at first, but the benefit can be seen through the following example…

Suppose we have written a stored procedure that returns a dataset to the business layer of the application. In our case, we will have delivered the dataset via a WCF service.

Our stored procedure might be something like:
CREATE PROCEDURE dbo.usp_MyTable_Get (@FilterParms…)
AS
BEGIN
SELECT T.Column1, T.Column2, T.Column3, LT.Column2, …
FROM dbo.MyTable AS T
INNER JOIN dbo.MyLookupTable AS LT ON LT.IDCol = T.Column4
WHERE T.ColumnN = @FilterParm1
…
END

Now suppose that the application development team ask for an additional column to be included in the returned dataset. This may be because the dataset returns a foreign key identifier and the developers need to see the lookup description in the returned dataset. To return the lookup value we need to include an additional join on the lookup table.

Before going ahead, we’d confirm that the developer hasn’t or can’t get the lookup description from content held in memory; we’d explain that we’ll need to create a new stored procedure just for this situation, or, we’ll need to include it in the existing one which will (unnecessarily) adversely impact performance for instances where the service is used but the additional column is not required.

We have seen this situation many times and it is frustrating that an optimum one-size-fits-all solution hasn’t presented itself – until now…

The solution is to replace the stored procedure with an inline TVF which includes every possible join for foreign key lookups and every possible output column, and then build up SQL SELECTs on this TVF with the required columns relevant to each individual situation, letting the Query Optimizer exclude joined tables where necessary.
So, the above stored procedure is replaced with:

WCF Service
public List GetMyTable(dtoRequiredColumns, dtoParameters, dtoFilter)
{
List dtoOut = new List()
string strSQL = ""

foreach (col in dtoRequiredColumns)
{
if (col.IsRequired) strSQL += ", " + col.Name
}

strSQL = "SELECT" + strSQL.Substring(2) + " FROM dbo.tvfMyTableGet"

// add any WHERE and ORDER BY clause

SqlDataAdapter SqlDataAdapter = new SqlDataAdapter(strSQL, SQLConnection)
DataTable dtResult = new DataTable()
SqlDataAdapter.Fill(dtResult)

foreach (DataRow drRow in dtResult.Rows)
{
// add row to dtoOut
}

SqlDataAdapter.Dispose()

return dtoOut
}


and the TVF definition is something like the following:

CREATE FUNCTION dbo.tvfMyTable
RETURNS TABLE
RETURN
SELECT T.every column…,
LT1.everycolumn…,
LT2.everycolumn…,
LT3.everycolumn…,
…
FROM dbo.MyTable AS T
INNER JOIN dbo.MyLookupTable1 AS LT1
ON LT1.IDColumn = T.ForeignKeyID1
INNER JOIN dbo.MyLookupTable2 AS LT2
ON LT1.IDColumn = T.ForeignKeyID2
INNER JOIN dbo.MyLookupTable3 AS LT3
ON LT1.IDColumn = T.ForeignKeyID3
…
GO
So the function includes every column in MyTable, and is joined to every table that provides a lookup for foreign keys.

And here’s the clever thing, at run-time the optimizer looks at which columns are included in the SELECTed column list and excludes those JOINs on tables that are not required for that particular query. In addition, query plans are cached (however, note that different length string parameters will generate additional cached plans).

The objections might go something like – underlying data is made more secure by placing these behind a stored procedure ‘firewall’. Of course, just as with stored procedures, we can grant execute permission to the function and not the underlying tables or views. And, this looks like dynamic SQL, which is bad! But, we are not allowing any injection to take place here – the listed columns are defined within the dtoRequiredColumns object and full control of the ‘dynamic SQL’ is maintained.

Here at last is the one-size-fits-all solution, so thanks go to Rob Farley for this.

Read more from Rob Farley’s Blog here .