Form Arrays

Hello,

I'm a new person when it comes to PHP and I have a quick question.

I would like to create a form that will allow the user to add more
information using the same form in case they have (similar to various
employment sites).

What would be the best way of using form arrays for that function?

Thank you,
Kevin

Re: Form Arrays

On Sep 4, 11:00 am, Kevin Davis wrote:
> Hello,
>
> I'm a new person when it comes to PHP and I have a quick question.
>
> I would like to create a form that will allow the user to add more
> information using the same form in case they have (similar to various
> employment sites).
>
> What would be the best way of using form arrays for that function?
>
> Thank you,
> Kevin

Hi Kevin,

I'm not sure exactly what you want to do...using your example of an
employment site...do you have a form that gathers a users employment
history, for example? And, if the employee has more than one previous
employer, to return to the same form so they can enter more
information? And, I assume, you do not want to submit the data to
persistent storage (ie database) until they are complete with the
form? If I'm off, let me know, just need clarification...

Re: Form Arrays

On Sep 4, 10:14 am, ELINTPimp wrote:
> On Sep 4, 11:00 am, Kevin Davis wrote:
>
> > Hello,
>
> > I'm a new person when it comes to PHP and I have a quick question.
>
> > I would like to create a form that will allow the user to add more
> > information using the same form in case they have (similar to various
> > employment sites).
>
> > What would be the best way of using form arrays for that function?
>
> > Thank you,
> > Kevin
>
> Hi Kevin,
>
> I'm not sure exactly what you want to do...using your example of an
> employment site...do you have a form that gathers a users employment
> history, for example? And, if the employee has more than one previous
> employer, to return to the same form so they can enter more
> information? And, I assume, you do not want to submit the data to
> persistent storage (ie database) until they are complete with the
> form? If I'm off, let me know, just need clarification...

Sorry about that I should added some claficiation.. The example would
be if the user has more than one previous employer and they have add
more until they are done. That is correct I don't want the user to
enter the information to the database until they are done.

Thanks..

Re: Form Arrays

On Sep 4, 11:36 am, Kevin Davis wrote:
> On Sep 4, 10:14 am, ELINTPimp wrote:
>
>
>
> > On Sep 4, 11:00 am, Kevin Davis wrote:
>
> > > Hello,
>
> > > I'm a new person when it comes to PHP and I have a quick question.
>
> > > I would like to create a form that will allow the user to add more
> > > information using the same form in case they have (similar to various
> > > employment sites).
>
> > > What would be the best way of using form arrays for that function?
>
> > > Thank you,
> > > Kevin
>
> > Hi Kevin,
>
> > I'm not sure exactly what you want to do...using your example of an
> > employment site...do you have a form that gathers a users employment
> > history, for example? And, if the employee has more than one previous
> > employer, to return to the same form so they can enter more
> > information? And, I assume, you do not want to submit the data to
> > persistent storage (ie database) until they are complete with the
> > form? If I'm off, let me know, just need clarification...
>
> Sorry about that I should added some claficiation.. The example would
> be if the user has more than one previous employer and they have add
> more until they are done. That is correct I don't want the user to
> enter the information to the database until they are done.
>
> Thanks..

OK, than you really have 3 options, the last 2 I'll mention has
several ways to implement each.

First, you can use database transactions. So, the solution would rely
more on the database rather than PHP. Basically, once the user starts
entering data, you open a persistent connection and start a
transaction. As data is added, modified, or deleted, you make those
changes to the database transaction. If errors popup, you do a
rollback. The data isn't actually saved in the database until you
commit the transaction. Good things are this makes it easier on the
PHP end, bad thing is the persistent connection, the overhead created
by talking to the database so much, and implementing a rollback on
data that wasn't saved incrementally could be bad news for your
customer (might have to enter in lots of data). I would be cautious
using this solution for your current situation, from what I see you're
doing.

Second, you use some form of data persistence between request,
typically using the SESSION superglobal or another form of filesystem
persistence. This one is the real PHP option. Here, you have to
(carefully) manage the data the user enters, often using some sort of
array mapping so you can update/delete/search for a particular record
within an array. So, if storing in $_SESSION, you could create a
single namespace for the type of data, and use it like an array stack
to hold the records so as to have a single location to manipulate it
and not pollute the namespace. Something like:

$employmentHistory = array();
array_push($employmentHistory, $record);
$_SESSION['employmentHistory'] = $employmentHistory;

Another option, which would probably be nicer to manipulate but would
generate additional overhead, would be to create an employmentHistory
object and serialize/deserialize them during the requests. This is
something I've done in the past.

Your third option, again, lives outside PHP. You could use javaScript
or another client-side scripting language to generate additional
records on page, as needed, before even submitting it back to the
server. While this potentially could clutter up the page if there are
many, it can often be done gracefully and well done. In this
situation, you would be looking at a DHTML solution, of which there
are many tutorials on the Internet to get you started, if you choose
this method. Generally, and increasingly nowadays, this solution is
being implemented more and more for situations like this. I've also
use this solution numerous times with great success.

So, that's a brief overview of how you can attack this problem. If
you need additional information on either of these suggestions, just
let me know.

Re: Form Arrays

Kevin Davis wrote:
> On Sep 4, 10:14 am, ELINTPimp wrote:
>> On Sep 4, 11:00 am, Kevin Davis wrote:
>>
>>> Hello,
>>> I'm a new person when it comes to PHP and I have a quick question.
>>> I would like to create a form that will allow the user to add more
>>> information using the same form in case they have (similar to various
>>> employment sites).
>>> What would be the best way of using form arrays for that function?
>>> Thank you,
>>> Kevin
>> Hi Kevin,
>>
>> I'm not sure exactly what you want to do...using your example of an
>> employment site...do you have a form that gathers a users employment
>> history, for example? And, if the employee has more than one previous
>> employer, to return to the same form so they can enter more
>> information? And, I assume, you do not want to submit the data to
>> persistent storage (ie database) until they are complete with the
>> form? If I'm off, let me know, just need clarification...
>
> Sorry about that I should added some claficiation.. The example would
> be if the user has more than one previous employer and they have add
> more until they are done. That is correct I don't want the user to
> enter the information to the database until they are done.
>

Very hard to add an infinite number of items and THEN commit.

Best is maybe to build a temporary thing and then make it permanent, or
delete it, if they commit/don't commit.

So using some form of persistent session Id set up a 'new set of
records' by

