Posted by Jerry Stuckle on 09/05/07 02:38

The Natural Philosopher wrote:
> Jerry Stuckle wrote:
>> The Natural Philosopher wrote:
>>> ELINTPimp wrote:
>>>> On Sep 4, 11:36 am, Kevin Davis <kevin.da...@kevincdavis.net> wrote:
>>>>> On Sep 4, 10:14 am, ELINTPimp <smsi...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Sep 4, 11:00 am, Kevin Davis <kevin.da...@kevincdavis.net> 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
==================

[Back to original message]