Re: Validator design considerations

2001-11-04 Thread David Morris
Ted, I would agree, the framework presented should fit most needs. Those of us that work outside of Java on the server appreciate the flexibility of the XML definition and it would be a step backward to tie this to Java. I am confident that the structures presented will work for almost any val

Re: Validator design considerations

2001-11-03 Thread Ted Husted
I just want to make sure that everyone watching this thread is aware that Struts does have a Validator, configured with an XML file, that uses regular expressions or Javascript, and peforms that same validations both client-side adn server-side, which many of us have been using since April. It's a

Re: Validator design considerations

2001-11-02 Thread David Morris
Group, I have read these comments on validators with interest. Experience tells me that most (99.9%+) validations can be performed with a validator, an error id, the value, and the value's container. Of course the container could be a struts form, but it would be nice if it could be a collect

Re: Validator design considerations

2001-11-02 Thread Paul Speed
Ted Husted wrote: > > "Sobkowski, Andrej" wrote: > > What if the > > validation on the same bean is different depending on the app context? It > > wouldn't be "clean" (for lack of better word) to consider both validations > > inside the bean itself (validate())... hence the advantage of having

Re: Validator design considerations

2001-11-02 Thread Adam
I actually built out a very similar framework back in my ATG days. Greate minds stink alike Not so sure how much logic you want to put into the XML. I would rather have Form validators that have access to a slew of page validation rules. One possiblity is MyFormValidator extends FormVal

Re: Validator design considerations

2001-11-02 Thread Ted Husted
"Sobkowski, Andrej" wrote: > What if the > validation on the same bean is different depending on the app context? It > wouldn't be "clean" (for lack of better word) to consider both validations > inside the bean itself (validate())... hence the advantage of having > separate validation processes o

RE: Validator design considerations - really a problem of meta data

2001-11-02 Thread Bill_Wallace
<[EMAIL PROTECTED]> cc: 11/02/01 02:03 PM Please respond to Subject: RE: Validator de

RE: Validator design considerations

2001-11-02 Thread David Winterfeldt
> Did I manage to change > your mind? :) If the ActionForm was just a pure data bean I would agree, but it isn't really. There are already a number of layers to the current system to add and customize funcionality. I do like the idea of having a base set of validations you could define

Re: Validator design considerations

2001-11-02 Thread David Winterfeldt
I don't mind the idea of combining or changing the XML configuration for validations. I think that the validation rules are getting very long at the top of the Validator and need to be moved to a separate file (at least for the default ones). I have some comments interspersed below on some other

RE: Validator design considerations

2001-11-02 Thread Sobkowski, Andrej
be cleaner by separating the validators from the beans themselves. Did I manage to change your mind? :) Andrej -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, November 02, 2001 12:40 PM To: Struts Developers List Subject: Re: Validator design considerations

Re: Validator design considerations

2001-11-02 Thread Ted Husted
Andrej Sobkowski wrote: > - The form bean itself is a "special data holder" and shouldn't be aware of > how its data is validated. Do you agree? I'm not sure that I do. I like to think of the ActionForm as a firewall. If it has passes the intial validation, then I know it is "safe" to use, and ca