- creating a new header with their details, and the date inserting it
and returning a unique number for that person, but flag the record as
'unsubmitted' Carry that number as a POST variable through the whole
session.

-loop through a series of the same form adding more records linked to
the record_headers id. key.

- allow them at any time to review this

- when done hit the big red button, and all that you then do is flag the
master record as 'submitted'.

'unsubmitted' data can be cleaned up and deleted once every so often.

Viz. Run this every night.

delete from records, record_headers where
record_headers.flag='unsubmitted' and
records.header_id=record_headers.id and
(record_header.date+1)<(todays_date())

In sort of pseudo-SQL spik.





> Thanks..
>

Re: Form Arrays

ELINTPimp wrote:
> On Sep 4, 11:36 am, Kevin Davis wrote:
>> On Sep 4, 10:14 am, ELINTPimp wrote:
>>
>>
>>
>>> On Sep 4, 11:00 am, Kevin Davis wrote:
>>>> Hello,
>>>> I'm a new person when it comes to PHP and I have a quick question.
>>>> I would like to create a form that will allow the user to add more
>>>> information using the same form in case they have (similar to various
>>>> employment sites).
>>>> What would be the best way of using form arrays for that function?
>>>> Thank you,
>>>> Kevin
>>> Hi Kevin,
>>> I'm not sure exactly what you want to do...using your example of an
>>> employment site...do you have a form that gathers a users employment
>>> history, for example? And, if the employee has more than one previous
>>> employer, to return to the same form so they can enter more
>>> information? And, I assume, you do not want to submit the data to
>>> persistent storage (ie database) until they are complete with the
>>> form? If I'm off, let me know, just need clarification...
>> Sorry about that I should added some claficiation.. The example would
>> be if the user has more than one previous employer and they have add
>> more until they are done. That is correct I don't want the user to
>> enter the information to the database until they are done.
>>
>> Thanks..
>
> OK, than you really have 3 options, the last 2 I'll mention has
> several ways to implement each.
>
> First, you can use database transactions. So, the solution would rely
> more on the database rather than PHP. Basically, once the user starts
> entering data, you open a persistent connection and start a
> transaction.

Doesn't need to be persistent CONNECTION.

You issue a tag id when the header form is created, and carry it as a
post variable through all the session. If they switch off and walk away,
the transaction isn't marked as complete, and the data can be erased
sometime later.



> As data is added, modified, or deleted, you make those
> changes to the database transaction. If errors popup, you do a
> rollback. The data isn't actually saved in the database until you
> commit the transaction. Good things are this makes it easier on the
> PHP end, bad thing is the persistent connection, the overhead created
> by talking to the database so much, and implementing a rollback on
> data that wasn't saved incrementally could be bad news for your
> customer (might have to enter in lots of data). I would be cautious
> using this solution for your current situation, from what I see you're
> doing.

weird way. Its so much easier to enter the data temporarily into the
database, and then remove it later if it never gets completed.
Databases are very fast animals these days on a quick /insert or 'update'


>
> Second, you use some form of data persistence between request,
> typically using the SESSION superglobal or another form of filesystem
> persistence. This one is the real PHP option.

Its actually a standard *CGI* option, You simply use a POST or GET
method to carry an ID between pages AS LONG AS ONE PAGE IS INVOKED FROM
ANOTHER THAT KNOWS THIS.

Here, you have to
> (carefully) manage the data the user enters, often using some sort of
> array mapping so you can update/delete/search for a particular record
> within an array. So, if storing in $_SESSION, you could create a
> single namespace for the type of data, and use it like an array stack
> to hold the records so as to have a single location to manipulate it
> and not pollute the namespace. Something like:
>
> $employmentHistory = array();
> array_push($employmentHistory, $record);
> $_SESSION['employmentHistory'] = $employmentHistory;
>

You still have to store that array somewhere between program
invocations. (web page form submissions). Its either in the database, on
the server disk or as an ever growing HUGE set of POST variables that
get passed from server to browser and back every time you submit. Or in
the browser as javascript (YUK!!)

I say that its easiest to store it in the database. That's what
databases are for ;-)

> Another option, which would probably be nicer to manipulate but would
> generate additional overhead, would be to create an employmentHistory
> object and serialize/deserialize them during the requests. This is
> something I've done in the past.
>
> Your third option, again, lives outside PHP. You could use javaScript
> or another client-side scripting language to generate additional
> records on page, as needed, before even submitting it back to the
> server. While this potentially could clutter up the page if there are
> many, it can often be done gracefully and well done. In this
> situation, you would be looking at a DHTML solution, of which there
> are many tutorials on the Internet to get you started, if you choose
> this method. Generally, and increasingly nowadays, this solution is
> being implemented more and more for situations like this. I've also
> use this solution numerous times with great success.
>
It looks reasonable, but I find it mentally revolting. Old fashioned
mindset. Do everything centrally where it can be guaranteed. Its bad
enough trying to get the same colors and fonts onscreen between browser
types, let alone expecting them to run the same code in he same way.

I have a site that takes a split second to load under IE6 or safari, but
over a minute with Firefox. Why? something in their javascript and the
sites code causes MASSIVE CPU usage.



> So, that's a brief overview of how you can attack this problem. If
> you need additional information on either of these suggestions, just
> let me know.
>

KISS. Use the database. Steer clear of cleverness. Don't rely on what te
user has if at all possible. Simple forms, no javascript if possible.

write slender php to interface to the database and let THAT do the work.
Its only ONE piece of code you have to code against then.


Conceptually is

enter and fill out header, submit to database and continue with issued
ID in POST and hidden variables, carry that ID from session to session
until you hit the 'done' button.

Then flag the transaction complete, and nullify further access to its id.

I'm going this way to do an online shopping site. Build up the cart
iteration by iteration, and only when checking out does it get some form
of validity, but its always in the database. Only when the credit card
clears does it get flagged 'ready to ship' ;-)

Re: Form Arrays

