|
|
Posted by The Natural Philosopher on 09/04/07 17:44
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.
> 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' ;-)
Navigation:
[Reply to this message]
|