Hi Kai,
This isn't (just) a plug, but theres a chapter in our
soon-on-the-shelves-book where I implemented an alternative validation
framework with Flex, which is particularly useful with multi-page forms
(such as the Accordion) with a single submit button.
In that framework we show how we can block the user submission of the
form until all fields are valid, and give more immediate feedback to the
user about the validation state of each field - as soon as they start
typing, the validator kicks in, rather than the default on-lose-focus.
However, we decided to stick with the default behaviour of not invoking
validation until the user had typed something into a field.
We had some good discussions with Matt during the development/writing
about the different solutions for form validation handling, and we're
not claiming what we produced is better than the default - its is just
an alternative. However, the solution does show the power of Flex.
I'd like to post the code I created here, but I don't think the
publisher would like that :)
Cheers,
Ali
--
Alistair McLeod
Development Director
iteration::two
Co-Author "Developing Rich Clients with Macromedia Flex"
Available June 2004 from Macromedia Press
On Wed, 2004-05-12 at 22:49, Kai KÃnig wrote:
> Hi Matt,
>
> MC> Hope this clarifies things,
>
> yes, it sure does! Thanks for that! Let me just comment on you,
> because I couldn't fully agree with you ;)
>
> Let's imagine a form in the context of the order processing of a
> shopping cart. When the user follows the process, why should he leave
> a certain field open to fill in later? I don't see a use for that. For
> me, one big advantage of the Flex validation would be that if I tab
> out of an empty required field I instantly will receive an error
> message. I'm sure that there is a way to trigger the validation of the
> certain field capturing the key event or whatever in AS, but I would
> really like to be able to choose how my validation should behave.
>
> There might be situations where the application should behave like you
> described, I don't know. But in my sense of understanding validation
> it means that a required field is required - always and not just if I
> entered something before.
> Otherwise - let's say my form is completly empty at the start - I
> could tab throught an n-fielded form and pushing my "action"-button
> and will receive my validation result during click time. For me that's
> not the "natural" behaviour, it's very similar to HTML forms with some
> JavaScript which checks for errors after collecting all that data -
> which I always disliked ;)
>
> Cheers
> Kai
>
>
> MC> It is intended behavior that if you do not
> MC> change anything in an initially blank field the validator will not fire.
> The
> MC> reason we did this is that many times a user will tab through a
> fieldintending
> MC> to fill it in later, so we found it to be frustrating when the field
> MC> immediately turned red ("how can my value be invalid when I didn't
> MC> enter anything yet?"). Additionally, if you had an alert or some other
> obtrusive
> MC> mechanism to indicate that validation had failed it was even more
> frustrating
> MC> to the user. So we decided if they didn't actually change the value and
> MC> the value had not been set before, don't fire validation. Essentially
> MC> you have to get one real value (not null, not undefined, not empty
> string) before
> MC> binding and validation will start to fire.
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