On Sep 4, 11:54 am, ELINTPimp wrote:
> On Sep 4, 11:36 am, Kevin Davis wrote:
>
>
>
>
>
> > On Sep 4, 10:14 am, ELINTPimp wrote:
>
> > > On Sep 4, 11:00 am, Kevin Davis wrote:
>
> > > > Hello,
>
> > > > I'm a new person when it comes to PHP and I have a quick question.
>
> > > > I would like to create a form that will allow the user to add more
> > > > information using the same form in case they have (similar to various
> > > > employment sites).
>
> > > > What would be the best way of using form arrays for that function?
>
> > > > Thank you,
> > > > Kevin
>
> > > Hi Kevin,
>
> > > I'm not sure exactly what you want to do...using your example of an
> > > employment site...do you have a form that gathers a users employment
> > > history, for example? And, if the employee has more than one previous
> > > employer, to return to the same form so they can enter more
> > > information? And, I assume, you do not want to submit the data to
> > > persistent storage (ie database) until they are complete with the
> > > form? If I'm off, let me know, just need clarification...
>
> > Sorry about that I should added some claficiation.. The example would
> > be if the user has more than one previous employer and they have add
> > more until they are done. That is correct I don't want the user to
> > enter the information to the database until they are done.
>
> > Thanks..
>
> OK, than you really have 3 options, the last 2 I'll mention has
> several ways to implement each.
>
> First, you can use database transactions. So, the solution would rely
> more on the database rather than PHP. Basically, once the user starts
> entering data, you open a persistent connection and start a
> transaction. As data is added, modified, or deleted, you make those
> changes to the database transaction. If errors popup, you do a
> rollback. The data isn't actually saved in the database until you
> commit the transaction. Good things are this makes it easier on the
> PHP end, bad thing is the persistent connection, the overhead created
> by talking to the database so much, and implementing a rollback on
> data that wasn't saved incrementally could be bad news for your
> customer (might have to enter in lots of data). I would be cautious
> using this solution for your current situation, from what I see you're
> doing.
>
> Second, you use some form of data persistence between request,
> typically using the SESSION superglobal or another form of filesystem
> persistence. This one is the real PHP option. Here, you have to
> (carefully) manage the data the user enters, often using some sort of
> array mapping so you can update/delete/search for a particular record
> within an array. So, if storing in $_SESSION, you could create a
> single namespace for the type of data, and use it like an array stack
> to hold the records so as to have a single location to manipulate it
> and not pollute the namespace. Something like:
>
> $employmentHistory = array();
> array_push($employmentHistory, $record);
> $_SESSION['employmentHistory'] = $employmentHistory;
>
> Another option, which would probably be nicer to manipulate but would
> generate additional overhead, would be to create an employmentHistory
> object and serialize/deserialize them during the requests. This is
> something I've done in the past.
>
> Your third option, again, lives outside PHP. You could use javaScript
> or another client-side scripting language to generate additional
> records on page, as needed, before even submitting it back to the
> server. While this potentially could clutter up the page if there are
> many, it can often be done gracefully and well done. In this
> situation, you would be looking at a DHTML solution, of which there
> are many tutorials on the Internet to get you started, if you choose
> this method. Generally, and increasingly nowadays, this solution is
> being implemented more and more for situations like this. I've also
> use this solution numerous times with great success.
>
> So, that's a brief overview of how you can attack this problem. If
> you need additional information on either of these suggestions, just
> let me know.- Hide quoted text -
>
> - Show quoted text -

If possible can you show how you would implement the 2nd and 3rd
options. Just a breif overview would be helpful.

Thank you for suggestions.
Kevin

Re: Form Arrays

The Natural Philosopher wrote:
> ELINTPimp wrote:
>> On Sep 4, 11:36 am, Kevin Davis wrote:
>>> On Sep 4, 10:14 am, ELINTPimp wrote:
>>>
>>>
>>>
>>>> On Sep 4, 11:00 am, Kevin Davis wrote:
>>>>> Hello,
>>>>> I'm a new person when it comes to PHP and I have a quick question.
>>>>> I would like to create a form that will allow the user to add more
>>>>> information using the same form in case they have (similar to various
>>>>> employment sites).
>>>>> What would be the best way of using form arrays for that function?
>>>>> Thank you,
>>>>> Kevin
>>>> Hi Kevin,
>>>> I'm not sure exactly what you want to do...using your example of an
>>>> employment site...do you have a form that gathers a users employment
>>>> history, for example? And, if the employee has more than one previous
>>>> employer, to return to the same form so they can enter more
>>>> information? And, I assume, you do not want to submit the data to
>>>> persistent storage (ie database) until they are complete with the
>>>> form? If I'm off, let me know, just need clarification...
>>> Sorry about that I should added some claficiation.. The example would
>>> be if the user has more than one previous employer and they have add
>>> more until they are done. That is correct I don't want the user to
>>> enter the information to the database until they are done.
>>>
>>> Thanks..
>>
>> OK, than you really have 3 options, the last 2 I'll mention has
>> several ways to implement each.
>>
>> First, you can use database transactions. So, the solution would rely
>> more on the database rather than PHP. Basically, once the user starts
>> entering data, you open a persistent connection and start a
>> transaction.
>
> Doesn't need to be persistent CONNECTION.
>
> You issue a tag id when the header form is created, and carry it as a
> post variable through all the session. If they switch off and walk away,
> the transaction isn't marked as complete, and the data can be erased
> sometime later.
>

But PHP will close the connection at the end of the page and the data
will be committed. You can't use a transaction this way.

>
>
>> As data is added, modified, or deleted, you make those
>> changes to the database transaction. If errors popup, you do a
>> rollback. The data isn't actually saved in the database until you
>> commit the transaction. Good things are this makes it easier on the
>> PHP end, bad thing is the persistent connection, the overhead created
>> by talking to the database so much, and implementing a rollback on
>> data that wasn't saved incrementally could be bad news for your
>> customer (might have to enter in lots of data). I would be cautious
>> using this solution for your current situation, from what I see you're
>> doing.
>
> weird way. Its so much easier to enter the data temporarily into the
> database, and then remove it later if it never gets completed.
> Databases are very fast animals these days on a quick /insert or 'update'
>

True, this is one option. But then you need some way to trigger the
remove, if, for instance, the user just closes his browser. A cron job
or similar will work.

>
>>
>> Second, you use some form of data persistence between request,
>> typically using the SESSION superglobal or another form of filesystem
>> persistence. This one is the real PHP option.
>
> Its actually a standard *CGI* option, You simply use a POST or GET
> method to carry an ID between pages AS LONG AS ONE PAGE IS INVOKED FROM
> ANOTHER THAT KNOWS THIS.
>

The SESSION superglobal works fine in the apache (or IIS) module version.

And it keeps from having to send all that data back and forth between
the client and the server.

It's also safer - someone can't "gimmick" the data after it's been
received to change it - for instance, change the amount to be charged
from $100.00 to $1.00.

