Form process flow

Get Started
1

I have a form called “Add an Article” that is just for me to populate my site.

Right now, the page “add_article.php” displays the form.

On data entry errors, the form is re-displayed with error messages.

On success, the page is re-displayed with a message that says, “Congratulations! The article ‘<article name here>’ was added to the database.”

On failure (e.g. database issue), the page is re-displayed with an error message that says, “Insert failed! Please contact the System Administrator.”

Questions:

1.) Is it okay to submit a form onto itself like that?

2.) What is the best way to handle the “process flow” after a record is successfully entered into the database?

I was thinking of adding a button at the bottom that says “Insert another record”?

I’m getting confused how to handle all of these Registration/Log-In/Add-a-Record/etc forms and how the “flow” should be handled?!

Thanks,

Debbie

2

It’s a personal choice, but I handle from processing similarly. Obviously, if you have a MULTI-PAGE form it may not be suitable to have the action set to itself unless you dont mind not allowing progress in to the next part until the previous part is validated.

But thats complicating the issue.

Submitting a form onto itself is almost standard practice; it allows for logical grouping of validation.

  1. if form has been submitted check it.
    1a. if it fails validation || save to DB, output error message, clear fields with error, remember correct fields.
    1b. if it passed validation && SAVE TO DB utput success message ( or failure o save), and navigation
  2. if form hasnt been submitted or fails validation… output form
    2a. if form has already been submitted include $_POST fields as value ( saves people from having to retype the fields that passed validation)… this step would be more complex if the form wasn’t being submitted to itself.

What you are doing seems fine. At the end of the process i would add the “insert another record” button and a “return to main menu” button ( if haven’t already done so)

Hope that helps.

3

Maybe after I add an Article I should echo back what was entered and add a small message somewhere also confirming, “Your article has been added!” and then the two buttons you mentioned at the very end?

Debbie

4

sorry. I thought you already had a confirmation message as part of it.

Yes confirmation messages FIRST and foremost, for either occurrence (enter/fail).

IN FACT, a trick I use to optimize my PHP is setting a variable such as $err=“”. I add all error messages into $err. if at the end of the validation / database update $err is NOT empty my script echos $err and re outputs the form, else it echos " your data has been entered (or such)" and navigation for the user.

5

But I do.

The user is on the form, submits it, and if the data is valid then the page is re-loaded with either a “Insert Succeeded” or “Insert Failed”.

I was asking if I should echo what they just inserted - similar to how I can “Preview” this response to you.

What do you think about that?

And then I said that I could have an “Enter another record?” button OR a “Return to ____ page?” button at the very bottom.

What do you think about that?

Debbie

6

By preview do you mean the final output or do you mean the form is reloaded with all the data they have imput?

really if you have a preview my first concern would be EDIT. Nothing sucks more than to see you made a typo after pressing confirm ( yea, it happens), and feel you have to struggle to find a way to correct it.

Inset another record is a nice courtesy that gets diminishing returns. think about it, in the beginning of populating a DB this is really useful. when you spend 2 nights in arrow just inserting records, but then your site is done… and you only punt one or two new records a week… hmmm

on the other hand, if that you “confirmation page” had was a general menu, of which one button pointed to a node which was a logical start for a new record it would be far more useful in the long run. For example, most for the CMS I design just show:

[GENERAL NAVIGATION including" record control: Add Record | Edit Records | Delete Record]

The preview as seen by the END USER.
----- EDIT THIS RECORD----

I hope you see what I mean by all this

7

I mean displaying the data that was INSERTed into the database after the fact. (I guess that is a “Post-View” and not a “Preview”?!) :lol:

really if you have a preview my first concern would be EDIT. Nothing sucks more than to see you made a typo after pressing confirm ( yea, it happens), and feel you have to struggle to find a way to correct it.

You know… I am starting to think that creating a simple web form like we are talking via is like a 20,000 hour project?!

God is this hard!!!

(I haven’t even thought about giving people edit capabilities yet?!)

Inset another record is a nice courtesy that gets diminishing returns. think about it, in the beginning of populating a DB this is really useful. when you spend 2 nights in arrow just inserting records, but then your site is done… and you only punt one or two new records a week… hmmm

I have no clue what you are saying here?! :-/

on the other hand, if that you “confirmation page” had was a general menu, of which one button pointed to a node which was a logical start for a new record it would be far more useful in the long run. For example, most for the CMS I design just show:

[GENERAL NAVIGATION including" record control: Add Record | Edit Records | Delete Record]

The preview as seen by the END USER.
----- EDIT THIS RECORD----

I hope you see what I mean by all this

Nope. :lol:

Here is what I am doing… (I forgot how I started this thread!!)

Right now I am making myself a web form to enter Articles. It will allow me to go from Article Files to Article Records.

Once I get that working, then I want to create a way for Members to comment on my Articles. (Similar process flow, but requires more security and more options like we are discussing.)

If a Member is on “Postage Meters can save you money” and wants to comment, then things should go like this…

  • Member must be Logged In or Log In
  • Member is taken to an “Add a Comment” form
  • Member types in a TEXT comment
  • Member hits “Submit”
  • System displays Success/Failure message
  • System holds Comment in queue for Admin to approve
  • System re-displays Article with Comments at bottom again

After New Comment is approved…

  • System displays Article with all Comments sorted Newest to Oldest and display below the Article

Having a fancy Rich Text Editor like here at SitePoint, and a Preview button and the ability to edit the comment before and after it is made is way down the line for me. (Unless you wanna help me out here?!) :smiley:

Debbie

8

nothing good is EVER easy, dont be discouraged.

Reverse order… I have made SIMPLE editors with JS… too much trouble. Incorporate TinyMCE and VOILA!

So this is all for viewers posting comments, not for data entry? The two should be VERY DIFFERENT documents if only for security reasons.

so this is in fact TWO jobs… 1) the CMS data entry and the other COMMENTS.

as far as handling comments comemments I would do this:

  • if a viewer is not logged in the “send comment form” is NOT displayed at all. PERIOD
  • when a member is logged in, then the form is displayed on any page where you want
  • Member types in a TEXT comment
  • Member hits “Submit”
  • System displays Success/Failure message along with the message that comment will not display till approved ( some idiot WILL keep sending the same comment over and over again because "he saw that it said it was approved, but… he didnt see it display right away). And don’t worry about allowing users to edit “comments”. Comments arent forums. User is still in the same page as before; new, clean blank comment form ( but with the “comment sent” message… so no need for anything else.
  • System holds Comment in queue for Admin to approve ( you figure this could take minutes or days.) but for all intents and purposes this is a moot point.
  • When comment is approved it displays along with all previous comment in your preferd order.

much easier and sensible…

9

Let’s hope I can get this done by next June 2012?! :frowning:

Reverse order… I have made SIMPLE editors with JS… too much trouble. Incorporate TinyMCE and VOILA!

Yeah, but that won’t help me out with the flow I’m talking about here.

So this is all for viewers posting comments, not for data entry? The two should be VERY DIFFERENT documents if only for security reasons.

My OP was about my admin “Add an Article” form.

But as I said, that will be the launching pad for my “Add a Comment” form as well.

I know they are different, with the second being much harder.

so this is in fact TWO jobs… 1) the CMS data entry and the other COMMENTS.

Separate, but related.

as far as handling comments comemments I would do this:

  • if a viewer is not logged in the “send comment form” is NOT displayed at all. PERIOD
  • when a member is logged in, then the form is displayed on any page where you want
  • Member types in a TEXT comment
  • Member hits “Submit”
  • System displays Success/Failure message along with the message that comment will not display till approved ( some idiot WILL keep sending the same comment over and over again because "he saw that it said it was approved, but… he didnt see it display right away). And don’t worry about allowing users to edit “comments”. Comments arent forums. User is still in the same page as before; new, clean blank comment form ( but with the “comment sent” message… so no need for anything else.
  • System holds Comment in queue for Admin to approve ( you figure this could take minutes or days.) but for all intents and purposes this is a moot point.
  • When comment is approved it displays along with all previous comment in your preferd order.

much easier and sensible…

So you don’t think I need to turn my “Add a Comment” into a full-blown SitePoint kind of thing?? :-/

Debbie

P.S. I have a pretty fancy workflow for the Comments, and can reveal it if you are curious.

10

My OP was about my admin “Add an Article” form.

But as I said, that will be the launching pad for my “Add a Comment” form as well.

I know they are different, with the second being much harder.

On the contrary, Adding a comment is easier… there is no need to validate ( except maybe for blanks) you don’t have too proof, you may not even need to display immediately. in other words the comment from is really part of your front end…

adding an article on the other hand is the CMS , part of your back end. this is one of those weird times in which doing two things is actually easier thann trying to do em as one.

So you don’t think I need to turn my “Add a Comment” into a full-blown SitePoint kind of thing??

Sitepoint ( or at least this area here) is not a blog. This is a forum… these aren’t comments ( or entries) these are threads. It doesnt sound like you are building a forum… but more like a blog or page in which YOU (the admin) POSTS… and others (members) comment. So I am saying it will be faster and more logical if you keep the ultimate function in mind rather than compare yourself to on site or another.

A comment is just a comment. :slight_smile:

As it stands you probably want to strip tags before you add comments into a DB ( just so that someone doesn’t actually use your comment form to override your page) … right? So why then, would you build a comment object that would allow them such amenities?

It is understandable that you wish those features for your back end. but not for comments. look at how many WP blogs handle comments, for example…)

11

Hmmm…

Debbie