----- Original Message -----
From: "John Wells" <wellsdjohn@xxxxxxxxx>
On 5/3/06, Satyam <Satyam@xxxxxxxxxxxxx> wrote:
I used that method initially, some months ago, but finally dropped it. It
looked nice at first, but then I started getting into problems and
required
too many special cases to make it work. In the end, it wasn't a clean
nor
elegant solution.
Satyam,
Would you care to give some more details as to those edge cases that
swayed you to drop the unique id approach? I've just recently added
it to my forms (for those that I find need it), in addition to the
redirect method you outlined below. Those two combined seem to really
go the distance in creating a reliable exchange of data between client
and server, as well as a better experience for the user (since the
form is capable of handling a larger set of error cases)
----------------------------------------
Actually, I don't know if any of those 'fixes' actually did anything. I got
some repeated log records (some of the operations were updates so they
wouldn't harm the data, only update again what was already updated, but the
log showed me both updates) and I can't really tell what was wrong and, in
the end, those attempts at fixing them didn't work so they didn't fix
anything. The redirection technique (which I learned about in this list)
never failed me so in the end I dropped investigating any further, and I use
that one alone.
---------------------------------------
Also, with regards to sending success/failure messages across the
redirection of your forms, I'd recommend considering sessions for
passing the data. It keeps your URLs clean, and allows you to send
complex data a bit easier (IMHO). For example if a user makes an
error on a few different form elements, you can send back an array of
messages to the user without having to serialize/unserialize in the
ugly URL.
-------------------------------------------
It took a while for me to get used to accept to rely on session data and I'm
still not completely comfortable with it. In a couple of places where the
confirmation data would be too large to send in the URL, I would just send
the primary key and re-read the data from the database, hopefully still
cached and not requiring any actual disk access.
As for the error messages, they don't go into the redirection which I only
do on success. At first I did concatenate errors into a string, each
enclosed in <p> tags and all shown in a <div class="errormessage">. In one
app, and that is the style I will probably follow from now on, the error
messages go into an array with the input field name as the key so each
message can be shown right by the corresponding field. Actually a style I
liked and will try in some real site is to put a simple and small error icon
and have the text of the message in the 'alt' attribute so it shows when the
cursor is over the icon. In that way, you can signal the place of the error
without disrupting the layout of the form with a long text but you are not
limited to show too brief a message. Most of the time, the user will
realize what the error was anyway. (I'm talking about an intranet system
with trained operators and somewhat dense forms). I fancy a floating div
somewhere around but not covering the input field in error might also work,
like a cartoon balloon dialog, but I'm not sure about it.
Satyam
-John W
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
