Re: Form Arrays

The Natural Philosopher wrote:
Jerry Stuckle wrote:
The Natural Philosopher wrote:
ELINTPimp wrote:
On Sep 4, 11:36 am, Kevin Davis <kevin.da...@xxxxxxxxxxxxxxx> wrote:
On Sep 4, 10:14 am, ELINTPimp <smsi...@xxxxxxxxx> wrote:



On Sep 4, 11:00 am, Kevin Davis <kevin.da...@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: Form Arrays
    ... I'm a new person when it comes to PHP and I have a quick question. ... employment site...do you have a form that gathers a users employment ... enter the information to the database until they are done. ... If they switch off and walk away, the transaction isn't marked as complete, and the data can be erased sometime later. ...
    (comp.lang.php)
  • Re: Form Arrays
    ... I'm a new person when it comes to PHP and I have a quick question. ... employment site...do you have a form that gathers a users employment ... enter the information to the database until they are done. ... If they switch off and walk away, the transaction isn't marked as complete, and the data can be erased sometime later. ...
    (comp.lang.php)
  • Re: Help please with the dreaded what if question
    ... proficient in php. ... One of the worst things you can do is keep this in a session. ... not be written to the database immediately, causing you to sell the last item twice. ... session data is not necessarily cleared from the database ...
    (comp.lang.php)
  • Re: remote sessions (database link, v$session)...
    ... if I understand what you want it is for session A running on ... database B to support the distributed transaction issued from A. ... The remote SID could be passed back. ...
    (comp.databases.oracle.misc)
  • Re: Objects and sessions
    ... >table in some other database. ... When the session ends, will the object die with it? ... memory or something, but I've never seen that done. ... The session "ends" when the file is erased, PHP has some built in stuff ...
    (comp.lang.php)