> Here, you have to
>> (carefully) manage the data the user enters, often using some sort of
>> array mapping so you can update/delete/search for a particular record
>> within an array. So, if storing in $_SESSION, you could create a
>> single namespace for the type of data, and use it like an array stack
>> to hold the records so as to have a single location to manipulate it
>> and not pollute the namespace. Something like:
>>
>> $employmentHistory = array();
>> array_push($employmentHistory, $record);
>> $_SESSION['employmentHistory'] = $employmentHistory;
>>
>
> You still have to store that array somewhere between program
> invocations. (web page form submissions). Its either in the database, on
> the server disk or as an ever growing HUGE set of POST variables that
> get passed from server to browser and back every time you submit. Or in
> the browser as javascript (YUK!!)
>

The SESSION array is the easiest.

> I say that its easiest to store it in the database. That's what
> databases are for ;-)
>

True, but the same problem as above.

>> Another option, which would probably be nicer to manipulate but would
>> generate additional overhead, would be to create an employmentHistory
>> object and serialize/deserialize them during the requests. This is
>> something I've done in the past.
>>
>> Your third option, again, lives outside PHP. You could use javaScript
>> or another client-side scripting language to generate additional
>> records on page, as needed, before even submitting it back to the
>> server. While this potentially could clutter up the page if there are
>> many, it can often be done gracefully and well done. In this
>> situation, you would be looking at a DHTML solution, of which there
>> are many tutorials on the Internet to get you started, if you choose
>> this method. Generally, and increasingly nowadays, this solution is
>> being implemented more and more for situations like this. I've also
>> use this solution numerous times with great success.
>>
> It looks reasonable, but I find it mentally revolting. Old fashioned
> mindset. Do everything centrally where it can be guaranteed. Its bad
> enough trying to get the same colors and fonts onscreen between browser
> types, let alone expecting them to run the same code in he same way.
>
> I have a site that takes a split second to load under IE6 or safari, but
> over a minute with Firefox. Why? something in their javascript and the
> sites code causes MASSIVE CPU usage.
>

Agreed. And what if they don't have javascript enabled?

>
>
>> So, that's a brief overview of how you can attack this problem. If
>> you need additional information on either of these suggestions, just
>> let me know.
>>
>
> KISS. Use the database. Steer clear of cleverness. Don't rely on what te
> user has if at all possible. Simple forms, no javascript if possible.
>
> write slender php to interface to the database and let THAT do the work.
> Its only ONE piece of code you have to code against then.
>

In this case I think the SESSION superglobal is easier.

>
> Conceptually is
>
> enter and fill out header, submit to database and continue with issued
> ID in POST and hidden variables, carry that ID from session to session
> until you hit the 'done' button.
>
> Then flag the transaction complete, and nullify further access to its id.
>

Enter and fill out the header. Store in $_SESSION and continue. No ID
or hidden variables required.

> I'm going this way to do an online shopping site. Build up the cart
> iteration by iteration, and only when checking out does it get some form
> of validity, but its always in the database. Only when the credit card
> clears does it get flagged 'ready to ship' ;-)
>
>

And how are you going to take care of the problem of someone leaving
before completing the checkout procedure?


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Form Arrays

On Sep 4, 8:00 am, Kevin Davis wrote:
> Hello,
>
> I'm a new person when it comes to PHP and I have a quick question.
>
> I would like to create a form that will allow the user to add more
> information using the same form in case they have (similar to various
> employment sites).
>
> What would be the best way of using form arrays for that function?
>
> Thank you,
> Kevin

I would have an input with a name that is translated to an array.
Have some javascript create the additional inputs...

Output:

\n";
foreach($_POST['inputbox'] as $v){
echo (!empty($v)) ? "
• {$v}
\n" : "";
}
echo "

[OT] Re: Form Arrays

Jerry Stuckle wrote:
> The Natural Philosopher wrote:

>> I have a site that takes a split second to load under IE6 or safari,
>> but over a minute with Firefox. Why? something in their javascript and
>> the sites code causes MASSIVE CPU usage.
>>
>
> Agreed. And what if they don't have javascript enabled?

I'm having that problem like *crazy*.
I thought it was just because I'm still a Firefox Newbie.

It got worse this week when my nice P4 system crapped out and I had to
revive an old P3 with 384k.

Now, those sites that used to just spike my CPU cause Firefox to crash
out completely - shutting all its windows and everything.

Anybody in Dallas wanna buy a P3 cheap?

Re: [OT] Re: Form Arrays

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> The Natural Philosopher wrote:
>
>>> I have a site that takes a split second to load under IE6 or safari,
>>> but over a minute with Firefox. Why? something in their javascript
>>> and the sites code causes MASSIVE CPU usage.
>>>
>>
>> Agreed. And what if they don't have javascript enabled?
>
> I'm having that problem like *crazy*.
> I thought it was just because I'm still a Firefox Newbie.
>
> It got worse this week when my nice P4 system crapped out and I had to
> revive an old P3 with 384k.
>
> Now, those sites that used to just spike my CPU cause Firefox to crash
> out completely - shutting all its windows and everything.
>
> Anybody in Dallas wanna buy a P3 cheap?

Simple. Use javascript to enhance the experience. Don't require it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Form Arrays

Jerry Stuckle wrote:
> The Natural Philosopher wrote:
>> ELINTPimp wrote:
>>> On Sep 4, 11:36 am, Kevin Davis wrote:
>>>> On Sep 4, 10:14 am, ELINTPimp wrote:
>>>>
>>>>
>>>>
>>>>> On Sep 4, 11:00 am, Kevin Davis wrote:
>>>>>> Hello,
>>>>>> I'm a new person when it comes to PHP and I have a quick question.
>>>>>> I would like to create a form that will allow the user to add more
>>>>>> information using the same form in case they have (similar to various
>>>>>> employment sites).
>>>>>> What would be the best way of using form arrays for that function?
>>>>>> Thank you,
>>>>>> Kevin
>>>>> Hi Kevin,
>>>>> I'm not sure exactly what you want to do...using your example of an
>>>>> employment site...do you have a form that gathers a users employment
>>>>> history, for example? And, if the employee has more than one previous
>>>>> employer, to return to the same form so they can enter more
>>>>> information? And, I assume, you do not want to submit the data to
>>>>> persistent storage (ie database) until they are complete with the
>>>>> form? If I'm off, let me know, just need clarification...
>>>> Sorry about that I should added some claficiation.. The example would
>>>> be if the user has more than one previous employer and they have add
>>>> more until they are done. That is correct I don't want the user to
>>>> enter the information to the database until they are done.
>>>>
>>>> Thanks..
>>>
>>> OK, than you really have 3 options, the last 2 I'll mention has
>>> several ways to implement each.
>>>
>>> First, you can use database transactions. So, the solution would rely
>>> more on the database rather than PHP. Basically, once the user starts
>>> entering data, you open a persistent connection and start a
>>> transaction.
>>
>> Doesn't need to be persistent CONNECTION.
>>
>> You issue a tag id when the header form is created, and carry it as a
>> post variable through all the session. If they switch off and walk
>> away, the transaction isn't marked as complete, and the data can be
>> erased sometime later.
>>
>
> But PHP will close the connection at the end of the page and the data
> will be committed. You can't use a transaction this way.
>

