11:26 p.m.
Hi Ed... Don't forget that EL has String-based "type coercion" and then
there's the basic PropertyEditor stuff from java.beans. Beans binding (JSR
295) was expected to have some notion of conversion IIRC, and that's only
the JCP stuff. Spring and others have done conversion frameworks as well,
with what are arguably varying degrees of success. I think it's possible
to do good, fully-featured Java object conversion, but that (a) it's bigger
than can comfortably fit in Bean Validation and (b) it's a shame to limit
the feature to conversion when the more generic term "transformation" can
encompass the closely-related concept of object *copying*.
Shameless self-promotion: see the Therian library [1]. Docs are more or
less nonexistent as of now, but Therian provides transformation plumbing so
that you can say, e.g.:
public Bar convertToBar(@NotNull Foo foo) {
final Bar result = therianContext.eval(Convert.to(Bar.class,
Positions.readOnly(foo));
return result;
}
I conceived Therian when I was working with JSF so TherianContext extends
ELContext. My goal was that it should be easy to plug Therian into JSF for
conversions. I haven't actually gotten around to trying this yet, but
Therian was based on my experience as a user and developer of the older
Morph transformation (etc.) library, and having found it quite easy to plug
my Morph transformations into JSF, I don't anticipate any difficulty.
Personally, I like Therian's design, but I am also aware that some will
find it a bit unwieldy (in the unlikely event that anyone ever even learns
of its existence ;P ). I would hope that any broader JSR would be
interface-based so as not to preclude the like of Therian being plugged in
as a potential implementation, but I can tell you I am exhausted just
imagining a specification negotiation in the object transformation space.
br,
Matt
[1] https://github.com/mbenson/therian
[2] http://morph.sourceforge.net/
On Fri, Jul 12, 2013 at 3:27 PM, Edward Burns <edward.burns(a)oracle.com>wrote:
Hello Volunteers,
I've been viewing Emmanuel's videos about BV 1.1 and whenever he talks
about Bean Validation and JAX-RS, such as this
@Path("/user")
class UserResource {
@Post
@Consumes("application/x-www-form-urlencoded")
public void register(
@NotEmpty @FormParam("firstname") String firstname,
@NotEmpty @FormParam("lastname") String lastname,
@NotNull @Email @FormParam("email") String email) { ... }
}
I have to ask myself, isn't this missing something? What about
conversion?
Before Bean Validation, JSF brought type conversion *and* validation to
the table. Now that Bean Validation provides the validation part for
all of JavaEE, isn't it time we think about the other part: type
conversion?
JSF has an elaborate conversion system with by-type conventions and also
the ability to manually declare that specific converters should be used
for specific values. It's not a far cry to realize that we don't need
to limit ourselves to "String" for these arguments and there is a lot we
could do to enable arbitrary types and have Bean Validation handle the
conversion on the way in.
JAX-RS also has the javax.ws.rs.ext.ParamConverter facility, which
solves the conversion problem in a JAX-RS specific way.
Here we have two specs that do conversion. I think it might be useful
to realize that type conversion is really just the first part of
validation, and therefore falls under the responsibility of Bean
Validation.
Is this worth pursuing?
Ed
--
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev