Programmatic @Path value providers/resolvers

(Email from Guilherme Silveira, [http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-03/message/90](http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-03/message/90) )

5\. URI Building

This is one that bothers me a lot. We should be writing OO code, not xml-oriented, not annotation-oriented, not string-oriented. So why so many annotations, strings and just one object? This is the refactor-friendly version of URI builder that we use in VRaptor so people can refactor code and things are still working:

@Resource
public class UserController {

// inject dao
public User show(long id)

{ return dao.load(id); }

}

@Resource
public class AdminController {

private final Result result;
private final UserDao dao;

// easy to mock, inject => easy to test
public AdminController(Result result, UserDao dao)

{ this.result = result; this.dao = dao; }

public void create(User created)

{ User created = dao.save(prototype); // refactor friendly + no URI hell result.redirectTo(UserController.class).show(created); }

}

Of course, if there is a @Path annotation on top of the method, the framework knows how to understand that. To do so we provide, again, everything configurable (and default versions):

public interface PathResolver {
String pathFor(ResourceMethod method);
}
public interface Proxifier {
T proxify(Class type, MethodInvocation handler);
}

This is the one that allows hypermedia resource generation in a refactor-friendly, non-annotation based way, i.e.:

public class Basket implements HypermediaResource {

public void configureRelations(RelationBuilder builder)

{ builder.relation("self").uses(BasketsController.class).show(id); builder.relation("payment").uses(PaymentsController.class).create(id, null); }

}
#### Affected Versions
[2.0]