How Can We Help?

Working with States

You are here:
< Back

SageTea is based on the Model View Controller software pattern, (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller). If you’re familiar with MVC, you can think of the data as the model, the UI as the view (screens), and the controllers are (clearly) the controller.

If you’re not familiar with the MVC pattern, you can learn more by visiting the Wikipedia page above. More detail is available there, but it says:
• Model: application data, business rules, logic, and functions;
• View: output representation of information such as charts and diagrams; and
• Controller: accepts input and converts it to commands for the model or view.

Text-to-Software lets you easily switch between UI, client controller, server controller, and web server controller states.
You’ll see different states when you’re in each of these views. When you are in UI states, you will see the screens of the application. As for the controller states, they’re a little different. Let me explain.

Using Controller States

The “controllers” of your application are the rules engines that do the work behind the scenes to connect your screens with your data. For example, the UI states (screens) display the graphical elements of your application, which is very important, but it’s static, not an active job. Without a client controller on your machine, the screen wouldn’t do anything. It would just sit there looking pretty. Without a client controller, you could see a nifty looking button that says OK on it, but when you pressed that button, nothing would happen.
It’s the client controller’s job to send messages like that to the server controller, and to receive messages back. Basically, the client controller tells the server controller that things have happened, that the user wrote something in a box or pressed a button. If the client controller worked in a restaurant, it would be a waiter. The waiter takes your order to the kitchen and brings out your food. But the waiter doesn’t make the food. The waiter communicates with the kitchen on your behalf and brings you the stuff the kitchen has done. That’s what the client controller does with the server controller—communicates on the user’s behalf and presents you with the work the server has done, in a way you can understand it.

To continue the analogy, the server controller represents the kitchen. The kitchen puts together your order, does what you ask it to do. But the kitchen has to work together with the waiter because the chef doesn’t come to your table to deliver your food. So without the client controller, the server would do a job like searching the database, but the results of that search would just stay in the background of the computer and you would never see it.

So, let’s say you’ve got a button that says “Check email.” The UI controller displays this button for you. When you press the button, the client controller sends a message telling the server controller that it’s time to check email. The server controller receives the message and checks for email. Then it passes the raw email data to the client controller. The client controller receives the email data and tells the UI state to display it. Then the UI state displays your email in a way that you (and not just a computer) can read it.

TO SWITCH BETWEEN STATE/SCREEN VIEWS
1. On the Requirements Analysis tab, in the States/Screens box, right-click a state.
2. Click one of the following options:
• Show UI States
• Show Client Controller States
• Show Server Controller States
• Show Web Server Controller States

Switching between State Screen Views

There are certain tasks you can only do while viewing the UI states and some you can only do while viewing the controller states.
Here’s how you switch the state you’re viewing.

TO SWITCH BETWEEN STATE/SCREEN VIEWS
1. On the Requirements Analysis tab, in the States/Screens box, right-click a state.
2. Click one of the following options:
• Show UI States
• Show Client Controller States
• Show Server Controller States
• Show Web Server Controller States

Adding, Renaming and Deleting Screens and States

The procedure for renaming a screen is the same as for renaming a state. Same for deleting a screen and a state.
NOTE! For information on how to create a screen using Text-to-software, see Creating Screens Using Text-to-Software.

TO ADD A SCREEN
1. On the Requirements Analysis tab, ensure you are viewing UI screens—Right-click in the States box and click Show UI States.
2. Right-click a field in the Fields box and click Become UI State.

TO ADD A CONTROLLER STATE
1. On the Requirements Analysis tab, ensure you are viewing a controller state—Right-click in the States box and click one of the following:
• Show Client Controller States
• Show Server Controller States
• Show Web Server Controller States
2. Right-click a field in the Fields box and click Become Controller State.
3. In the Choose the Parent State box, click a parent state.
3. Click OK.

NOTE! The parent state will be the model for the controller state. The state will be created with transitions and activities modeled on the parent state you choose.

TO RENAME A SCREEN OR STATE
1. On the Requirements Analysis tab, right-click a screen or state in the Screen or States box and click Rename.
2. In the Enter new name box, type a name for the screen or state.
3. Click OK.

TO DELETE A SCREEN OR STATE
1. On the Requirements Analysis tab, right-click a screen or state in the Screen or States box and click Delete.
2. Click OK.

Adding Activities to Screens

When you add an activity to a screen, it means that the forms it contains will be displayed on that screen in the application.
For a screen to be displayed in your application, it has to contain at least one activity.

TO ADD AN ACTIVITY TO A SCREEN
1. On the Requirements Analysis tab, ensure you are viewing UI screens—Right-click in the States box and click Show UI States.
2. Click an activity in the Activities box.
3. Right-click a screen in the Screens box and click Add Activity To Current State.

Removing Activities from Screens

If you added an activity to a screen, and then decide you don’t want it there, you can remove that activity from that screen. It is harder to remove an activity from a screen that has no activities.

TO REMOVE AN ACTIVITY FROM A SCREEN
1. Click the Requirements Analysis tab, ensure you are viewing UI screens—Right-click in the States box and click Show UI States.
2. Right-click a screen in the Screens box and click Remove Activity.
3. In the Choose the activity to remove box, click an activity.
4. Click OK.

Viewing the Contents of Screens and States

Whether you are viewing the controller states or the UI screens, you can easily check out the contents of a single state. Doing this will display a list of the transitions, activities, groups, and fields associated with the screen/state.

TO VIEW THE CONTENTS OF A SCREEN/STATE
On the Requirements Analysis tab, in the Screens or State box, right-click a screen/state and click View.

Making Screens Invisible

Invisible screens can’t be seen by users. They’re in your application, but users can’t see them.

So, why would you want to make a screen invisible? It doesn’t make much sense to do a bunch of work making a screen only to have it not appear to your users.
A couple of reasons you might want to do this:
• You’re adding a screen to the application, but it’s not finished yet, so you want to keep your work hidden for now.
• It’s an old screen that you decided not to use, but you’re not ready to let go of it yet (deleting is a permanent step).
• Maybe you merged an application into your application and it has screens you don’t want to show up.

TO MAKE A SCREEN INVISIBLE
1. On the Requirements Analysis tab, ensure you are viewing UI screens—Right-click in the States box and click Show UI States.
2. Right-click a screen in the Screens box and click Become Non-Visible.

TO MAKE A SCREEN VISIBLE
1. On the Requirements Analysis tab, ensure you are viewing UI screens—Right-click in the States box and click Show UI States.
2. Right-click a screen in the Screens box and click Become Visible.

Making Screens and States NON Start

States (and screens) are start states by default, but you can make any screen or state non-start.

TO MAKE A SCREEN OR STATE NON-START
1. On the Requirements Analysis tab, right click one of the following:
• A state in the State box
• A screen in the Screen box
Then click Become Non-Start State.

Previous Working with Smart Parts
Next Working with the SageTea Components in Text-to-Software
Table of Contents