It depends on what you mean by transaction

I ws using it in the sense of a complete session with th customer. Of
course the *database* transaction is atomic and complete, but it will be
added to by further invocations until the customer is satisfied. At that
point the final database transaction is to set a flag in the record
header saying 'done'

>>
>>
>>> As data is added, modified, or deleted, you make those
>>> changes to the database transaction. If errors popup, you do a
>>> rollback. The data isn't actually saved in the database until you
>>> commit the transaction. Good things are this makes it easier on the
>>> PHP end, bad thing is the persistent connection, the overhead created
>>> by talking to the database so much, and implementing a rollback on
>>> data that wasn't saved incrementally could be bad news for your
>>> customer (might have to enter in lots of data). I would be cautious
>>> using this solution for your current situation, from what I see you're
>>> doing.
>>
>> weird way. Its so much easier to enter the data temporarily into the
>> database, and then remove it later if it never gets completed.
>> Databases are very fast animals these days on a quick /insert or 'update'
>>
>
> True, this is one option. But then you need some way to trigger the
> remove, if, for instance, the user just closes his browser. A cron job
> or similar will work.
>
It will
Simply look for incomplete sessions that are more than a day old. And
blast em!


>>
>>>
>>> Second, you use some form of data persistence between request,
>>> typically using the SESSION superglobal or another form of filesystem
>>> persistence. This one is the real PHP option.
>>
>> Its actually a standard *CGI* option, You simply use a POST or GET
>> method to carry an ID between pages AS LONG AS ONE PAGE IS INVOKED
>> FROM ANOTHER THAT KNOWS THIS.
>>
>
> The SESSION superglobal works fine in the apache (or IIS) module version.
>
> And it keeps from having to send all that data back and forth between
> the client and the server.
>

It doesn't. HTML is a stateless protol. The only way to give it
statefulness is to excahnge information as each page is loaded or each
page submitted.

HOW its done may appear to not involve that, but it does.

> It's also safer - someone can't "gimmick" the data after it's been
> received to change it - for instance, change the amount to be charged
> from $100.00 to $1.00.
>
wanna bet?

>> Here, you have to
>>> (carefully) manage the data the user enters, often using some sort of
>>> array mapping so you can update/delete/search for a particular record
>>> within an array. So, if storing in $_SESSION, you could create a
>>> single namespace for the type of data, and use it like an array stack
>>> to hold the records so as to have a single location to manipulate it
>>> and not pollute the namespace. Something like:
>>>
>>> $employmentHistory = array();
>>> array_push($employmentHistory, $record);
>>> $_SESSION['employmentHistory'] = $employmentHistory;
>>>
>>
>> You still have to store that array somewhere between program
>> invocations. (web page form submissions). Its either in the database,
>> on the server disk or as an ever growing HUGE set of POST variables
>> that get passed from server to browser and back every time you submit.
>> Or in the browser as javascript (YUK!!)
>>
>
> The SESSION array is the easiest.
>
*shrug* it hides what is happening from you. That may be easier t
prgram, but harder t fix if things go wrong.

>> I say that its easiest to store it in the database. That's what
>> databases are for ;-)
>>
>
> True, but the same problem as above.
>
>>> Another option, which would probably be nicer to manipulate but would
>>> generate additional overhead, would be to create an employmentHistory
>>> object and serialize/deserialize them during the requests. This is
>>> something I've done in the past.
>>>
>>> Your third option, again, lives outside PHP. You could use javaScript
>>> or another client-side scripting language to generate additional
>>> records on page, as needed, before even submitting it back to the
>>> server. While this potentially could clutter up the page if there are
>>> many, it can often be done gracefully and well done. In this
>>> situation, you would be looking at a DHTML solution, of which there
>>> are many tutorials on the Internet to get you started, if you choose
>>> this method. Generally, and increasingly nowadays, this solution is
>>> being implemented more and more for situations like this. I've also
>>> use this solution numerous times with great success.
>>>
>> It looks reasonable, but I find it mentally revolting. Old fashioned
>> mindset. Do everything centrally where it can be guaranteed. Its bad
>> enough trying to get the same colors and fonts onscreen between
>> browser types, let alone expecting them to run the same code in he
>> same way.
>>
>> I have a site that takes a split second to load under IE6 or safari,
>> but over a minute with Firefox. Why? something in their javascript and
>> the sites code causes MASSIVE CPU usage.
>>
>
> Agreed. And what if they don't have javascript enabled?
>
Fuck em.
They aren't worth epmloying :)

>>
>>
>>> So, that's a brief overview of how you can attack this problem. If
>>> you need additional information on either of these suggestions, just
>>> let me know.
>>>
>>
>> KISS. Use the database. Steer clear of cleverness. Don't rely on what
>> te user has if at all possible. Simple forms, no javascript if possible.
>>
>> write slender php to interface to the database and let THAT do the
>> work. Its only ONE piece of code you have to code against then.
>>
>
> In this case I think the SESSION superglobal is easier.
>
>>
>> Conceptually is
>>
>> enter and fill out header, submit to database and continue with issued
>> ID in POST and hidden variables, carry that ID from session to session
>> until you hit the 'done' button.
>>
>> Then flag the transaction complete, and nullify further access to its id.
>>
>
> Enter and fill out the header. Store in $_SESSION and continue. No ID
> or hidden variables required.
>

What do you thing these superglobals are?

