You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/05/12 17:32:47 UTC
Re: Packaging Struts Extras (Re: DO NOT REPLY [Bug 34849] - [new
feature] Expressi)on Language Field Validator
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 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.
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: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Packaging Struts Extras (Re: DO NOT REPLY [Bug 34849] - [new
feature] Expressi)on Language Field Validator
Posted by Don Brown <mr...@twdata.org>.
Joe Germuska wrote:
> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org