Almond wrote:

> I do some experiment. The code to read and re-submit is ok. So, I think it
> is not difficult to write the remaining code. Now I want to know is :
>
> 1. How many record have you post back in one batch. Is that 200+ record
> would cause problem ? I think the size should not exceed 50K. Any problem
> if the connection speed is slow (<10K) ?

Depends on how much your webserver can handle :). Check php.ini to see
how much memory can a single script consume. I use Apache 1.3 with PHP
4.3, IIRC the default was 8MB, and I haven't had any problems with that
so far. You can always limit the number of rows on screen and force
users to click "Next >>" and "<< Prev" buttons or whatever. If they are
really searchin for something, provide the search for them. Noone likes
to browse table with 1000 rows just to find the one (s)he needs.

As for the speed, there are two issues. First is the amount of data
(html) sent to the browser. You can test it yourself, everything below
100kB is acceptable (for me). Other issue is updateing/inserting into
database. Be sure to use prepared statements and just fill parameter
values and execute. If you're about to edit the entire tables, you can
make one hidden field which shows wheter any field in that row is
changed, so you don't have to update rows which are left intact. It can
be all automated with javascript, but be very careful about it. JS
doesn't handle fields with [ and ] in name very well, so you'll have to
think of some other way of accessing it. I use searchig for substring in
input element's name. If you have a lot of controls it can be somewhat
slow on some older machines (like Pentinum I or similar). But there are
some ways to reduce the number of searches... but that's a topic for itself.

There is alternative way to name your input fields numerically or
somewhat similar (field00010003, field00010002) which mark rows and
columns, which gives you almost instant JS, but you would have an extra
job when the form is posted... you'd have to parse all input variables
and turn them into appropriate php array or whatever you like. Php's
variable variable names (the thing with $$var_name) come very handy for
that.

> 2. Any comments on that kind of code ? Is that post back so many variables
> (2,000+) would cause problem, ?

It shouldn't. It works for me (TM), but you can easily test yourself. I
find PHP to be very robust and capable of handling any amount of data.

I suggest you to do this only when it's really needed. Web applications
are made to be web applications, and trying to make something other of
it can result in very complex and hard to understand code.

--
Milan Babuskov
http://fbexport.sourceforge.net