>> I'm going this way to do an online shopping site. Build up the cart
>> iteration by iteration, and only when checking out does it get some
>> form of validity, but its always in the database. Only when the credit
>> card clears does it get flagged 'ready to ship' ;-)
>>
>>
>
> And how are you going to take care of the problem of someone leaving
> before completing the checkout procedure?
>
What problem?

There will be a shopping trolley full of goods left in the aisle.

If no one comes to collect it I will simply have a cron script to put
the stuff back on the shelves after 24 hours. Or not. It only waste s
very little disk space to have it stored. In reality it hasn't come off
the shelves anyway, its just an order that was never finished. Like a
letter waiting for a signature before it gets sent. If it never gets a
signature, it never gets sent, thats all :-)

And one day you stuff it in the trash.

>

Re: [OT] Re: Form Arrays

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> Anybody in Dallas wanna buy a P3 cheap?
>
> Simple. Use javascript to enhance the experience. Don't require it.

I never do.
As far as I'm concerned - a web app that requires more than XHTML1 and
CSSS2 is too scattered.

That's one of the reasons I bailed on MS after learning ASP.NET.

When you program in dotnet, you find that some of your logic runs on the
server, an some on the client. That's insanely error-prone, and makes
it waaaay too easy to easy to expose proprietary business information -
like processes and security credentials.

Re: Form Arrays

The Natural Philosopher wrote:
> Jerry Stuckle wrote:
>> The Natural Philosopher wrote:
>>> ELINTPimp wrote:
>>>> On Sep 4, 11:36 am, Kevin Davis wrote:
>>>>> On Sep 4, 10:14 am, ELINTPimp wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Sep 4, 11:00 am, Kevin Davis wrote:
>>>>>>> Hello,
>>>>>>> I'm a new person when it comes to PHP and I have a quick question.
>>>>>>> I would like to create a form that will allow the user to add more
>>>>>>> information using the same form in case they have (similar to
>>>>>>> various
>>>>>>> employment sites).
>>>>>>> What would be the best way of using form arrays for that function?
>>>>>>> Thank you,
>>>>>>> Kevin
>>>>>> Hi Kevin,
>>>>>> I'm not sure exactly what you want to do...using your example of an
>>>>>> employment site...do you have a form that gathers a users employment
>>>>>> history, for example? And, if the employee has more than one
>>>>>> previous
>>>>>> employer, to return to the same form so they can enter more
>>>>>> information? And, I assume, you do not want to submit the data to
>>>>>> persistent storage (ie database) until they are complete with the
>>>>>> form? If I'm off, let me know, just need clarification...
>>>>> Sorry about that I should added some claficiation.. The example would
>>>>> be if the user has more than one previous employer and they have add
>>>>> more until they are done. That is correct I don't want the user to
>>>>> enter the information to the database until they are done.
>>>>>
>>>>> Thanks..
>>>>
>>>> OK, than you really have 3 options, the last 2 I'll mention has
>>>> several ways to implement each.
>>>>
>>>> First, you can use database transactions. So, the solution would rely
>>>> more on the database rather than PHP. Basically, once the user starts
>>>> entering data, you open a persistent connection and start a
>>>> transaction.
>>>
>>> Doesn't need to be persistent CONNECTION.
>>>
>>> You issue a tag id when the header form is created, and carry it as a
>>> post variable through all the session. If they switch off and walk
>>> away, the transaction isn't marked as complete, and the data can be
>>> erased sometime later.
>>>
>>
>> But PHP will close the connection at the end of the page and the data
>> will be committed. You can't use a transaction this way.
>>
>
> It depends on what you mean by transaction
>

When dealing with relational databases, the term "transaction" has a
very specific meaning. It is the time between a "START TRANSACTION"
call and an explicit or implicit "ROLLBACK" or "COMMIT".

> I ws using it in the sense of a complete session with th customer. Of
> course the *database* transaction is atomic and complete, but it will be
> added to by further invocations until the customer is satisfied. At that
> point the final database transaction is to set a flag in the record
> header saying 'done'
>

Then you are confusing matters by using incorrect terminology.

>>>
>>>
>>>> As data is added, modified, or deleted, you make those
>>>> changes to the database transaction. If errors popup, you do a
>>>> rollback. The data isn't actually saved in the database until you
>>>> commit the transaction. Good things are this makes it easier on the
>>>> PHP end, bad thing is the persistent connection, the overhead created
>>>> by talking to the database so much, and implementing a rollback on
>>>> data that wasn't saved incrementally could be bad news for your
>>>> customer (might have to enter in lots of data). I would be cautious
>>>> using this solution for your current situation, from what I see you're
>>>> doing.
>>>
>>> weird way. Its so much easier to enter the data temporarily into the
>>> database, and then remove it later if it never gets completed.
>>> Databases are very fast animals these days on a quick /insert or
>>> 'update'
>>>
>>
>> True, this is one option. But then you need some way to trigger the
>> remove, if, for instance, the user just closes his browser. A cron
>> job or similar will work.
>>
> It will
> Simply look for incomplete sessions that are more than a day old. And
> blast em!
>

That's one way. But if you have a lot of them you can end up with a
very large amount of wasted space in your database.

>
>>>
>>>>
>>>> Second, you use some form of data persistence between request,
>>>> typically using the SESSION superglobal or another form of filesystem
>>>> persistence. This one is the real PHP option.
>>>
>>> Its actually a standard *CGI* option, You simply use a POST or GET
>>> method to carry an ID between pages AS LONG AS ONE PAGE IS INVOKED
>>> FROM ANOTHER THAT KNOWS THIS.
>>>
>>
>> The SESSION superglobal works fine in the apache (or IIS) module version.
>>
>> And it keeps from having to send all that data back and forth between
>> the client and the server.
>>
>
> It doesn't. HTML is a stateless protol. The only way to give it
> statefulness is to excahnge information as each page is loaded or each
> page submitted.
>

Yes, HTML is stateless. But sessions work great, and are used by
millions of web sites all over the world. That's what they are created for.

I think you need to learn about sessions.

> HOW its done may appear to not involve that, but it does.
>

PHP sessions are identified by a cookie (default) or a GET parameter
appended to the URI, as necessary. PHP handles the session identifiers
and you don't have to worry about it.

>> It's also safer - someone can't "gimmick" the data after it's been
>> received to change it - for instance, change the amount to be charged
>> from $100.00 to $1.00.
>>
> wanna bet?
>

Yes. Any amount you want.

