struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34849] - Expression Language Field Validator
Date Thu, 02 Jun 2005 01:09:28 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34849>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34849





------- Additional Comments From niallp@apache.org  2005-06-02 03:09 -------
(In reply to comment #21)
> At this time, I feel that
> using the PageContext implementation provides clarity to people familiar with
> writing JSTL expressions in that context;

I think it could create as much confusion as clarity. PageContext makes no 
sense in the "context" this validator operates in. Also, some people might 
confuse the PageContext in a jsp that renders the form with the one available 
to this validator. And it won't make any sense to people who don't use JSP's 
for their view (OK thats probably the minority). Also, interestingly enough, if 
you look at JSF - pageContext isn't available as a predefined object in the 
value binding expression language there - though I guess thats not relevant.

> also, the actual ActionContext isn't
> available for the expression evaluation as it is now, since it isn't passed 
into
> the validation process -- so if we didn't use this PageContext implementation,
> we'd have to do something else comparably artificial.
> On the other hand, maybe something comparably artificial is fine, especially 
if
> it's more "struts like" in other ways.  I'll wait for a few strong opinions, 
but

Its not passed in now, but with the Struts 1.3 this is the logical direction - 
if it wasn't for compatibility wouldn't we have changed the ActionForm's 
validate() method to take a WebContext already? There is a mechanism in 
validator to pass in objects through the "o.a.c.v.Validator" object and it 
would be simple to have it so that it works now and in the future when/if the 
WebContext is available:

public static boolean validateExpression(Object form,
                                         ValidatorAction va,
                                         Field field,
                                         ActionMessages errors,
                                         Validator validator,
                                         HttpServletRequest request,
                                         ServletContext application) {

    // Web Context
    WebContext webContext = (WebContext)validator
              .getParameterValue(Resources.WEB_CONTEXT_PARAM);
    if (webContext == null) {
        webContext = new ServletWebContext(application, request, null);
        validator.setParameter(Resources.WEB_CONTEXT_PARAM, webContext);
    }

    JexlContext jc = JexlHelper.createContext();
        
    jc.getVars().put("form", form);
    jc.getVars().put("requestScope", webContext.getRequestScope());
    jc.getVars().put("sessionScope", webContext.getSessionScope());
    jc.getVars().put("applicationScope", webContext.getApplicationScope());
        
    jc.getVars().put("param", webContext.getParam());
    jc.getVars().put("paramValues", webContext.getParamValues());
    jc.getVars().put("header", webContext.getHeader());
    jc.getVars().put("headerValues", webContext.getHeaderValues());
    jc.getVars().put("cookie", createCookieMap(request));
    jc.getVars().put("initParam", webContext.getInitParam());

    ...
}

Not only does the dependency go, also the whole createMap() method disappears - 
with v.little additional coding. Also looks to me like Chain's WebContext could 
do with a getCookieMap() method for completeness - that would remove the need 
for the createCookieMap() method as well.

Doing it this way also means that all these scope Maps are only created once 
per form validation - however many fields are using the expression validator.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message