Dealing with Form submissions

Hi,

I'm new to TBS and am wondering what the best way to deal with HTML forms is.  I am big on removing all PHP and all strings from my HTML forms and defining that in the underlying PHP page, but when it comes to processing forms, I'm a bit confused.

Take the example below, for instance:

****************

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">

<h2>Iniciar la Sesión</h2>
<fieldset>
    <legend>Meta sus datos abajo </legend>
    <ol>
        <li>
            <label for="username">Nombre de Usuario <em>(Mandatorio)</em></label>
            <input id="username" name="username" class="text" type="text" size="30" maxlength="25" value="<?php if (isset($_POST['username'])) echo $_POST['username']; ?>" />
        </li>
        <li>
            <label for="password">Contraseña <em>(Mandatorio)</em></label>
            <input id="password" name="password" class="text" type="password" size="30" maxlength="25"/>
        </li>
    </ol>
</fieldset>

<fieldset class="submit">
    <input class="submit" type="submit" name="submit" value="Login" />
</fieldset>

</form>

*************************

Question 1:  For the form action "<?php echo $_SERVER['PHP_SELF']; ?>" is the recommendation to replace this with a variable placeholder and then define the action in the underlying PHP page?  Thus, it would read something like:  <form action="[var.form_action]" method="post"> with the variable [var.form_action] being defined as "<?php echo $_SERVER['PHP_SELF']; ?>" in the PHP page?  Or is this taking the whole "separation of PHP from HTML too far"?

Question 2: What about the "sticky" form fields (e.g.: <?php if (isset($_POST['username'])) echo $_POST['username']; ?>) ?   What is the TBS view on reproducing this functionality in a form using TBS?

Sorry in advance if these questions have been answered in the forum before, but I looked high and low and could not find the answer...

Thanks,

Ian

Well, I managed to get this working using placeholders for both the form action attribute [var.form_action] and the sticky form field for username [var.sticky_username].  The $form_action variable is set with the value '$_SERVER['PHP_SELF']' and the $sticky_username variable is set with the value '$_POST['username']' within a conditional (which checks to see if the POST superglobal has anything set for the 'username' key)...

Not sure if this is the "best practice" in this area, but it works great.

Please let me know if anyone has a better way to handle this.

- Ian

Hi Ian,

I would code it like this:
as all browsers would post the form to the same page when action is not specified. But if you really want to explicitly write it you would simply code it as
Likewise, for "sticky" fields you could use The nice trick about the ;noerr part is that if $_POST['username'] is not set, tbs simply replaces the entire variable with empty string instead of complaining about it, which is effectively what you want to achieve.

In both examples, we took advantage of the fact that $_SERVER and $_POST superglobals are already defined by php, so they can be used in tbs var fields just like user defined variables. Also note that array slots can be reached in tbs with [var.arrayName.arrayIndex] syntax, which we also took advantage of, in both of the examples.

Hope that helped.
ege.

Hi Ege,

Thanks so much for weighing in on this.  I'm definitely pretty new to PHP coding so every little bit helps to round out my knowledge.  Regarding your suggestion to use of an empty "action" attribute on the form rather than the "PHP_SELF" reference - is there any risk/downside of leaving this blank?  I guess the coding books I consumed all recommended using "PHP_SELF" rather than leaving that blank when submitting the page to itself...  I do know that there are some concerns around using PHP_SELF from an XSS attack perspective, so that may be a compelling reason on its own to go with the empty Action attribute...

Anyway, I'd love to hear more of your thoughts around any potential downside of this method, if any.  Does it always work would be my main question...

Thanks as well for the TBS tips for the sticky form field setup with "noerr".  That will definitely come in handy.

Regards,

Ian

Hello again,

As far as empty action fields are concerned, the only downside I can think of is that some browser (or user agents) might not be supporting it. I haven't checked the html specification about the issue, but it's a known and common trick to leave it blank, I would say that almost all known and decent browsers, including the ones designed for cell phones and palms, support it. I have been using it in almost every project and haven't received any complaints or bug reports about it. I currently produce 7-9 web sites every year I think I have enough experience about it to conclude that there seems no harm using it in standard applications.

One concern would be about whether the resulting html would comply with xhtml standards (if you choose to use it). As far as I can see, pages that contain empty form actions validate perfectly on transitional 1.0 xhtml doctype as long as the action attribute is not missing altogether. That is, <form method="post" action=""> is o.k, but <form method="post"> is not. It is stated that action attribute is mandatory and should contain a valid URI. So the discussion comes down to whether an empty uri is a valid uri. One should really check the uri specification about it, but I think it's probably ok, since w3c's validators haven't thrown an error or warning about my empty actions.

Finally, results on a quick googling on the issue has no serious objections about it:
http://www.thefutureoftheweb.com/blog/use-empty-form-action-submit-to-current
http://carehart.org/blog/client/index.cfm/2007/1/2/form_self_post

Regards.
ege.

Perfect.  Thanks for the background on the empty 'action' attribute and self-posting.  I think I'll start using that from here on out and save myself some typing... :)

Best,

Ian