>>> Here, you have to
>>>> (carefully) manage the data the user enters, often using some sort of
>>>> array mapping so you can update/delete/search for a particular record
>>>> within an array. So, if storing in $_SESSION, you could create a
>>>> single namespace for the type of data, and use it like an array stack
>>>> to hold the records so as to have a single location to manipulate it
>>>> and not pollute the namespace. Something like:
>>>>
>>>> $employmentHistory = array();
>>>> array_push($employmentHistory, $record);
>>>> $_SESSION['employmentHistory'] = $employmentHistory;
>>>>
>>>
>>> You still have to store that array somewhere between program
>>> invocations. (web page form submissions). Its either in the database,
>>> on the server disk or as an ever growing HUGE set of POST variables
>>> that get passed from server to browser and back every time you
>>> submit. Or in the browser as javascript (YUK!!)
>>>
>>
>> The SESSION array is the easiest.
>>
> *shrug* it hides what is happening from you. That may be easier t
> prgram, but harder t fix if things go wrong.
>

No, much more than that. It does a lot for you. And it isn't hard at
all to find the problem if something goes wrong.

>>> I say that its easiest to store it in the database. That's what
>>> databases are for ;-)
>>>
>>
>> True, but the same problem as above.
>>
>>>> Another option, which would probably be nicer to manipulate but would
>>>> generate additional overhead, would be to create an employmentHistory
>>>> object and serialize/deserialize them during the requests. This is
>>>> something I've done in the past.
>>>>
>>>> Your third option, again, lives outside PHP. You could use javaScript
>>>> or another client-side scripting language to generate additional
>>>> records on page, as needed, before even submitting it back to the
>>>> server. While this potentially could clutter up the page if there are
>>>> many, it can often be done gracefully and well done. In this
>>>> situation, you would be looking at a DHTML solution, of which there
>>>> are many tutorials on the Internet to get you started, if you choose
>>>> this method. Generally, and increasingly nowadays, this solution is
>>>> being implemented more and more for situations like this. I've also
>>>> use this solution numerous times with great success.
>>>>
>>> It looks reasonable, but I find it mentally revolting. Old fashioned
>>> mindset. Do everything centrally where it can be guaranteed. Its bad
>>> enough trying to get the same colors and fonts onscreen between
>>> browser types, let alone expecting them to run the same code in he
>>> same way.
>>>
>>> I have a site that takes a split second to load under IE6 or safari,
>>> but over a minute with Firefox. Why? something in their javascript
>>> and the sites code causes MASSIVE CPU usage.
>>>
>>
>> Agreed. And what if they don't have javascript enabled?
>>
> Fuck em.
> They aren't worth epmloying :)
>

And you'll lose at least 10% of the people on the internet. As well as
all search engines.

>>>
>>>
>>>> So, that's a brief overview of how you can attack this problem. If
>>>> you need additional information on either of these suggestions, just
>>>> let me know.
>>>>
>>>
>>> KISS. Use the database. Steer clear of cleverness. Don't rely on what
>>> te user has if at all possible. Simple forms, no javascript if possible.
>>>
>>> write slender php to interface to the database and let THAT do the
>>> work. Its only ONE piece of code you have to code against then.
>>>
>>
>> In this case I think the SESSION superglobal is easier.
>>
>>>
>>> Conceptually is
>>>
>>> enter and fill out header, submit to database and continue with
>>> issued ID in POST and hidden variables, carry that ID from session to
>>> session until you hit the 'done' button.
>>>
>>> Then flag the transaction complete, and nullify further access to its
>>> id.
>>>
>>
>> Enter and fill out the header. Store in $_SESSION and continue. No ID
>> or hidden variables required.
>>
>
> What do you thing these superglobals are?
>

You need to learn what the $_SESSION superglobal is. It is neither a
hidden variable nor a transaction id.

>>> I'm going this way to do an online shopping site. Build up the cart
>>> iteration by iteration, and only when checking out does it get some
>>> form of validity, but its always in the database. Only when the
>>> credit card clears does it get flagged 'ready to ship' ;-)
>>>
>>>
>>
>> And how are you going to take care of the problem of someone leaving
>> before completing the checkout procedure?
>>
> What problem?
>
> There will be a shopping trolley full of goods left in the aisle.
>
> If no one comes to collect it I will simply have a cron script to put
> the stuff back on the shelves after 24 hours. Or not. It only waste s
> very little disk space to have it stored. In reality it hasn't come off
> the shelves anyway, its just an order that was never finished. Like a
> letter waiting for a signature before it gets sent. If it never gets a
> signature, it never gets sent, thats all :-)
>
> And one day you stuff it in the trash.
>
>>

And in the meantime, you waste a lot of database space and fragment your
database more than necessary.

Some fragmentation is inevitable. But there's no need to exacerbate the
situation unnecessarily.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: [OT] Re: Form Arrays

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>>> Anybody in Dallas wanna buy a P3 cheap?
>>
>> Simple. Use javascript to enhance the experience. Don't require it.
>
> I never do.
> As far as I'm concerned - a web app that requires more than XHTML1 and
> CSSS2 is too scattered.
>
> That's one of the reasons I bailed on MS after learning ASP.NET.
>
> When you program in dotnet, you find that some of your logic runs on the
> server, an some on the client. That's insanely error-prone, and makes
> it waaaay too easy to easy to expose proprietary business information -
> like processes and security credentials.
>
>
>

I typically don't even worry about XHTML1. Browser support is too
sporadic. I can do everything I need with HTML 4.01 strict and CSS 1.

And I never use .net. I do have a couple of VBScript/ASP sites, but
that's it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: [OT] Re: Form Arrays

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> When you program in dotnet, you find that some of your logic runs on
>> the server, an some on the client. That's insanely error-prone, and
>> makes it waaaay too easy to easy to expose proprietary business
>> information - like processes and security credentials.
>
> I typically don't even worry about XHTML1. Browser support is too
> sporadic. I can do everything I need with HTML 4.01 strict and CSS 1.

Other than capitalization, there's *very* little difference.
And that ain't much.



>
> And I never use .net. I do have a couple of VBScript/ASP sites, but
> that's it.
>

Re: Form Arrays

