|
|
Posted by The Natural Philosopher on 09/05/07 02:23
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
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.
>
Navigation:
[Reply to this message]
|