Thank you all for your responses.
Mike.
I like the ii option better, mostly because I already have most of that in
place (ie. order posts to process, and process has editable fields and
hidden fields with the remaining complimentary values).
Martin suggested I use the following code for my update script (which is
posted to via the process page):
[code]
foreach($_POST as $key => $value)
if( '0' == $value || '' == $value )
{
/*if*/ session_is_registered( $key ) &&
session_unregister( $key );
}
[/code]
I am not following the logic on the above code very well, but is this indeed
a better option? And is not session_*whatever deprecated? The reason I am
using $_SESSION is because it seems that php 6 will use solely this method,
and it currently works with php 5. The other reason I am using it is so that
I can keep the variables stored elsewhere for whenever I need them; I don't
want to have to juggle all the information with POST and hidden inputs
unless it will work seamlessly, and be ready for update at a later date (if
I move to using a database to store show information, or when php 6 is
mainstream).
Keep in mind that once I get the update feature working, I need the process
page to have a final submit button that will insert the order into a
database table AND send a notification email to myself (and an email to the
user). Am I setting myself up for failure with this udate order option? I
ask because the update feature relies on a form, and are not forms limited
to one submit button?
Thanks all for your patience! I will work on this today and write back with
any further questions I can't figure out on my own. And if anyone has any
advice I will be checking my email regularly.
Allen
On Fri, Aug 14, 2009 at 7:52 AM, Ford, Mike <[email protected]> wrote:
> > -----Original Message-----
> > From: Allen McCabe [mailto:[email protected]]
> > Sent: 14 August 2009 06:58
> >
> > Here is some more complete code:
> >
> > [code = order_process.php]
> >
> > <?php
> > session_start();
> > // POST ALL $_POST VALUES, CREATE AS VARIABLES IN SESSION
> > foreach($_POST as $k=>$v) {
> > $_SESSION[$k]=$v;
> > }
> >
> > $thisPage="AFY"; //NAVIGATION PURPOSES
> > include("afyshows.php"); //CONTAINS ARRAYS FOR SHOW ENTITIES;
> > POPULATES
> > ORDER FORM
> > ?>
> >
> > . . .
> >
> > </p><form name="update" action="update_order.php" method="post" >
> > <!-- HIDDEN FORM VALUES FOR SESSION PURPOSES -->
>
> Er wait, no! Sessions and hidden form fields are generally alternative
> solutions to the same problem -- you shouldn't be putting the same values
> both in the session and in hidden form fields. In this case, I'm beginning
> to suspect that the hidden fields are the better solution, but there is a
> certain amount of personal preference in this.
>
> > <input type="hidden" name="School" id="School" value="<?php
> > $_SESSION['School']; ?>" />
> > <input type="hidden" name="Grade" id="Grade" value="<?php
> > $_SESSION['Grade']; ?>" />
> > <input type="hidden" name="Address" id="Address" value="<?php
> > $_SESSION['Address']; ?>" />
> > <input type="hidden" name="City" id="City" value="<?php
> > $_SESSION['City'];
> > ?>" />
> > <input type="hidden" name="State" id="State" value="<?php
> > $_SESSION['State']; ?>" />
> > <input type="hidden" name="Zip" id="Zip" size="9" value="<?php
> > $_SESSION['Zip']; ?>" />
> > <input type="hidden" name="Contact" id="Contact" value="<?php
> > $_SESSION['Contact']; ?>" />
> > <input type="hidden" name="Phone" id="Phone" value="<?php
> > $_SESSION['Phone']; ?>" />
> > <input type="hidden" name="Fax" id="Fax" value="<?php
> > $_SESSION['Fax']; ?>"
> > />
> > <input type="hidden" name="Email" id="Email" value="<?php
> > $_SESSION['Email']; ?>" />
> > . . .
> >
> > <?php
> >
> > function findTotalCost($b, $c) {
> > $total = $b * $c;
> > return $total;
> > }
> >
> > function writeResultRow($a, $b, $c, $d, $e, $f) {
> > if($a != '') {
> > echo "\n<tr>\n\t";
> > echo "<td'>".$b."</td><td>".$c."</td><td>".$d."</td>";
> > echo "<td>".$e."</td><td> </td><td><input type='text'
> > value='".$a."'
> > name='".$a."' id='".$a."' size='2'
> > /></td><td>=</td><td>\$".$f."</td>";
> > echo "</tr>";
> > }
> > }
> >
> > //SETS $Total_show_01 to PRICE * QUANTITY
> > //FORMATS TOTAL
> > //IF A QUANTITY IS ENTERED, WRITES THE ROW WITH CURRENT VARIABLES
> > $Total_show_01 = findTotalCost($shows['show_01']['price'],
> > $_SESSION['show_01_qty']);
> > $Total_show_01_fmtd = number_format($Total_show_01, 2, '.', '');
> > writeResultRow($_SESSION['show_01_qty'], $shows['show_01']['title'],
> > $shows['show_01']['date'], $shows['show_01']['time'],
> > $shows['show_01']['price'],$Total_show_01_fmtd);
> >
> > //ABOVE LINES REPEATED FOR ALL 38 ENTITIES (show_01 to show_38)
> >
> > ?>
> > . . .
> >
> > <input name="updates" id="updates" type="submit" value="Update"/>
> >
> > [/code]
>
> If I'm reading what you want to do correctly, it seems to me there are two
> obvious approaches to this:
>
> (i) Have a single form which posts back to itself, showing all the show
> information and requested quantities and calculated result fields (such as
> total cost); initially, this will have the calculated fields not displaying
> anything, and these will be (re)populated at each Update. Using this
> method, all your values are contained solely within the $_POST array.
>
> (ii) Have your initial form post to the process form, which then also posts
> to itself on Update. This process form will have visible fields only for
> values which can be changed, but *must* then contain hidden fields for all
> the other values which were originally passed in the $_POST array. This
> arrangement means that the process form always receives a full complement of
> values in the $_POST array -- either from the original form, or from hidden
> fields posted back to itself.
>
> This is all just coming off the top of my head, and I'm sure there are
> improvements/other solutions to be offered. Hope this will give you some
> things to think about, and maybe a pointer or two towards a satisfactory
> solution.
>
>
> Cheers!
>
> Mike
> --
> Mike Ford,
> Electronic Information Developer, Libraries and Learning Innovation,
> Leeds Metropolitan University, C507, Civic Quarter Campus,
> Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom
> Email: [email protected]
> Tel: +44 113 812 4730
>
>
>
>
>
> To view the terms under which this email is distributed, please go to
> http://disclaimer.leedsmet.ac.uk/email.htm
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
