Is the state design pattern overkill for a PHP form?

Question

I have a page that, when accessed displays a table of information related to a video:

• Embed code
• Title
• Description
• Current gallery
• Thumbnail image

This information is read-only when the page is first accessed.

There is a select menu that has the following options:

• Edit Description
• Create Thumbnail (Upload/Replace)
• Edit embed code
• Change Gallery
• Delete video

When the user selects an option, the same initial table of data is displayed, but the relevant form input is displayed where necessary.

For example, if "Edit Description" is selected, the page reloads and the description text is replaced with a text input. If "Create Thumbnail" is selected, then a file upload input is displayed.

The idea is to display all of the information together but to limit how much can be edited at a time.

I know the state pattern is a possible solution, since each piece of data can be in atleast one of two states:

1. Display State
2. Form input state

But, my question is, would using the state pattern be overkill?

At the moment, each time the page is accessed, each part of the form decides with a switch statement whether it should be in 'display' or 'input' state and then acts accordingly. I wonder if implementing the state pattern design would make altering the form and creating similar forms easier down the road.

Thanks!

Answer 1

No, the state design pattern isn't overkill. It's probably a very good choice of algorithm for handling such a complex interface. I've used state engines in PHP several times; it helps you think creatively about the problem and you often get a bonus in flexibility.

I wish more programmers knew of such things.