4

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!

jaco0646
  • 15,303
  • 7
  • 59
  • 83
Mike Moore
  • 7,228
  • 10
  • 42
  • 63
  • 2
    Better yet: why don't you use javascript to generate the form when the user clicks the link. Then he wouldn't have to reload the page. – Artefacto Aug 03 '10 at 03:23
  • Well, I have not yet stepped into ajax and am trying to keep it simple. – Mike Moore Aug 03 '10 at 03:25
  • 1
    Well, I was not suggesting ajax (though that's a good idea). The form could still be submitted in a normal fashion; it was just a matter of creating the form dynamically (or just include it in the HTML and change the display from none to block). – Artefacto Aug 03 '10 at 03:32
  • @Artefacto - Thank-you for the recommendation. I will probably eventually build in more javascript, but I am building a system that I will maintain independently and made an initial decision to not rely on javascript unless absolutely necessary. For example, I am utilizing javascript for a "image rearranging" script. Thanks as your idea is a good one! – Mike Moore Aug 03 '10 at 03:35
  • Hi Mike, I believe you have implemented the State pattern for your case. Do you mind sharing the code sample? – XuDing Mar 19 '14 at 02:07

2 Answers2

4

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.

staticsan
  • 29,935
  • 4
  • 60
  • 73
0

The more I use design patterns, including the State pattern in PHP, the more I'm convinced that they save time. Initially, it may take longer to develop, but not much longer. However, when it comes to change and update, they save huge amounts of time. Your code is better organized, clearer and less likely to through a bomb into your code that you get with the tight binding outside of design patterns. I've done several PHP design patterns at php5dp.com, but, nothing in a State dp.

Bill Sanders
  • 31
  • 3