Enhancement proposal: support Jersey like Parameters and Providers #204

Closed
dadg opened this Issue May 6, 2014 · 6 comments

Comments

Projects
None yet
3 participants
@dadg

dadg commented May 6, 2014

Hi,

Would it be possible to add a system to be able to support parameters classes and providers in the same way it's done in Jersey ?

I currently use it a lot in Jersey, and it would be awsome to have the same feature in Wisdom HTTP layer.

Here are 2 articles that explains better than me what I would like to have:

What Makes Jersey Interesting: Injection Providers
What Makes Jersey Interesting: Parameter Classes

Thanks a lot.
WBR // David

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier May 6, 2014

Member

Hi,

On 6 mai 2014, at 16:35, David G. notifications@github.com wrote:

Hi,

Would it be possible to add a system to be able to support parameters classes and providers in the same way it's done in Jersey ?

I currently use it a lot in Jersey, and it would be awsome to have the same feature in Wisdom HTTP layer.

Here are 2 articles that explains better than me what I would like to have:

What Makes Jersey Interesting: Injection Providers
What Makes Jersey Interesting: Parameter Classes

Both can definitely be implemented without too much burden. Could you open an issue on https://github.com/wisdom-framework/wisdom/issues. I think it can be included in the 0.6 (mid-june). The idea would to expose a specialized service responsible of the object creation called when the router invokes the route.

I don’t really like the @context annotation, and I would prefer a @http or something different. @context is kind of misleading here.

Regards,

Clement

Thanks a lot.
WBR // David


Reply to this email directly or view it on GitHub.

Member

cescoffier commented May 6, 2014

Hi,

On 6 mai 2014, at 16:35, David G. notifications@github.com wrote:

Hi,

Would it be possible to add a system to be able to support parameters classes and providers in the same way it's done in Jersey ?

I currently use it a lot in Jersey, and it would be awsome to have the same feature in Wisdom HTTP layer.

Here are 2 articles that explains better than me what I would like to have:

What Makes Jersey Interesting: Injection Providers
What Makes Jersey Interesting: Parameter Classes

Both can definitely be implemented without too much burden. Could you open an issue on https://github.com/wisdom-framework/wisdom/issues. I think it can be included in the 0.6 (mid-june). The idea would to expose a specialized service responsible of the object creation called when the router invokes the route.

I don’t really like the @context annotation, and I would prefer a @http or something different. @context is kind of misleading here.

Regards,

Clement

Thanks a lot.
WBR // David


Reply to this email directly or view it on GitHub.

@dadg

This comment has been minimized.

Show comment
Hide comment
@dadg

dadg May 6, 2014

Hi,

Thanks for the quick answer. The issue is already done.

For the annotation name, I have no strong opinion. I don't want necessary to have the same annotations as Jersey nor interfaces, as long as I can code the same behavior.

Thanks so much.
WBR // David

dadg commented May 6, 2014

Hi,

Thanks for the quick answer. The issue is already done.

For the annotation name, I have no strong opinion. I don't want necessary to have the same annotations as Jersey nor interfaces, as long as I can code the same behavior.

Thanks so much.
WBR // David

@cescoffier cescoffier added this to the 0.6 milestone May 6, 2014

@barjo

This comment has been minimized.

Show comment
Hide comment
@barjo

barjo May 6, 2014

Member

+1 for it


Jonathan

On Tue, May 6, 2014 at 10:10 PM, David G. notifications@github.com wrote:

Hi,

Thanks for the quick answer. The issuehttps://github.com/wisdom-framework/wisdom/issues/204is already done.

For the annotation name, I have no strong opinion. I don't want necessary
to have the same annotations as Jersey nor interfaces, as long as I can
code the same behavior.

Thanks so much.
WBR // David


Reply to this email directly or view it on GitHubhttps://github.com/wisdom-framework/wisdom/issues/204#issuecomment-42314951
.

Member

barjo commented May 6, 2014

+1 for it


Jonathan

