Form Arrays

[Kevin Davis]

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

[ELINTPimp]

On Sep 4, 11:00 am, Kevin Davis <[e-mail]:

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...

[Kevin Davis]

On Sep 4, 10:14 am, ELINTPimp <[e-mail]:

On Sep 4, 11:00 am, Kevin Davis <[e-mail]:

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..

[ELINTPimp]

On Sep 4, 11:36 am, Kevin Davis <[e-mail]:

On Sep 4, 10:14 am, ELINTPimp <[e-mail]:

On Sep 4, 11:00 am, Kevin Davis <[e-mail]:

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.

[The Natural Philosopher]

Kevin Davis wrote:

On Sep 4, 10:14 am, ELINTPimp <[e-mail]:

>On Sep 4, 11:00 am, Kevin Davis <[e-mail]:

>>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..

[The Natural Philosopher]

ELINTPimp wrote:

On Sep 4, 11:36 am, Kevin Davis <[e-mail]:

>On Sep 4, 10:14 am, ELINTPimp <[e-mail]:

>>On Sep 4, 11:00 am, Kevin Davis <[e-mail]:
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' ;-)

[Kevin Davis]

On Sep 4, 11:54 am, ELINTPimp <[e-mail]:

On Sep 4, 11:36 am, Kevin Davis <[e-mail]:

On Sep 4, 10:14 am, ELINTPimp <[e-mail]:

On Sep 4, 11:00 am, Kevin Davis <[e-mail]:

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

[Jerry Stuckle]

The Natural Philosopher wrote:

ELINTPimp wrote:

>On Sep 4, 11:36 am, Kevin Davis <[e-mail]:

>>On Sep 4, 10:14 am, ELINTPimp <[e-mail]:

On Sep 4, 11:00 am, Kevin Davis <[e-mail]:
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.
js*******@attglobal.net
==================

[4sak3n 0ne]

On Sep 4, 8:00 am, Kevin Davis <[e-mail]:

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...

<form action="something.php" method="post">
<input type="text" name="inputbox[]" value="" />
<input type="text" name="inputbox[]" value="" />
</form>

When this is posted, you can use a foreach loop to run through it. If
you use this method, be sure to check for empty values, because once
the form has been created, its added to the array, empty or not.

if(isset($_POST['inputbox'])){
echo "<h2>Output:</h2>";
echo "<ul>\n";
foreach($_POST['inputbox'] as $v){
echo (!empty($v)) ? "<li>{$v}</li>\n" : "";
}
echo "</ul>\n";
}

[Sanders Kaufman]

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?

[Jerry Stuckle]

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.
js*******@attglobal.net
==================

[Sanders Kaufman]

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.

[Jerry Stuckle]

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.
js*******@attglobal.net
==================

[Sanders Kaufman]

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.

[The Natural Philosopher]

Jerry Stuckle wrote:

The Natural Philosopher wrote:

>Jerry Stuckle wrote:

>>The Natural Philosopher wrote:
ELINTPimp wrote:
On Sep 4, 11:36 am, Kevin Davis <[e-mail]:
>On Sep 4, 10:14 am, ELINTPimp <[e-mail]:
>>
>>
>>
>>On Sep 4, 11:00 am, Kevin Davis <[e-mail]:
>>>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.;-)

[Jerry Stuckle]

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 <[e-mail]:
>>On Sep 4, 10:14 am, ELINTPimp <[e-mail]:
>>>
>>>
>>>
>>>On Sep 4, 11:00 am, Kevin Davis <[e-mail]>
>>>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.
js*******@attglobal.net
==================