Hmmm, the example below looks a lot like a specialization of
javax.interceptor.*...
Marc.
On Sep 7, 2007, at 9:06 AM, Ryan McDonough wrote:
>
> I agree with Paul's comment that some of the validation logic could
> be a bit
> more complex and it would be best left in the value beans
> themselves. Taking
> that a little further, maybe we could provide a way to perform the
> validation automatically through some type of callback mechanism.
> Taking
> Paul's example a little further with half-baked thought I had:
>
> @RequestListener({Jsr303ValidationListener.class})
> class Something {
>
> @ValidateRequest(autoValidate=true)
> public Response purchase(@UriParam("creditCard") CreditCard cc,
> @UriParam("email") EMail email) {
> ...
>
> }
>
> The ValidateRequest annotation could be used to declare that the
> use wishes
> to handle the the validation automagically by the listener.
> In this instance, a listener is applied to method parameters before
> the
> method is called. If the beans are annotated with JSR-303
> annotations, the
> validation will be performed and some type of error response will be
> generated by the listener. The messages used in the respose could
> be pulled
> from the JSR-303 annotations. When errors are found, the target
> method is
> never executed.
>
> Another nice thing about this that you wouldn't restricted to just
> JSR-303
> validation:
>
> @RequestListener({HibernateValidator.class})
> class Something {
>
> @ValidateRequest(autoValidate=true)
> public Response purchase(@UriParam("creditCard") CreditCard cc,
> @UriParam("email") EMail email) {
> ...
>
> }
>
> In this instance, we could plug in Hibernate's validation framework
> instead,
> or any other type of validation framework. Taking it even further,
> we could
> also apply Response listeners as well if needed. Thoughts?
>
> Ryan-
>
>
> On 9/7/07, Paul Sandoz <Paul.Sandoz_at_sun.com > wrote:
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>>
>
>
> --
> Ryan J. McDonough
> http://www.damnhandy.com
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.