Future standard GUI library

[Chris Angelico]

On Fri, Jun 14, 2013 at 3:39 PM, Frank Millman <frank at chagford.com> wrote:
>> It's not either-or. The server *MUST* perform the checks at the time
>> of form submission; the question is whether or not to perform
>> duplicate checks earlier. This is an absolute rule of anything where
>> the client is capable of being tampered with, and technically, you
>> could violate it on a closed system; but it's so easy to migrate from
>> closed system to diverse system without adding all the appropriate
>> checks, so just have the checks from the beginning.
>>
>
> In my case, it is either-or. I do not just do field-by-field validation, I
> do field-by-field submission. The server builds up a record of the data
> entered while it is being entered. When the user selects 'Save', it does not
> resend the entire form, it simply sends a message to the server telling it
> to process the data it has already stored.

Ah, I see what you mean. What I was actually saying was that it's
mandatory to check on the server, at time of form submission, and
optional to pre-check (either on the client itself, for simple
syntactic issues, or via AJAX or equivalent) for faster response.

As a general rule, I would be inclined to go with a more classic
approach for reasons of atomicity. What happens if the user never gets
around to selecting Save? Does the server have a whole pile of data
that it can't do anything with? Do you garbage-collect that
eventually? The classic model allows you to hold off inserting
anything into the database until it's fully confirmed, and then do the
whole job in a single transaction.

But if you want to use a "wizard" approach, where the user enters one
thing and then moves on to the next, that can work too. It gets clunky
quickly, but it can be useful if the early responses make the
subsequent questions drastically different.

ChrisA