On 19.Jun.2001 -- 01:28 PM, Neeme Praks wrote:
> > > * form name
>
> Well, maybe this can be solved through some other mechanisms, but currently
> I'm using it to identify the form where to show errors. Real-life case:
> * I have a page with many forms.
> * I submit one of the forms, some errors occur (they do not have to be
> validation errors, could be some unexpected exceptions also).
> * Because of an error, I do an internal redirect back to the old page with
> many forms.
> * While generating the old page, I need to know on which form I should show
> the error(s).
OK. But you need to know which form was submitted in the first
place. So this is probably already encoded in the value of the submit
parameter or in the URL of the form's action attribute.
I think this is nothing the validation action know about. It only
knows about the constraint set it checks against.
So, do you think it would be a good idea to store the name of the
constraint set (and probably of the descriptor file) as well as an
request attribute? Provided that the only access such a page is
guarded by the validation action it would probably do to read out the
additional data from the descriptor file for input lengths etc. But
hold on, it wouldn't help if there were several forms on a page :-|
How should the name of the form be incorparated?
> > > * field name
> >
> > Thus when an error occured and the action directs the flow to the
> > error page every parameter has to be checked to see what when
> > wrong. Hence you're not provided with the name of the offending field
> > but with a per field status.
>
> well, then you already have the name of the field? :-)
Yes, indeed. I envisioned that error messages would appear close to
the input field itself. Like "input your name:____________ (please
do fill in this one!)". If you want to put a list with error messages
at the top of the form, this is probably not very convenient. Since
the results are stored in a Map you could iterate over it and see
which parameters violated the constraints.
> > > * related data (optional)
>
> It is dynamic. For example, I have an web-based email application (e.g.
> Hotmail) that allows to enter more than one email address in the "to" field.
> After the user has entered something, I run it though the validator that
> checks if the list was well formed. If the list was not well formed or if
> one of the addresses was incorrect, then I need to point out, which address
> was incorrect. With this dynamic data, I could stuff this data in there. Ok?
So far FormValidatorActions does only simple syntax checks and does
not explain the error to the user. Frankly, I don't think the user is
that dumb that (s)he will not figure it out. Well, if the constraint
is a regular expression (s)he will probably not be able to do it. But
the RE library does not indicate at wich point an expression
failed. And I don't see how this could be achieved easily.
I'm afraid that for those cases you'll either have to code such a
logic on your XSP or write an application specific action.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
