Say, that you are handling a multi-step process (like a complex registration form, with a number of steps the user has go through in order). You need to be able to save the current state of the process (e.g. so the user can come back to that registration form later and continue form the step where they were left off).
Obviously, you’ll probably want to give each “step” an identifier you can refer to: 1, 2, 3, 4, etc. Your logic will check for this step_id (or whatever you call it) to render the appropriate data.
The question: how would you identify the stage after the final step, like the completed registration state (say, that you have to give that last “step” its own id, that’s how your logic is structured). Would it be a 0, 999, a non-integer value, something else entirely?
I wouldn’t store a step_id at all, as you’re just limiting yourself in the future. Break it down into 2 groups of orders:
- Incomplete order
- Complete order
Just use a boolean to store that. So you only have to worry about incomplete orders now (which are proportionately few compared to the total number of orders in your system). Now every required detail that they have to enter has to be it’s own field:
- Name
- Street
- City
- etc.
Now in the future you may want to divide your steps up in various ways. There’s a tendency now to move away from steps and towards a single long page where the user can jump around and enter it in whatever order they want, but there might be steps.
So when you reconstitute an incomplete order, you have something like:
OrderStep currentStep(Order incompleteOrder)
{
if(!step1FieldsComplete(incompleteOrder))
{
return OrderStep.One; // silly naming, I know, but give it more meaningful name
}
}
bool step1FieldsComplete(Order incompleteOrder)
{
return
incompleteOrder.Name != null
&& incompleteOrder.Street != null
&& ...;
}
Now, when you want to move fields from one step to another, or merge 2 steps into one, you have lots of flexibility, and the code will even work if you add new fields in a previous step that the customer already filled out. When they come back they’ll just be bumped back to the step with the new field.
I would consider something like a state table (or stage table (or step table)). This table would consist of an ID and a Description, and potentially anything else you feel needs to be associated with a state/stage/step. Just try to find some sort of relevant descriptor about each step – this hopefully wouldn’t be too difficult.
1 – Start
2 – Personal Info
3 – Address Info
4 – Another state
5 – Completed
Ideally, additional steps would not be added down the road, but captured up front in the design process. Just a thought.
People like to count in order, so systems like this often involve sorting the pages by ID number. Page IDs tend to go in steps of 10, though any arbitrary number can be chosen. This allows you to later insert pages between existing pages without renumbering any existing pages.
Using an unusually high value such as 999 for the final page allows you to insert any reasonable number of pages without having to renumber your final page. This is perfectly reasonable.
10 Start page
20 Welcome
30 Select products to install
35 Configure products <-- Page inserted later
40 Select folder to install to
50 Confirm installation
60 Display install progress
999 Finished
I wouldn’t really make a table with numeric identifiers but more something like this:
Current | Next
--------------
Start | Page1
Page1 | Page2
Page2 | End
End |
This way you can easily fit a page in between. And your end page would be the one with an empty(nil) Value.