PHP - Best (or better) practice for Forms?

[David]

I have a web app that is forms intensive. These forms have a number
of dropdown lists, check box, etc., each which requires additional
processing, db calls, etc. On an item changed, I post back the form
and set a hidden field to tell PHP what changed so it knows what to
process.

Is there a preferred way to handle this type of forms processing? My
screen is a mix of hidden vars., Javascript, etc. which works but it
messy!

I guess I am looking for a web site of book on "The Zen" of php! Eg.
not so much how but how AND why.

Thanks

[Oli Filth]

Re: PHP - Best (or better) practice for Forms?

David said the following on 05/09/2005 23:58:[color=blue]
> I have a web app that is forms intensive. These forms have a number
> of dropdown lists, check box, etc., each which requires additional
> processing, db calls, etc. On an item changed, I post back the form
> and set a hidden field to tell PHP what changed so it knows what to
> process.[/color]

This relies on Javascript being enabled, and is a waste of bandwidth
(you need to send a load of extra HTML, and the form submission requires
a load of extra fields).

Why do you need to know exactly what was changed? Why not just update
everything when you've received the form submission?

If you're worried about speed, it will make virtually zero speed
difference whether you update one field in a table row, or the whole row.

If you need to identify changes in values to trigger specific actions,
then either extract the original values from the DB and do a comparison
server-side, or store the original values in $_SESSION.


--
Oli

[Chung Leong]

Re: PHP - Best (or better) practice for Forms?

The use of hidden fields to hold the "original value" of a field is bad
practice. If the field is modified in the mean time (through a
different window, for instance) then the forms will not be fully saved.

You don't get much from this kind of optimization. Just resave the
whole thing.

[Mladen Gogala]

Re: PHP - Best (or better) practice for Forms?

On Mon, 05 Sep 2005 17:58:40 -0500, David wrote:
[color=blue]
> Is there a preferred way to handle this type of forms processing? My
> screen is a mix of hidden vars., Javascript, etc. which works but it
> messy![/color]

require_once('H TML/QuickForm.php') ;

--

http://www.mgogala.com

[Rincewind]

Re: PHP - Best (or better) practice for Forms?

On 5 Sep 2005 20:42:33 -0700, Chung Leong wrote:



Have you ever considered quoting what your replying to?

[Erwin Moller]

Re: PHP - Best (or better) practice for Forms?

Rincewind wrote:
[color=blue]
> On 5 Sep 2005 20:42:33 -0700, Chung Leong wrote:
>
>
>
> Have you ever considered quoting what your replying to?[/color]

Hi Rincewind,

Most of us use a threaded newsreader.
What do you use?
Do you receive all there mails in your mailbox without a structure?
If so: why not start using a newsreader?
Many opensourced/free newsreaders are available.

Or do you have another reason to complain?
(I am just curious.)

Regards,
Erwin Moller

[Rincewind]

Re: PHP - Best (or better) practice for Forms?

On Tue, 06 Sep 2005 15:55:48 +0200, Erwin Moller wrote:
[color=blue]
> Rincewind wrote:
>[color=green]
>> On 5 Sep 2005 20:42:33 -0700, Chung Leong wrote:
>>
>> Have you ever considered quoting what your replying to?[/color]
>
> Hi Rincewind,
>
> Most of us use a threaded newsreader.
> What do you use?
> Do you receive all there mails in your mailbox without a structure?
> If so: why not start using a newsreader?
> Many opensourced/free newsreaders are available.
>
> Or do you have another reason to complain?
> (I am just curious.)
>
> Regards,
> Erwin Moller[/color]

1. Because it's the way Netiquette wants it.

2. Because I don't always receive all posts that are sent so it make no
difference what newsreader I use if it ain't there I can't read it.

3. If you want to know what newsreader I, or anyone else uses read the
headers, you for instance use KNode 0.7.1 and you post through
news.xs4all.nl server. ;-))

[David]

Re: PHP - Best (or better) practice for Forms?

The issue is changes in a dropdown box will require the app to perform
a DB lookup.

If the user changes a dropdown box, how can one tell the system to
postback and then what caused that postback. Unless you session all
of the vars or keep a hidden version of each, then you need to set
some switch to tell the system what occurred!

I will say this is MUCH easier in ASP.net.
[color=blue]
>
>This relies on Javascript being enabled, and is a waste of bandwidth
>(you need to send a load of extra HTML, and the form submission requires
>a load of extra fields).
>
>Why do you need to know exactly what was changed? Why not just update
>everything when you've received the form submission?
>[/color]

[LeagueWebmaster]

The issue is changes in a dropdown box will require the app to perform
a DB lookup.

If the user changes a dropdown box, how can one tell the system to
postback and then what caused that postback. Unless you session all
of the vars or keep a hidden version of each, then you need to set
some switch to tell the system what occurred!

I will say this is MUCH easier in ASP.net.

As a matter of security and an matter of bandwidth it's always better to determine your changes in the resultant web page your are submiting to. Get a extra hit to the database, query and build your update via PHP. Better yet though if you where running against MS SQL you'd do it in a trigger at the database, if your running in MYSql version five you'd also run it in a trigger on the database. If you can do it in a trigger always try there first. You can code update times, copy old records to log tables etc.. all via triggers.

:cool: MYSQL Tigger Docs
:cool: MS SQL Trigger Docs

[Alexey Kulentsov]

Re: PHP - Best (or better) practice for Forms?

David wrote:[color=blue]
> I have a web app that is forms intensive. These forms have a number
> of dropdown lists, check box, etc., each which requires additional
> processing, db calls, etc. On an item changed, I post back the form
> and set a hidden field to tell PHP what changed so it knows what to
> process.[/color]
When processing form on server just compare entered data and current
data from database to know that is changed. I use class for it who make
'changed' attribute for every db field so I can just check attribute.
[color=blue]
> Is there a preferred way to handle this type of forms processing? My
> screen is a mix of hidden vars., Javascript, etc. which works but it
> messy![/color]
All javascript code must be in one separate .js file. just link to it
on your form page and call procedure with one long-long parameter
describing all tests for this form. as here for example:

http://www.crimaniak.com/flat/

(see source, search for <form> tag)