At 8:12 AM -0700 5/12/05, Don Brown wrote:
I agree commons-validator shouldn't have code that mentions Servlets or Struts, but they would benefit from a validator that uses jexl, which I believe isn't tied to servlets (I could be wrong here). If I'm not, why not put the el validator in commons-validator, but add a hook for folks like Struts to add variables in the immediate scope, ala Velocity and Velocity tools.
That sounds like a good approach. But it still leaves us with the question: if a rich JEXL-based validator would be useful in Struts (as in one which can populate the expression evaluation context with Struts-centric or Servlet-centric objects), the where does that go in Struts? At the moment, I have little taste for spawning yet another artifact, especially with no clear idea of what else would go in it.
I know Ted's been itching to start an "extras" project to include things DispatchAction and helpful plugins, and special validators would be a good match as well. Unfortunately, yes, that would be more work and no, I'm not particularly interested in setting it up at the moment :)
I take that back. It sounds like a reasonable approach -- but I fear for what it would take to get a new release of commons-validator cut so that we could depend upon it for Struts. I know I should roll up my sleeves, but it's busy season again, so there's no point in pretending I'd have time for that any time soon.
This reminds me of a quote I heard recently, "There comes a time where execution is more important than theory". Personally, I'd vote for sticking it in core (once it meets Niall's checklist) and worry about doing it "right" later, however, if some object, there is always the sandbox.
Don
Joe
Don
Joe Germuska wrote:
At 5:12 PM -0700 5/10/05, Don Brown wrote:
Actually, the extras I was referring to was for the commons-validator project itself as I mistook the ticket for a validator ticket. The Beanshell and xpath validators required only the commons-validator project and had nothing to do with Struts. Ideally, all validators could be added to the commons-validator project and be immediately reusable in environments like Struts and Spring. Unfortunately, the code is currently too muddled for that so Struts has to create a wrapper for every new validator/validation.
Also, at least in this case, I think one of the strong benefits is the
preparation of a meaningful expression evaluation context which includes
references to the ActionForm and the request and session scope, etc.
commons-validator has no business being bound to the servlet API or the
Struts API. (I suppose you could treat the form as a POJO and cover one
of those, but not both.)
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
