I had something like that in mind initially, but when I whittled it down
to just return type and args, it seemed like overkill. But if you want
to be able to test for modifiers and other more complex stuff, then it
would be good to do it that way.
As for multiple acceptable return types or param types, I was thinking
you'd just use one validator for each acceptable combination. But I
guess that could end up creating a lot of them. For example, If you'll
accept a method that takes either no args or ValidationError and returns
either void or Resolution, that would require four different validators.
Maybe I'm off my rocker, but we could make this really easy by having
the validator extract information from a class that defines what is
acceptable. For example, you could create a validator by passing it a
class that looks like this:
public final class Prototypes {
public interface ValidationMethods {
public void validate();
public void validate(ValidationErrors errors);
public Resolution validate();
public Resolution validate(ValidationErrors errors);
}
}
You'd then create it with a single line like:
MethodValidator validator = new
MethodValidator(Prototypes.ValidationMethods.class);
The validator would use reflection to get the information it needs. I
could also write the proposed "builder-style" API so a MethodValidator
can be created on the fly if need be.
-Ben
Tim Fennell wrote:
The problem I see with this is that in most cases the checks are:
1. The return type should be void or Resolution (for example), but not
another type.
or
2. The method should take ValidationErrors as a parameter or no
parameters at all
The other thing that it'd be nice to include in this is to be able to
check modifiers (is it static, abstract, final etc)
I wonder if an API like the hibernate Criteria API might work nicely, e.g.
new MethodValidator()
.returnType(Resolution.class, /* required = */ false)
.addParameter(ValidationErrors.class, false)
.isStatic(false).isAbstract(false);
-t
On Nov 21, 2006, at 8:47 AM, Ben Gunter wrote:
OK, I'm sending this to the dev list.
My thinking runs along these lines. We need to validate at most two
things about a method before calling it: the return type and the
parameter types. Most of the time we don't care about the return
type, but the parameter types always need to be checked. Pretty much
all that's left is the name of the method and the exceptions it
throws. If you're going to validate the name of the method then you
might as well put it in an interface and be done with it, so that
shouldn't be a concern. The exceptions shouldn't matter either.
That makes the validator pretty simple. The constructor takes
(Class<?> returnType, Class<?>[] parameterTypes). If the return type
is null then it will be ignored. Since parameter types always should
be checked, a null argument there will mean a void argument list,
just like with Method.invoke(...).
I was thinking of pretty basic usage, like:
MethodValidator mv = new MethodValidator(null, ValidationErrors.class);
if (mv.validate(method)) {
method.invoke(object, args);
} else {
Log.error("A detailed explanation of what was expected and what
we found.");
}
-Ben
Tim Fennell wrote:
#3 sounds good to me. The only thing that I think will need some
serious thought is how it should work - i.e. what arguments it
should take. I think almost everywhere the requirements are
somewhat lax, e.g. returns anything, but takes zero or one
parameters of type X. It'd be nice to figure out an easy way to
encapsulate the acceptable-ness of method - especially if that meant
the tester could then generate detailed messages about what the
requirement was and why a method failed :)
Btw, feel free to post these kinds of things to Stripes-Dev (just
start with Hey Tim so I know to respond to it!) - I think it's
probably good to keep these kinds of conversations as open as possible.
-t
On Nov 20, 2006, at 8:51 PM, Ben Gunter wrote:
Hey, Tim. Take a look at STS-310:
http://stripes.mc4j.org/jira/browse/STS-310
We can handle this in several different ways:
1. Check for the expected method signature(s) and if one is
found then handle it normally. If the method signature
differs from what's expected, then pass some default values
in for all the args (null for Objects, 0 for
short/int/long/float/double, etc). This is probably not a
good idea because quietly passing arbitrary values to a
method can lead to behavior that's difficult to trace.
2. Try to call the method and catch any IllegalArgumentException
that might be thrown and log it.
3. Create a MethodSignatureValidator that can be used to check
the signature before trying to call a method.
I have already implemented #2 and it works, but I started thinking
maybe #3 would be a good idea. A lot of features in Stripes rely on
annotations on methods to indicate how those methods should be
used. We don't implement interfaces so we don't have the
compile-time checks to ensure we're getting valid code. I think
it's a good idea for the future (and present) to have a utility
like this to validate methods before we try to call them. Of
course, I'll write it so you don't have to worry about it :)
Thoughts?
-Ben
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
<http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________>
Stripes-development mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/stripes-development
------------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
