A workspace's purpose within Finsemble is to save and restore the end user's window state and position. In other words, a workspace is simply a collection of windows that persist between sessions. Before we dive too deeply into it, it might be beneficial to revisit the definitions of component, workspace, and window.

What types of windows live in the workspace?

The easiest way to understand what is and isn't stored in the workspace is to ask yourself this question: "Does the component need to exist across multiple workspaces?" If the answer is "Yes," then it is not stored in the workspace. Our menus, toolbars, dialogs, and chat windows are not stored in the workspace.

In the diagram below, the red components are application-level components. They're workspace independent. The blue components are part of the workspace and will restore at the proper place when a new session is started. Workspace

Why the distinction between window and component?

We only allow one component per window. Despite the one to one relationship, windows have very different concerns from components. The window shouldn't concern itself with the symbol on the chart, and the chart shouldn't concern itself with where it is placed on the screen. The functional and semantic distinction allows us to speak more clearly when discussing problems. It also speeds up debugging—you don't need to look in the component to figure out an issue with the window's state.

Saving workspaces

By default, Finsemble does not automatically overwrite the stored state of a workspace. There is nothing stopping a developer from creating this kind of auto-saving feature; however, to demonstrate how workspace saving works out of the box, imagine the code below was run:

        name: 'myWorkspace'
    //This is what's pulled from storage.
    //myWorkspace = {
    //    name:'My Workspace',
    //    windows:['AdvancedChart1234', 'SimpleChart12333']

When FSBL.Clients.WorkspaceClient.load is invoked, the application will go off and find myWorkspace in the application's default storage. From there, it will load that data into the activeWorkspace. Any change that the user makes is persisted to activeWorkspace, not myWorkspace. Because we aren't automatically overwriting what the user has saved in storage, we need to know when to ask the user if they would like to overwrite their saved workspace.

When a window changes its state or position, it tells the Workspace Service that there's been a change in app or window state, and that the activeWorkspace should be considered "dirty." This only happens once. On subsequent state changes, all windows are aware that the workspace is dirty. Now, any UI that saves or loads workspaces can check if the workspace is "dirty"; if so, the program can ask the user if they'd like to save their changes before switching workspaces.

check   A workspace is a collection of windows whose state and position persist between sessions.

Further reading

Now that you have an understanding of what a workspace is, check out the Workspace API Documentation. It's full of helpful examples that will clarify and reinforce the information covered in this tutorial.

Understanding how the Finsemble application handles start-up will provide additional context. That tutorial can be found here.

To learn how components link and share data, proceed on to Linking.