Hi Dhanji,
Thanks for the example, that was very helpful.
It is possible to do some validation with the current API:
public Response purchase(@UriParam("creditCard") CreditCard cc,
@UriParam("email") EMail email) {
}
the requirement is that CreditCard and Email have a constructor that
takes a String parameter and throw a runtime exception if validation
fails, the runtime exception can be caught and transformed into a 400
(Bad Request).
An implementation of the parameter injection can still validate all
parameters even on the first failure, thus grouping errors.
One advantage of 303 is that String can be used but it does seem more
involved to invoke some bean checking rather than encapsulate
functionality. I suppose the CreditCard and EMail could encapsulate 303
functionality.
Paul.
Dhanji R. Prasanna wrote:
> OK =)
>
> Here's something off the top of my head: you purchase an ebook with a
> credit card and email to deliver the ebook to. A webservice invocation
> sends the credit card number and delivery email to a JaxRs application:
>
> @URITemplate("/eshop/books/{isbn}")
> public class BookPurchaseService {
>
> @HttpMethod(POST)
> public Response purchase(@Param("creditCard") String cc,
> @Param("email") String email, /** ISBN, etc. **/) {
> PurchaseOrder po = new PurchaseOrder(cc, email ...);
>
> //enter order...
> purchasingBiz.processOrder(po);
>
> //respond with receipt number or failure code
> }
> }
>
> Now if the card # or email is invalid, your biz logic will fall over
> with an exception. Typically you want to trap it before then to give a
> meaningful message back in to the client. With jsr303 you can do
> something like the following:
>
> public class PurchaseOrder {
> @Email(message = "invalid.email") private String email;
> @CreditCard(message = "invalid.cc") private String cc;
>
> ...
> }
>
> ...and correspondingly alter the http method:
>
> @HttpMethod(POST)
> public Response purchase(@UriParam("creditCard") String cc,
> @UriParam("email") String email) {
> PurchaseOrder po = new PurchaseOrder(cc, email);
>
> //invoke jsr303 runtime aka BeanCheck
> List<InvalidValue> errors = beanCheck.validate(po);
>
> if (errors.isEmpty())
> //enter order...
> purchasingBiz.processOrder(po);
> else
> //iterate errors and lookup the localized messages to send
> back (if necessary) to client
> }
>
>
> Dhanji.
>
> On 9/6/07, *Marc Hadley* <Marc.Hadley_at_sun.com
> <mailto:Marc.Hadley_at_sun.com>> wrote:
>
> Me too, an example would be great.
>
> Marc.
>
> On Sep 5, 2007, at 5:01 PM, Ryan McDonough wrote:
>
> > +1 from me. I'm interested in seeing what you're thinking Dhanji.
> >
> > Ryan-
> >
> > On 9/5/07, Paul Sandoz <Paul.Sandoz_at_sun.com
> <mailto:Paul.Sandoz_at_sun.com>> wrote:
> >> Dhanji R. Prasanna wrote:
> >>> An *initial* reaction suggests that we should leave this entirely
> >>> to a
> >>> user (bootstrap, validate, feedback error). However, since I
> >>> recall Paul
> >>> saying we want jsr311 to be a complete *usable* API it might be
> >>> worth
> >>> considering if/whether we want to integrate jsr303 in some (even
> >>> optional) way. For instance, in the Response.Builder.
> >>>
> >>> I can explain a bit more about how bean validation in jsr303
> >>> works if
> >>> anyone is interested. Thoughts?
> >>>
> >>
> >> IMHO it would be most helpful, at least to me!, to provide a
> >> couple of
> >> examples from the perspective of a 311 developer i.e. this will help
> >> explain why 303 is useful and what benefits it offers before we
> >> get into
> >> the deeper technical aspects of how 303 works and determine
> >> whether some
> >> optional integration is required.
> >>
> >> Paul.
> >>
> >> --
> >> | ? + ? = To question
> >> ----------------\
> >> Paul Sandoz
> >> x38109
> >> +33-4-76188109
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> >> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
> >>
> >>
> >
> >
> > --
> > Ryan J. McDonough
> > http://www.damnhandy.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com <http://sun.com>>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109