On Tue, May 6, 2014 at 10:10 PM, David G. notifications@github.com wrote:

Hi,

Thanks for the quick answer. The issuehttps://github.com/wisdom-framework/wisdom/issues/204is already done.

For the annotation name, I have no strong opinion. I don't want necessary
to have the same annotations as Jersey nor interfaces, as long as I can
code the same behavior.

Thanks so much.
WBR // David


Reply to this email directly or view it on GitHubhttps://github.com/wisdom-framework/wisdom/issues/204#issuecomment-42314951
.

@dadg

This comment has been minimized.

Show comment
Hide comment
@dadg

dadg May 6, 2014

Hi,

Also I've just found the @BeanParam concept in Jax-RS 2.0. Some documents links

I didn't use it (still use Jersey 1.x) but it seems to be a very elegant IMHO, even if it's not exactly for the same purpose as in my previous request.

You may find useful to also provides the same mecanism in Wisdom Framework ?

WBR // David

dadg commented May 6, 2014

Hi,

Also I've just found the @BeanParam concept in Jax-RS 2.0. Some documents links

I didn't use it (still use Jersey 1.x) but it seems to be a very elegant IMHO, even if it's not exactly for the same purpose as in my previous request.

You may find useful to also provides the same mecanism in Wisdom Framework ?

WBR // David

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier May 7, 2014

Member

Definitely,

They have really good ideas to ease the parameter parsing. May even have a look in the next few days to draw a first proposal.

On 6 mai 2014, at 18:37, David G. notifications@github.com wrote:

Hi,

Also I've just found the @BeanParam concept in Jax-RS 2.0. Some documents links

I didn't use it (still use Jersey 1.x) but it seems to be a very elegant IMHO, even if it's not exactly for the same purpose as in my previous request.

You may find useful to also provides the same mecanism in Wisdom Framework ?

WBR // David


Reply to this email directly or view it on GitHub.

Member

cescoffier commented May 7, 2014

Definitely,

They have really good ideas to ease the parameter parsing. May even have a look in the next few days to draw a first proposal.

On 6 mai 2014, at 18:37, David G. notifications@github.com wrote:

Hi,

Also I've just found the @BeanParam concept in Jax-RS 2.0. Some documents links

I didn't use it (still use Jersey 1.x) but it seems to be a very elegant IMHO, even if it's not exactly for the same purpose as in my previous request.

You may find useful to also provides the same mecanism in Wisdom Framework ?

WBR // David


Reply to this email directly or view it on GitHub.

@cescoffier cescoffier added the feature label May 7, 2014

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier May 9, 2014

Member

Just to summarize and sketch out a list of task:

  1. add support for @PathParameter, @QueryParameter, @HttpHeader and @HttpContext
  2. add support for @DefaultValue
  3. add support for parameter converters to map the input data (String) to the required type. We should support primitive types, class having a constructor with a String parameter, class with a valueOf or fromString static methods, a valid parameter converter service or an array of these types.
  4. add support for a 'bean converter' that can map the current HTTP Context and request to a bean class

About 4, the bean class can use the same annotations as the action method. To simplify, only setter method using the annotation will be supported:

public void setAccept(@HttpHeader("accept") String header) { ... }
public void setPayload(@Body MyData data) { ... }
Member

cescoffier commented May 9, 2014

Just to summarize and sketch out a list of task:

  1. add support for @PathParameter, @QueryParameter, @HttpHeader and @HttpContext
  2. add support for @DefaultValue
  3. add support for parameter converters to map the input data (String) to the required type. We should support primitive types, class having a constructor with a String parameter, class with a valueOf or fromString static methods, a valid parameter converter service or an array of these types.
  4. add support for a 'bean converter' that can map the current HTTP Context and request to a bean class

About 4, the bean class can use the same annotations as the action method. To simplify, only setter method using the annotation will be supported:

public void setAccept(@HttpHeader("accept") String header) { ... }
public void setPayload(@Body MyData data) { ... }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment