Feature request: Secure parameter binding

I see 3 options for that issue:

1) Provide an helper class that delegates to the jakarta common beanutils
2) Add a new annotation: @NoBinding
3) As I happen to work on the @As annotation that is a binding annotation, add a new attribute for it that exclude a propery: @As(exclude="myAttribute")

I am still debating between option 2) and 3).

I think we need a mix of both 2) and 3). Because we need to support
several 'binding context'.

For example, with this User object:

public class User extends Model {

     public String name;

     @Bind(excludeFor="profile")
     public boolean isAdmin;

}

Using the @Bind annotation I say that this field must not been binded
for the 'profile' binding context.

And then in the controller:

public static void editMyProfile(@As("profile") User user) {
    ...
}

On 2 nov. 2009, at 21:17, Nicolas <email address hidden> wrote:

> I see 3 options for that issue:
>
> 1) Provide an helper class that delegates to the jakarta common
> beanutils
> 2) Add a new annotation: @NoBinding
> 3) As I happen to work on the @As annotation that is a binding
> annotation, add a new attribute for it that exclude a propery: @As
> (exclude="myAttribute")
>
> I am still debating between option 2) and 3).
>
> ** Changed in: play
> Assignee: (unassigned) => Nicolas (nicolas-lunatech)
>
> --
> Feature request: Secure params biding
> https://bugs.launchpad.net/bugs/467207
> You received this bug notification because you are a member of play
> framework developers, which is subscribed to play framework.

Hmm, that is a good idea! We can even extend the idea to have different type of binding depending on your profile.

So I should be able to do:

public class User extends Model {

     public String name;

     @Bind(profile = "us", format = "yyyy-dd-MM")
     @Bind(profile = "fr", format = "yyyy-MM-dd")
     public Date date;

}

and then in the controller:

public static void editMyProfile(@As("${Lang}") User user) {
    ...
}

So @Bind(profile="") could support a comma separated list as well. If not specified it would apply to all profiles.
The @Bind could also be set on the class level and support a @Bind(binder=MyBinder.class). That would be useful for custom binder. Same idea of profile applies there.

If we follow this, then I think that the @Bind(exclude = "bla") should probably be @Unbind(profile).

Ok that's more work but we could do a lot of things with that. In case no @As is defined, the@Bind is ignored ad we fall back to the default date format. I will try to write a more elaborate functional specification (I believe the blueprints are made for that?).

It looks really nice!

Hmm, but the another solution could be to create complete 'form' environment e.g. like a Django has http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#topics-forms-modelforms . Using this approach, we can obtain potentialy deeper solution, that will cover other aspects of the problem. Such Form object could be able to render himself to HTML, can make aditional validation like 'onValidate method' and many other things(e.g. contribution can then extends it to form wizards ...) We can find a huge inspiration in Django for example. If you imagine the model with 20-30 fields, it can be a bit messy to use annotations for diffrerent presentation cases in one model file. Separate Form objects would be much more elegant and we can separate form logic from model.
(from JAVA world I had a very positive experience with Click Framework and their form implementation http://click.sourceforge.net/docs/click-api/net/sf/click/control/Form.html)

But I guess, you guys will have many nice ideas.
David