Jerry Stuckle wrote:
> The Natural Philosopher wrote:
>> Jerry Stuckle wrote:
>>> The Natural Philosopher wrote:
>>>> ELINTPimp wrote:
>>>>> On Sep 4, 11:36 am, Kevin Davis wrote:
>>>>>> On Sep 4, 10:14 am, ELINTPimp wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 4, 11:00 am, Kevin Davis wrote:
>>>>>>>> Hello,
>>>>>>>> I'm a new person when it comes to PHP and I have a quick question.
>>>>>>>> I would like to create a form that will allow the user to add more
>>>>>>>> information using the same form in case they have (similar to
>>>>>>>> various
>>>>>>>> employment sites).
>>>>>>>> What would be the best way of using form arrays for that function?
>>>>>>>> Thank you,
>>>>>>>> Kevin
>>>>>>> Hi Kevin,
>>>>>>> I'm not sure exactly what you want to do...using your example of an
>>>>>>> employment site...do you have a form that gathers a users employment
>>>>>>> history, for example? And, if the employee has more than one
>>>>>>> previous
>>>>>>> employer, to return to the same form so they can enter more
>>>>>>> information? And, I assume, you do not want to submit the data to
>>>>>>> persistent storage (ie database) until they are complete with the
>>>>>>> form? If I'm off, let me know, just need clarification...
>>>>>> Sorry about that I should added some claficiation.. The example would
>>>>>> be if the user has more than one previous employer and they have add
>>>>>> more until they are done. That is correct I don't want the user to
>>>>>> enter the information to the database until they are done.
>>>>>>
>>>>>> Thanks..
>>>>>
>>>>> OK, than you really have 3 options, the last 2 I'll mention has
>>>>> several ways to implement each.
>>>>>
>>>>> First, you can use database transactions. So, the solution would rely
>>>>> more on the database rather than PHP. Basically, once the user starts
>>>>> entering data, you open a persistent connection and start a
>>>>> transaction.
>>>>
>>>> Doesn't need to be persistent CONNECTION.
>>>>
>>>> You issue a tag id when the header form is created, and carry it as
>>>> a post variable through all the session. If they switch off and walk
>>>> away, the transaction isn't marked as complete, and the data can be
>>>> erased sometime later.
>>>>
>>>
>>> But PHP will close the connection at the end of the page and the data
>>> will be committed. You can't use a transaction this way.
>>>
>>
>> It depends on what you mean by transaction
>>
>
> When dealing with relational databases, the term "transaction" has a
> very specific meaning. It is the time between a "START TRANSACTION"
> call and an explicit or implicit "ROLLBACK" or "COMMIT".
>
>> I ws using it in the sense of a complete session with th customer. Of
>> course the *database* transaction is atomic and complete, but it will
>> be added to by further invocations until the customer is satisfied. At
>> that point the final database transaction is to set a flag in the
>> record header saying 'done'
>>
>
> Then you are confusing matters by using incorrect terminology.
>

No, I am confusing YOU.;-)

I have business transactions with customers, database transactions with
databases.

The term transaction was not INVENTED by, or used explicitly FOR
database software authors.

You should get out more and have some transactions with a bar.;-)

Re: Form Arrays

The Natural Philosopher wrote:
> Jerry Stuckle wrote:
>> The Natural Philosopher wrote:
>>> Jerry Stuckle wrote:
>>>> The Natural Philosopher wrote:
>>>>> ELINTPimp wrote:
>>>>>> On Sep 4, 11:36 am, Kevin Davis wrote:
>>>>>>> On Sep 4, 10:14 am, ELINTPimp wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Sep 4, 11:00 am, Kevin Davis
>>>>>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>> I'm a new person when it comes to PHP and I have a quick question.
>>>>>>>>> I would like to create a form that will allow the user to add more
>>>>>>>>> information using the same form in case they have (similar to
>>>>>>>>> various
>>>>>>>>> employment sites).
>>>>>>>>> What would be the best way of using form arrays for that function?
>>>>>>>>> Thank you,
>>>>>>>>> Kevin
>>>>>>>> Hi Kevin,
>>>>>>>> I'm not sure exactly what you want to do...using your example of an
>>>>>>>> employment site...do you have a form that gathers a users
>>>>>>>> employment
>>>>>>>> history, for example? And, if the employee has more than one
>>>>>>>> previous
>>>>>>>> employer, to return to the same form so they can enter more
>>>>>>>> information? And, I assume, you do not want to submit the data to
>>>>>>>> persistent storage (ie database) until they are complete with the
>>>>>>>> form? If I'm off, let me know, just need clarification...
>>>>>>> Sorry about that I should added some claficiation.. The example
>>>>>>> would
>>>>>>> be if the user has more than one previous employer and they have add
>>>>>>> more until they are done. That is correct I don't want the user to
>>>>>>> enter the information to the database until they are done.
>>>>>>>
>>>>>>> Thanks..
>>>>>>
>>>>>> OK, than you really have 3 options, the last 2 I'll mention has
>>>>>> several ways to implement each.
>>>>>>
>>>>>> First, you can use database transactions. So, the solution would
>>>>>> rely
>>>>>> more on the database rather than PHP. Basically, once the user
>>>>>> starts
>>>>>> entering data, you open a persistent connection and start a
>>>>>> transaction.
>>>>>
>>>>> Doesn't need to be persistent CONNECTION.
>>>>>
>>>>> You issue a tag id when the header form is created, and carry it as
>>>>> a post variable through all the session. If they switch off and
>>>>> walk away, the transaction isn't marked as complete, and the data
>>>>> can be erased sometime later.
>>>>>
>>>>
>>>> But PHP will close the connection at the end of the page and the
>>>> data will be committed. You can't use a transaction this way.
>>>>
>>>
>>> It depends on what you mean by transaction
>>>
>>
>> When dealing with relational databases, the term "transaction" has a
>> very specific meaning. It is the time between a "START TRANSACTION"
>> call and an explicit or implicit "ROLLBACK" or "COMMIT".
>>
>>> I ws using it in the sense of a complete session with th customer. Of
>>> course the *database* transaction is atomic and complete, but it will
>>> be added to by further invocations until the customer is satisfied.
>>> At that point the final database transaction is to set a flag in the
>>> record header saying 'done'
>>>
>>
>> Then you are confusing matters by using incorrect terminology.
>>
>
> No, I am confusing YOU.;-)
>
> I have business transactions with customers, database transactions with
> databases.
>
> The term transaction was not INVENTED by, or used explicitly FOR
> database software authors.
>
> You should get out more and have some transactions with a bar.;-)
>
>
>

And you improperly used TRANSACTION when speaking about DATABASE:

To quote you:

"First, you can use database transactions."

Database transactions do not work like you explained.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================