I think this is a strange approach. Info about the same object comes from
two different places in the same request? I am not sure if this is already
working in VRaptor, but for me the best solution is to receive an extra
parameter, with the id.

Em Fri Feb 13 2015 at 12:41:48 PM, Nykolas Laurentino de Lima <
[email protected]> escreveu:

If we have a resource class like this:

public class UserResource {
private long id;
private long accountId;
private String name;
}

If we want to populate id and name fields from JSON and accountId from
request param, this doesn't work:

@post("/accounts/{user.accountId}
@consumes("application/json")
public void addUser(User user) {
//user.getAccountId() will be null
}

I believe that we should deserialize the class from the JSON and if there
is any path param, we should override the value in the deserialized
resource.

—
Reply to this email directly or view it on GitHub
#940.

If we can't do this, we'll have to do something like this:

@post("/accounts/{accountId}
@consumes("application/json")
public void addUser(User user, long accountId) {
user.setAccountId(accountId);
}

In my applications, this is a common use, because them I have to transform
the resource class in the domain class. Don't you guys never had this use
case?
On Fri, Feb 13, 2015 at 12:45 PM Alberto Luiz Souza <
[email protected]> wrote:

I think this is a strange approach. Info about the same object comes from
two different places in the same request? I am not sure if this is already
working in VRaptor, but for me the best solution is to receive an extra
parameter, with the id.

Em Fri Feb 13 2015 at 12:41:48 PM, Nykolas Laurentino de Lima <
[email protected]> escreveu:

If we have a resource class like this:

public class UserResource {
private long id;
private long accountId;
private String name;
}

If we want to populate id and name fields from JSON and accountId from
request param, this doesn't work:

@post("/accounts/{user.accountId}
@consumes("application/json")
public void addUser(User user) {
//user.getAccountId() will be null
}

I believe that we should deserialize the class from the JSON and if there
is any path param, we should override the value in the deserialized
resource.

—
Reply to this email directly or view it on GitHub
#940.

—
Reply to this email directly or view it on GitHub
#940 (comment).

I agree with @nykolaslima. I have this use case.
For now I sent the 'accountId` within the JSON.

I believe that we should deserialize the class from the JSON and if there is any path param, we should override the value in the deserialized resource.

++1 for this proposal

IMO it makes sense to support it. And If user send the same key both
in json and path, the path param should override the json value. Is it ok?

It's perfect to me. Can I implement it and open a PR?
On Mon, Feb 16, 2015 at 11:16 AM Rodrigo Turini [email protected]
wrote:

IMO it makes sense to support it. And If user send the same key both
in json and path, the path param should override the json value. Is it ok?

—
Reply to this email directly or view it on GitHub
#940 (comment).

sure, it would be great! 👍