> FormProc can do as much or as little as you like.  If you 
> only specify a 
> validator then the values will only be validated.  If you want to use 
> FormProc to do type conversion then you can specify a type converter. 
>  This goes the same for storing the data (in a bean, hash map, etc),
> 
> Regarding alternative methods for validation: I believe that 
> it is up to 
> the developer using FormProc as to how they want to validate. 
>  The nice 
> thing about FormProc is that you can do what you want with it.

That's fair. As long as I don't have to use all of it. 
  
> >
> The actual integration with WebWork would probably have to be done by 
> someone else as a.) I am not intimately familiar with WebWork, b.) I 
> don't have a lot of time to work on it.  The main reason I suggested 
> FormProc was because it is mature and has already gone through issues 
> like i18n.

Yeah, no problem. I'm talking about me doing it, just trying to judge if
it's a good fit and I should look into it more.

> 
> I don't think it would be exceptionally difficult to 
> integrate FormProc 
> and WebWork though.  Your interceptor would need to call the method:
> 
>    process(FormData[] formData, Locale locale) throws Exception;
> 
> ...which is in the Form class.  You can see an example of 
> extending the 
> Form class in the HttpForm class, which converts an 
> HttpServletRequest 
> to an array of FormData objects.  

So do Actions have to extend Form? That's a big drawback. Would it be
possible to abstract that? Or just automatically wrap a bean? Right now
what I've got is field validators that are given the name of the field
to work on, and can use Ognl to get the value of the field (Ognl uses
reflection under the covers to get it) and can use it in validation.

> The configuration is completely 
> pluggable as well, by implementing the FormConfiguration 
> interface.  The 
> FormManager class then allows you to add named configurations 
> which are 
> then retrieved when the Form by the same name is passed to the 
> FormManager.configure() method.

Ok, so this is where I could plug in the auto-finding configuration, or
is that already built in?

> 
> There was also talk of an abstraction for pluggable 
> validation.  Anyone 
> working on this yet?

Interceptors allow anything to be pluggable! :-) Seriously, I
implemented this validation stuff as an Interceptor, and just about
anything else like this which is orthogonal to the execution of an
Action can be done this way, including plugging in any validation
framework you wanted.

Jason


-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to