proposed bind access changes

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

proposed bind access changes

Ben Gunter
OK folks, I have heard your feedback about the bind access controls. I want to see what you think about the following changes:

Do away with @BindAccess(policy=..., allow=..., deny=...)

Add @StrictBinding at the class level, which acts as a marker to indicate that binding rules apply to this class. It can also be given a default policy to follow by doing @StrictBinding(BindAccessPolicy.ALLOW) or @StrictBinding(BindAccessPolicy.DENY). You would no longer specify allow and deny lists at the class level. Nobody seemed too happy with that anyway.

Add @AllowBinding at the field or method level which takes a string array as its value. Any properties specified will be added to the allow list. A nice thing about the annotation syntax is that an array of length 1 doesn't have to have braces around it so you can choose to write it as @AllowBinding("a.*, b.*, c.**") or @AllowBinding({ "a.*", "b.*", "c.**" }). Or combine the two if you like. All elements of the array will be treated as a comma-separated list.

Add @DenyBinding at the field or method level which takes a string array as its value. Any properties specified will be added to the deny list.

Since there seems to be a lot of interest in one day adding this to Stripes core, I want to go ahead and make it behave now as closely as possible to how it will behave when that day comes to minimize the headaches for whoever might be using it already. So for any bean that does not have a @StrictBinding annotation, binding is allowed for all properties -- even if @DenyBinding is present on the bean's fields. A simple @StrictBinding or @StrictBinding(DENY) will turn on access control and deny all properties that are not explicitly allowed by @AllowBinding. A @StrictBinding(ALLOW) will turn on access control and allow all properties that are not explicitly denied by @DenyBinding.

A new interface will be added called BindAccessEvaluator that defines a method boolean isBindingAllowed(String parameterName). Any ActionBean that implements that interface can provide whatever special logic is required to determine if binding is allowed for each parameter. As a convenience, some way to match parameter names against globs will be provided. E.g.:
public boolean isBindingAllowed(String parameterName) {
    BeanPropertyGlob glob = new BeanPropertyGlob("person.account**");
    if (!context.getUser().satisfiesRole("Administrator") && glob.matches(parameterName))
       return false;
    return true;
}

There is one thing I haven't come to a conclusion on yet, and I need your help with that. Since @AllowBinding and @DenyBinding are now specified on the property's field or getter or setter method, there needs to be some way in the property spec to refer to the annotated property itself. For example, this
@AllowBinding("**")
@DenyBinding("account**")
private Person person;

says any property of person  except account and all its sub-properties can be bound. But how does one specify that the person property itself can be bound? I could follow OGNL and use "#this". (I can't just use "this" because getThis() and setThis() are valid method names.) But I wanted to ask if anybody out there has a better idea.

So those are my ideas. Please let me know what you like and/or dislike about them.

-Ben

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Tim Fennell-3
Hey Ben,

This sounds great.  One word of caution is that for the  
@StrictBinding I'd go for @StrictBinding(policy=ALLOW) as opposed to  
using value().  I've been caught out before now (before/after methods  
being a recent example) where I thought an annotation would only ever  
have one attribute, but then later wanted to add more.  If you use  
value() it's impossible to add more attrs later without breaking  
current usage :(

-t

On Oct 24, 2006, at 9:48 AM, Ben Gunter wrote:

> OK folks, I have heard your feedback about the bind access  
> controls. I want to see what you think about the following changes:
>
> Do away with @BindAccess(policy=..., allow=..., deny=...)
>
> Add @StrictBinding at the class level, which acts as a marker to  
> indicate that binding rules apply to this class. It can also be  
> given a default policy to follow by doing @StrictBinding
> (BindAccessPolicy.ALLOW) or @StrictBinding(BindAccessPolicy.DENY).  
> You would no longer specify allow and deny lists at the class  
> level. Nobody seemed too happy with that anyway.
>
> Add @AllowBinding at the field or method level which takes a string  
> array as its value. Any properties specified will be added to the  
> allow list. A nice thing about the annotation syntax is that an  
> array of length 1 doesn't have to have braces around it so you can  
> choose to write it as @AllowBinding("a.*, b.*, c.**") or  
> @AllowBinding({ "a.*", "b.*", "c.**" }). Or combine the two if you  
> like. All elements of the array will be treated as a comma-
> separated list.
>
> Add @DenyBinding at the field or method level which takes a string  
> array as its value. Any properties specified will be added to the  
> deny list.
>
> Since there seems to be a lot of interest in one day adding this to  
> Stripes core, I want to go ahead and make it behave now as closely  
> as possible to how it will behave when that day comes to minimize  
> the headaches for whoever might be using it already. So for any  
> bean that does not have a @StrictBinding annotation, binding is  
> allowed for all properties -- even if @DenyBinding is present on  
> the bean's fields. A simple @StrictBinding or @StrictBinding(DENY)  
> will turn on access control and deny all properties that are not  
> explicitly allowed by @AllowBinding. A @StrictBinding(ALLOW) will  
> turn on access control and allow all properties that are not  
> explicitly denied by @DenyBinding.
>
> A new interface will be added called BindAccessEvaluator that  
> defines a method boolean isBindingAllowed(String parameterName).  
> Any ActionBean that implements that interface can provide whatever  
> special logic is required to determine if binding is allowed for  
> each parameter. As a convenience, some way to match parameter names  
> against globs will be provided. E.g.:
> public boolean isBindingAllowed(String parameterName) {
>     BeanPropertyGlob glob = new BeanPropertyGlob("person.account**");
>     if (!context.getUser().satisfiesRole("Administrator") &&  
> glob.matches(parameterName))
>        return false;
>     return true;
> }
> There is one thing I haven't come to a conclusion on yet, and I  
> need your help with that. Since @AllowBinding and @DenyBinding are  
> now specified on the property's field or getter or setter method,  
> there needs to be some way in the property spec to refer to the  
> annotated property itself. For example, this
> @AllowBinding("**")
> @DenyBinding("account**")
> private Person person;
> says any property of person  except account and all its sub-
> properties can be bound. But how does one specify that the person  
> property itself can be bound? I could follow OGNL and use "#this".  
> (I can't just use "this" because getThis() and setThis() are valid  
> method names.) But I wanted to ask if anybody out there has a  
> better idea.
>
> So those are my ideas. Please let me know what you like and/or  
> dislike about them.
>
> -Ben
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
> _________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Ben Gunter
But they're just so much prettier without the element name! :)

I definitely thought about that, and you're right that it's the safer approach. I guess most of the time you won't even specify a policy anyway. That makes me wonder about @AllowBinding and @DenyBinding, though. They use value() too. Was there a reason you didn't suggest the same treatment for those two?

Tim Fennell wrote:
Hey Ben,

This sounds great.  One word of caution is that for the  
@StrictBinding I'd go for @StrictBinding(policy=ALLOW) as opposed to  
using value().  I've been caught out before now (before/after methods  
being a recent example) where I thought an annotation would only ever  
have one attribute, but then later wanted to add more.  If you use  
value() it's impossible to add more attrs later without breaking  
current usage :(

-t

On Oct 24, 2006, at 9:48 AM, Ben Gunter wrote:

  
OK folks, I have heard your feedback about the bind access  
controls. I want to see what you think about the following changes:

Do away with @BindAccess(policy=..., allow=..., deny=...)

Add @StrictBinding at the class level, which acts as a marker to  
indicate that binding rules apply to this class. It can also be  
given a default policy to follow by doing @StrictBinding 
(BindAccessPolicy.ALLOW) or @StrictBinding(BindAccessPolicy.DENY).  
You would no longer specify allow and deny lists at the class  
level. Nobody seemed too happy with that anyway.

Add @AllowBinding at the field or method level which takes a string  
array as its value. Any properties specified will be added to the  
allow list. A nice thing about the annotation syntax is that an  
array of length 1 doesn't have to have braces around it so you can  
choose to write it as @AllowBinding("a.*, b.*, c.**") or  
@AllowBinding({ "a.*", "b.*", "c.**" }). Or combine the two if you  
like. All elements of the array will be treated as a comma- 
separated list.

Add @DenyBinding at the field or method level which takes a string  
array as its value. Any properties specified will be added to the  
deny list.

Since there seems to be a lot of interest in one day adding this to  
Stripes core, I want to go ahead and make it behave now as closely  
as possible to how it will behave when that day comes to minimize  
the headaches for whoever might be using it already. So for any  
bean that does not have a @StrictBinding annotation, binding is  
allowed for all properties -- even if @DenyBinding is present on  
the bean's fields. A simple @StrictBinding or @StrictBinding(DENY)  
will turn on access control and deny all properties that are not  
explicitly allowed by @AllowBinding. A @StrictBinding(ALLOW) will  
turn on access control and allow all properties that are not  
explicitly denied by @DenyBinding.

A new interface will be added called BindAccessEvaluator that  
defines a method boolean isBindingAllowed(String parameterName).  
Any ActionBean that implements that interface can provide whatever  
special logic is required to determine if binding is allowed for  
each parameter. As a convenience, some way to match parameter names  
against globs will be provided. E.g.:
public boolean isBindingAllowed(String parameterName) {
    BeanPropertyGlob glob = new BeanPropertyGlob("person.account**");
    if (!context.getUser().satisfiesRole("Administrator") &&  
glob.matches(parameterName))
       return false;
    return true;
}
There is one thing I haven't come to a conclusion on yet, and I  
need your help with that. Since @AllowBinding and @DenyBinding are  
now specified on the property's field or getter or setter method,  
there needs to be some way in the property spec to refer to the  
annotated property itself. For example, this
@AllowBinding("**")
@DenyBinding("account**")
private Person person;
says any property of person  except account and all its sub- 
properties can be bound. But how does one specify that the person  
property itself can be bound? I could follow OGNL and use "#this".  
(I can't just use "this" because getThis() and setThis() are valid  
method names.) But I wanted to ask if anybody out there has a  
better idea.

So those are my ideas. Please let me know what you like and/or  
dislike about them.

-Ben
---------------------------------------------------------------------- 
---
Using Tomcat but need to do more? Need to support web services,  
security?
Get stuff done quickly with pre-integrated technology to make your  
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache  
Geronimo
http://sel.as-us.falkag.net/sel? 
cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
_________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
    


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Tim Fennell-3
But they're just so much prettier without the element name! :)
I know...it's syntax sure i almost wish didn't exist in this case.

I definitely thought about that, and you're right that it's the safer approach. I guess most of the time you won't even specify a policy anyway. That makes me wonder about @AllowBinding and @DenyBinding, though. They use value() too. Was there a reason you didn't suggest the same treatment for those two?
Umm, because I didn't think that far ahead ;)

-t



Tim Fennell wrote:
Hey Ben,

This sounds great.  One word of caution is that for the  
@StrictBinding I'd go for @StrictBinding(policy=ALLOW) as opposed to  
using value().  I've been caught out before now (before/after methods  
being a recent example) where I thought an annotation would only ever  
have one attribute, but then later wanted to add more.  If you use  
value() it's impossible to add more attrs later without breaking  
current usage :(

-t

On Oct 24, 2006, at 9:48 AM, Ben Gunter wrote:

  
OK folks, I have heard your feedback about the bind access  
controls. I want to see what you think about the following changes:

Do away with @BindAccess(policy=..., allow=..., deny=...)

Add @StrictBinding at the class level, which acts as a marker to  
indicate that binding rules apply to this class. It can also be  
given a default policy to follow by doing @StrictBinding 
(BindAccessPolicy.ALLOW) or @StrictBinding(BindAccessPolicy.DENY).  
You would no longer specify allow and deny lists at the class  
level. Nobody seemed too happy with that anyway.

Add @AllowBinding at the field or method level which takes a string  
array as its value. Any properties specified will be added to the  
allow list. A nice thing about the annotation syntax is that an  
array of length 1 doesn't have to have braces around it so you can  
choose to write it as @AllowBinding("a.*, b.*, c.**") or  
@AllowBinding({ "a.*", "b.*", "c.**" }). Or combine the two if you  
like. All elements of the array will be treated as a comma- 
separated list.

Add @DenyBinding at the field or method level which takes a string  
array as its value. Any properties specified will be added to the  
deny list.

Since there seems to be a lot of interest in one day adding this to  
Stripes core, I want to go ahead and make it behave now as closely  
as possible to how it will behave when that day comes to minimize  
the headaches for whoever might be using it already. So for any  
bean that does not have a @StrictBinding annotation, binding is  
allowed for all properties -- even if @DenyBinding is present on  
the bean's fields. A simple @StrictBinding or @StrictBinding(DENY)  
will turn on access control and deny all properties that are not  
explicitly allowed by @AllowBinding. A @StrictBinding(ALLOW) will  
turn on access control and allow all properties that are not  
explicitly denied by @DenyBinding.

A new interface will be added called BindAccessEvaluator that  
defines a method boolean isBindingAllowed(String parameterName).  
Any ActionBean that implements that interface can provide whatever  
special logic is required to determine if binding is allowed for  
each parameter. As a convenience, some way to match parameter names  
against globs will be provided. E.g.:
public boolean isBindingAllowed(String parameterName) {
    BeanPropertyGlob glob = new BeanPropertyGlob("person.account**");
    if (!context.getUser().satisfiesRole("Administrator") &&  
glob.matches(parameterName))
       return false;
    return true;
}
There is one thing I haven't come to a conclusion on yet, and I  
need your help with that. Since @AllowBinding and @DenyBinding are  
now specified on the property's field or getter or setter method,  
there needs to be some way in the property spec to refer to the  
annotated property itself. For example, this
@AllowBinding("**")
@DenyBinding("account**")
private Person person;
says any property of person  except account and all its sub- 
properties can be bound. But how does one specify that the person  
property itself can be bound? I could follow OGNL and use "#this".  
(I can't just use "this" because getThis() and setThis() are valid  
method names.) But I wanted to ask if anybody out there has a  
better idea.

So those are my ideas. Please let me know what you like and/or  
dislike about them.

-Ben
---------------------------------------------------------------------- 
---
Using Tomcat but need to do more? Need to support web services,  
security?
Get stuff done quickly with pre-integrated technology to make your  
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache  
Geronimo
http://sel.as-us.falkag.net/sel? 
cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
_________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
    
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Stripes-users mailing list


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

paul.barry
In reply to this post by Ben Gunter
I don't there is too much difference between these two:

1.  @StrictBinding(BindAccessPolicy.ALLOW)
2.  @StrictBinding(policy=BindAccessPolicy.ALLOW)

1.  @AllowBinding("**")
2.  @AllowBinding(property="**")

I think the explictness of #2 combined with the fact that you aren't
limiting yourself seems like the way to go.






On 10/24/06, Ben Gunter <[hidden email]> wrote:

> But they're just so much prettier without the element name! :)
>
> I definitely thought about that, and you're right that it's the safer
> approach. I guess most of the time you won't even specify a policy anyway.
> That makes me wonder about @AllowBinding and @DenyBinding, though. They use
> value() too. Was there a reason you didn't suggest the same treatment for
> those two?
>
>
> Tim Fennell wrote:
> Hey Ben,

This sounds great. One word of caution is that for the
>
@StrictBinding I'd go for @StrictBinding(policy=ALLOW) as opposed to
using
> value(). I've been caught out before now (before/after methods
being a
> recent example) where I thought an annotation would only ever
have one
> attribute, but then later wanted to add more. If you use
value() it's
> impossible to add more attrs later without breaking
current usage
> :(

-t

On Oct 24, 2006, at 9:48 AM, Ben Gunter wrote:


> OK folks, I have heard your feedback about the bind access
controls. I want
> to see what you think about the following changes:

Do away with
> @BindAccess(policy=..., allow=..., deny=...)

Add @StrictBinding at the
> class level, which acts as a marker to
indicate that binding rules apply to
> this class. It can also be
given a default policy to follow by doing
> @StrictBinding
(BindAccessPolicy.ALLOW) or
> @StrictBinding(BindAccessPolicy.DENY).
You would no longer specify allow
> and deny lists at the class
level. Nobody seemed too happy with that
> anyway.

Add @AllowBinding at the field or method level which takes a string
>
array as its value. Any properties specified will be added to the
allow
> list. A nice thing about the annotation syntax is that an
array of length 1
> doesn't have to have braces around it so you can
choose to write it as
> @AllowBinding("a.*, b.*, c.**") or
@AllowBinding({ "a.*", "b.*", "c.**" }).
> Or combine the two if you
like. All elements of the array will be treated
> as a comma-
separated list.

Add @DenyBinding at the field or method level
> which takes a string
array as its value. Any properties specified will be
> added to the
deny list.

Since there seems to be a lot of interest in one
> day adding this to
Stripes core, I want to go ahead and make it behave now
> as closely
as possible to how it will behave when that day comes to
> minimize
the headaches for whoever might be using it already. So for any
>
bean that does not have a @StrictBinding annotation, binding is
allowed
> for all properties -- even if @DenyBinding is present on
the bean's fields.
> A simple @StrictBinding or @StrictBinding(DENY)
will turn on access control
> and deny all properties that are not
explicitly allowed by @AllowBinding. A
> @StrictBinding(ALLOW) will
turn on access control and allow all properties
> that are not
explicitly denied by @DenyBinding.

A new interface will be
> added called BindAccessEvaluator that
defines a method boolean
> isBindingAllowed(String parameterName).
Any ActionBean that implements that
> interface can provide whatever
special logic is required to determine if
> binding is allowed for
each parameter. As a convenience, some way to match
> parameter names
against globs will be provided. E.g.:
public boolean
> isBindingAllowed(String parameterName) {
 BeanPropertyGlob glob = new
> BeanPropertyGlob("person.account**");
 if
> (!context.getUser().satisfiesRole("Administrator") &&
>
glob.matches(parameterName))
 return false;
 return true;
}
There is one
> thing I haven't come to a conclusion on yet, and I
need your help with
> that. Since @AllowBinding and @DenyBinding are
now specified on the
> property's field or getter or setter method,
there needs to be some way in
> the property spec to refer to the
annotated property itself. For example,
> this
@AllowBinding("**")
@DenyBinding("account**")
private Person
> person;
says any property of person except account and all its sub-
>
properties can be bound. But how does one specify that the person
property
> itself can be bound? I could follow OGNL and use "#this".
(I can't just use
> "this" because getThis() and setThis() are valid
method names.) But I
> wanted to ask if anybody out there has a
better idea.

So those are my
> ideas. Please let me know what you like and/or
dislike about
> them.

-Ben
----------------------------------------------------------------------
>
---
Using Tomcat but need to do more? Need to support web services,
>
security?
Get stuff done quickly with pre-integrated technology to make
> your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on
> Apache
Geronimo
http://sel.as-us.falkag.net/sel?
>
cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
>
_________________
Stripes-users mailing
> list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
>
-------------------------------------------------------------------------
Using
> Tomcat but need to do more? Need to support web services, security?
Get
> stuff done quickly with pre-integrated technology to make your job
> easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users
> mailing
> list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users

>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Gary Moselen
In reply to this post by Ben Gunter
>  There is one thing I haven't come to a conclusion on yet, and I need
> your help with that. Since @AllowBinding and @DenyBinding are now
> specified on the property's field or getter or setter method, there
> needs to be some way in the property spec to refer to the annotated
> property itself. For example, this
>
>     @AllowBinding("**")
>     @DenyBinding("account**")
>     private Person person;
>
> says any property of person except account and all its sub-properties
> can be bound. But how does one specify that the person property itself
> can be bound? I could follow OGNL and use "#this". (I can't just use
> "this" because getThis() and setThis() are valid method names.) But I
> wanted to ask if anybody out there has a better idea.


Well the only time you ever want to bind to "this" is when there is a
TypeConverter for it and in that case you don't usually bind to nested
properties; *except* when you are using Stripernate which uses this as a
trick to hydrate the entity before the rest of the binding.

My opinion was that the Stripernate trick is a not very natural use of
TypeConverters, but it's necessary because Stripes doesn't have a notion
of object hydration. In what other cases would binding to "this" be used
and there also be nested properties?

I made a post about this a few days ago but nobody commented it :(

Gary


Ben Gunter wrote:

> OK folks, I have heard your feedback about the bind access controls. I
> want to see what you think about the following changes:
>
> Do away with @BindAccess(policy=..., allow=..., deny=...)
>
> Add @StrictBinding at the class level, which acts as a marker to
> indicate that binding rules apply to this class. It can also be given
> a default policy to follow by doing
> @StrictBinding(BindAccessPolicy.ALLOW) or
> @StrictBinding(BindAccessPolicy.DENY). You would no longer specify
> allow and deny lists at the class level. Nobody seemed too happy with
> that anyway.
>
> Add @AllowBinding at the field or method level which takes a string
> array as its value. Any properties specified will be added to the
> allow list. A nice thing about the annotation syntax is that an array
> of length 1 doesn't have to have braces around it so you can choose to
> write it as @AllowBinding("a.*, b.*, c.**") or @AllowBinding({ "a.*",
> "b.*", "c.**" }. Or combine the two if you like. All elements of the
> array will be treated as a comma-separated list.
>
> Add @DenyBinding at the field or method level which takes a string
> array as its value. Any properties specified will be added to the deny
> list.
>
> Since there seems to be a lot of interest in one day adding this to
> Stripes core, I want to go ahead and make it behave now as closely as
> possible to how it will behave when that day comes to minimize the
> headaches for whoever might be using it already. So for any bean that
> does not have a @StrictBinding annotation, binding is allowed for all
> properties -- even if @DenyBinding is present on the bean's fields. A
> simple @StrictBinding or @StrictBinding(DENY) will turn on access
> control and deny all properties that are not explicitly allowed by
> @AllowBinding. A @StrictBinding(ALLOW) will turn on access control and
> allow all properties that are not explicitly denied by @DenyBinding.
>
> A new interface will be added called BindAccessEvaluator that defines
> a method boolean isBindingAllowed(String parameterName) . Any
> ActionBean that implements that interface can provide whatever special
> logic is required to determine if binding is allowed for each
> parameter. As a convenience, some way to match parameter names against
> globs will be provided. E.g.:
>
>     public boolean isBindingAllowed(String parameterName) {
>        BeanPropertyGlob glob = new BeanPropertyGlob("person.account**");
>        if (!context.getUser().satisfiesRole("Administrator") & &
>     glob.matches(parameterName))
>          return false;
>        return true;
>     }
>
> There is one thing I haven't come to a conclusion on yet, and I need
> your help with that. Since @AllowBinding and @DenyBinding are now
> specified on the property's field or getter or setter method, there
> needs to be some way in the property spec to refer to the annotated
> property itself. For example, this
>
>     @AllowBinding("**")
>     @DenyBinding("account**")
>     private Person person;
>
> says any property of person except account and all its sub-properties
> can be bound. But how does one specify that the person property itself
> can be bound? I could follow OGNL and use "#this". (I can't just use
> "this" because getThis() and setThis() are valid method names.) But I
> wanted to ask if anybody out there has a better idea.
>
> So those are my ideas. Please let me know what you like and/or dislike
> about them.
>
> -Ben
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Stripes-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/stripes-users
>  
>



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Ben Gunter
No matter the data type of the bean property, you always need to allow binding to #this if you want the property bound.

    @AllowBinding(property="#this")
    private String something;


So the short answer is that *every* allowed property needs to be referenced as #this. I hadn't thought of it until you brought up this question, but I suppose the default value of "property" should be "#this" (or whatever) so that one can do this instead:

    @AllowBinding
    private String something;


Another approach would be to add a boolean element to @AllowBinding and @DenyBinding that indicates if binding to the annotated property itself is allowed. The default would be true in both cases.

    @AllowBinding(allowThis=false, property="*")
    @DenyBinding(denyThis=false, property="*")


That would simplify the expressions (and the code to parse them), but I don't know if it's the right approach.

And finally, contrary to my original message on this subject, I now think @AllowBinding and @DenyBinding should be applicable to a class declaration so you can do this:

    @StrictBinding
    @AllowBinding(property="person**")
    public class MyBean extends BaseActionBean {
       private Person person;
       // ...
    }


Instead of having to tag each property individually. Feedback is welcome.

-Ben

Gary Moselen wrote:
 There is one thing I haven't come to a conclusion on yet, and I need 
your help with that. Since @AllowBinding and @DenyBinding are now 
specified on the property's field or getter or setter method, there 
needs to be some way in the property spec to refer to the annotated 
property itself. For example, this

    @AllowBinding("**")
    @DenyBinding("account**")
    private Person person;

says any property of person except account and all its sub-properties 
can be bound. But how does one specify that the person property itself 
can be bound? I could follow OGNL and use "#this". (I can't just use 
"this" because getThis() and setThis() are valid method names.) But I 
wanted to ask if anybody out there has a better idea.
    


Well the only time you ever want to bind to "this" is when there is a 
TypeConverter for it and in that case you don't usually bind to nested 
properties; *except* when you are using Stripernate which uses this as a 
trick to hydrate the entity before the rest of the binding.

My opinion was that the Stripernate trick is a not very natural use of 
TypeConverters, but it's necessary because Stripes doesn't have a notion 
of object hydration. In what other cases would binding to "this" be used 
and there also be nested properties?

I made a post about this a few days ago but nobody commented it :(

Gary


Ben Gunter wrote:

  
OK folks, I have heard your feedback about the bind access controls. I 
want to see what you think about the following changes:

Do away with @BindAccess(policy=..., allow=..., deny=...)

Add @StrictBinding at the class level, which acts as a marker to 
indicate that binding rules apply to this class. It can also be given 
a default policy to follow by doing 
@StrictBinding(BindAccessPolicy.ALLOW) or 
@StrictBinding(BindAccessPolicy.DENY). You would no longer specify 
allow and deny lists at the class level. Nobody seemed too happy with 
that anyway.

Add @AllowBinding at the field or method level which takes a string 
array as its value. Any properties specified will be added to the 
allow list. A nice thing about the annotation syntax is that an array 
of length 1 doesn't have to have braces around it so you can choose to 
write it as @AllowBinding("a.*, b.*, c.**") or @AllowBinding({ "a.*", 
"b.*", "c.**" }. Or combine the two if you like. All elements of the 
array will be treated as a comma-separated list.

Add @DenyBinding at the field or method level which takes a string 
array as its value. Any properties specified will be added to the deny 
list.

Since there seems to be a lot of interest in one day adding this to 
Stripes core, I want to go ahead and make it behave now as closely as 
possible to how it will behave when that day comes to minimize the 
headaches for whoever might be using it already. So for any bean that 
does not have a @StrictBinding annotation, binding is allowed for all 
properties -- even if @DenyBinding is present on the bean's fields. A 
simple @StrictBinding or @StrictBinding(DENY) will turn on access 
control and deny all properties that are not explicitly allowed by 
@AllowBinding. A @StrictBinding(ALLOW) will turn on access control and 
allow all properties that are not explicitly denied by @DenyBinding.

A new interface will be added called BindAccessEvaluator that defines 
a method boolean isBindingAllowed(String parameterName) . Any 
ActionBean that implements that interface can provide whatever special 
logic is required to determine if binding is allowed for each 
parameter. As a convenience, some way to match parameter names against 
globs will be provided. E.g.:

    public boolean isBindingAllowed(String parameterName) {
       BeanPropertyGlob glob = new BeanPropertyGlob("person.account**");
       if (!context.getUser().satisfiesRole("Administrator") & &
    glob.matches(parameterName))
         return false;
       return true;
    }

There is one thing I haven't come to a conclusion on yet, and I need 
your help with that. Since @AllowBinding and @DenyBinding are now 
specified on the property's field or getter or setter method, there 
needs to be some way in the property spec to refer to the annotated 
property itself. For example, this

    @AllowBinding("**")
    @DenyBinding("account**")
    private Person person;

says any property of person except account and all its sub-properties 
can be bound. But how does one specify that the person property itself 
can be bound? I could follow OGNL and use "#this". (I can't just use 
"this" because getThis() and setThis() are valid method names.) But I 
wanted to ask if anybody out there has a better idea.

So those are my ideas. Please let me know what you like and/or dislike 
about them.

-Ben

------------------------------------------------------------------------

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
 

    



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Gary Moselen
The examples where the default is '#this' would be for types like
String, Date, DateTime, Quantity/Measure which are all immutable types
and don't have nested properties. And when you have a mutable bean class
then 99% of the time it makes no sense to bind to the bean itself, right?

Which means that I think it should default to the property itself by
default and allow no nested properties, and you would use that for
immutable types.

@AllowBinding
private String foo;

In the other case binding to '#this' doesn't normally make sense, I
would probably say forget about binding to 'this' altogether as soon as
they provide a pattern.

@AllowBinding("**")
private Person person;

OR you could follow the same form as Stripes @AllowBindingNestedProperties

Gary

Ben Gunter wrote:

> No matter the data type of the bean property, you always need to allow
> binding to #this if you want the property bound.
>
>     @AllowBinding(property="#this")
>     private String something;
>
> So the short answer is that *every* allowed property needs to be
> referenced as #this. I hadn't thought of it until you brought up this
> question, but I suppose the default value of "property" should be
> "#this" (or whatever) so that one can do this instead:
>
>     @AllowBinding
>     private String something;
>
> Another approach would be to add a boolean element to @AllowBinding
> and @DenyBinding that indicates if binding to the annotated property
> itself is allowed. The default would be true in both cases.
>
>     @AllowBinding(allowThis=false, property="*")
>     @DenyBinding(denyThis=false, property="*")
>
> That would simplify the expressions (and the code to parse them), but
> I don't know if it's the right approach.
>
> And finally, contrary to my original message on this subject, I now
> think @AllowBinding and @DenyBinding should be applicable to a class
> declaration so you can do this:
>
>     @StrictBinding
>     @AllowBinding(property="person**")
>     public class MyBean extends BaseActionBean {
>        private Person person;
>        // ...
>     }
>
> Instead of having to tag each property individually. Feedback is welcome.
>
> -Ben
>
> Gary Moselen wrote:
>
>>> There is one thing I haven't come to a conclusion on yet, and I need
>>>your help with that. Since @AllowBinding and @DenyBinding are now
>>>specified on the property's field or getter or setter method, there
>>>needs to be some way in the property spec to refer to the annotated
>>>property itself. For example, this
>>>
>>>    @AllowBinding("**")
>>>    @DenyBinding("account**")
>>>    private Person person;
>>>
>>>says any property of person except account and all its sub-properties
>>>can be bound. But how does one specify that the person property itself
>>>can be bound? I could follow OGNL and use "#this". (I can't just use
>>>"this" because getThis() and setThis() are valid method names.) But I
>>>wanted to ask if anybody out there has a better idea.
>>>    
>>>
>>
>>
>>Well the only time you ever want to bind to "this" is when there is a
>>TypeConverter for it and in that case you don't usually bind to nested
>>properties; *except* when you are using Stripernate which uses this as a
>>trick to hydrate the entity before the rest of the binding.
>>
>>My opinion was that the Stripernate trick is a not very natural use of
>>TypeConverters, but it's necessary because Stripes doesn't have a notion
>>of object hydration. In what other cases would binding to "this" be used
>>and there also be nested properties?
>>
>>I made a post about this a few days ago but nobody commented it :(
>>
>>Gary
>>    
>>



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Ben Gunter
It seems to me that Stripernate has a few fans on this list, and Stripernate does use type converters to bind directly into mutable bean classes. And personally I think it's a pretty clever use of type converters. At the very least, if it's a feature that Stripes supports then I need to support it in my code as well.

As for @AllowBindingNestedProperties, I allow the use of globs in the property names specifically to avoid the complexities that introduces. The access controls will honor @ValidateNestedProperties and @Validate annotations the same as an @AllowBinding. If you prefer this kind of behavior, all you have to do is make sure all your allowed properties have a @Validate associated with them (even if it's empty).

-Ben

Gary Moselen wrote:
The examples where the default is '#this' would be for types like 
String, Date, DateTime, Quantity/Measure which are all immutable types 
and don't have nested properties. And when you have a mutable bean class 
then 99% of the time it makes no sense to bind to the bean itself, right?

Which means that I think it should default to the property itself by 
default and allow no nested properties, and you would use that for 
immutable types.

@AllowBinding
private String foo;

In the other case binding to '#this' doesn't normally make sense, I 
would probably say forget about binding to 'this' altogether as soon as 
they provide a pattern.

@AllowBinding("**")
private Person person;

OR you could follow the same form as Stripes @AllowBindingNestedProperties

Gary

Ben Gunter wrote:

  
No matter the data type of the bean property, you always need to allow 
binding to #this if you want the property bound.

    @AllowBinding(property="#this")
    private String something;

So the short answer is that *every* allowed property needs to be 
referenced as #this. I hadn't thought of it until you brought up this 
question, but I suppose the default value of "property" should be 
"#this" (or whatever) so that one can do this instead:

    @AllowBinding
    private String something;

Another approach would be to add a boolean element to @AllowBinding 
and @DenyBinding that indicates if binding to the annotated property 
itself is allowed. The default would be true in both cases.

    @AllowBinding(allowThis=false, property="*")
    @DenyBinding(denyThis=false, property="*")

That would simplify the expressions (and the code to parse them), but 
I don't know if it's the right approach.

And finally, contrary to my original message on this subject, I now 
think @AllowBinding and @DenyBinding should be applicable to a class 
declaration so you can do this:

    @StrictBinding
    @AllowBinding(property="person**")
    public class MyBean extends BaseActionBean {
       private Person person;
       // ...
    }

Instead of having to tag each property individually. Feedback is welcome.

-Ben

Gary Moselen wrote:

    
There is one thing I haven't come to a conclusion on yet, and I need 
your help with that. Since @AllowBinding and @DenyBinding are now 
specified on the property's field or getter or setter method, there 
needs to be some way in the property spec to refer to the annotated 
property itself. For example, this

   @AllowBinding("**")
   @DenyBinding("account**")
   private Person person;

says any property of person except account and all its sub-properties 
can be bound. But how does one specify that the person property itself 
can be bound? I could follow OGNL and use "#this". (I can't just use 
"this" because getThis() and setThis() are valid method names.) But I 
wanted to ask if anybody out there has a better idea.
   

        
Well the only time you ever want to bind to "this" is when there is a 
TypeConverter for it and in that case you don't usually bind to nested 
properties; *except* when you are using Stripernate which uses this as a 
trick to hydrate the entity before the rest of the binding.

My opinion was that the Stripernate trick is a not very natural use of 
TypeConverters, but it's necessary because Stripes doesn't have a notion 
of object hydration. In what other cases would binding to "this" be used 
and there also be nested properties?

I made a post about this a few days ago but nobody commented it :(

Gary
   

      



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Gary Moselen
 > It seems to me that Stripernate has a few fans on this list, and
Stripernate does use type converters to bind directly into mutable bean
classes. And personally I think it's a pretty clever use of type
converters. At the very least, if it's a feature that Stripes supports
then I need to support it in my code as well.

I think Stripernate is great too and the TypeConverter trick is clever
but also weird. And this was an example of how it's weirdness causes
problems; but I guess noone else is seeing it that way... otherwise your
binding annotations look good.

Gary

Ben Gunter wrote:

> It seems to me that Stripernate has a few fans on this list, and
> Stripernate does use type converters to bind directly into mutable
> bean classes. And personally I think it's a pretty clever use of type
> converters. At the very least, if it's a feature that Stripes supports
> then I need to support it in my code as well.
>
> As for @AllowBindingNestedProperties, I allow the use of globs in the
> property names specifically to avoid the complexities that introduces.
> The access controls will honor @ValidateNestedProperties and @Validate
> annotations the same as an @AllowBinding. If you prefer this kind of
> behavior, all you have to do is make sure all your allowed properties
> have a @Validate associated with them (even if it's empty).
>
> -Ben
>
> Gary Moselen wrote:
>
>>The examples where the default is '#this' would be for types like
>>String, Date, DateTime, Quantity/Measure which are all immutable types
>>and don't have nested properties. And when you have a mutable bean class
>>then 99% of the time it makes no sense to bind to the bean itself, right?
>>
>>Which means that I think it should default to the property itself by
>>default and allow no nested properties, and you would use that for
>>immutable types.
>>
>>@AllowBinding
>>private String foo;
>>
>>In the other case binding to '#this' doesn't normally make sense, I
>>would probably say forget about binding to 'this' altogether as soon as
>>they provide a pattern.
>>
>>@AllowBinding("**")
>>private Person person;
>>
>>OR you could follow the same form as Stripes @AllowBindingNestedProperties
>>
>>Gary
>>
>>Ben Gunter wrote:
>>
>>  
>>
>>>No matter the data type of the bean property, you always need to allow
>>>binding to #this if you want the property bound.
>>>
>>>    @AllowBinding(property="#this")
>>>    private String something;
>>>
>>>So the short answer is that *every* allowed property needs to be
>>>referenced as #this. I hadn't thought of it until you brought up this
>>>question, but I suppose the default value of "property" should be
>>>"#this" (or whatever) so that one can do this instead:
>>>
>>>    @AllowBinding
>>>    private String something;
>>>
>>>Another approach would be to add a boolean element to @AllowBinding
>>>and @DenyBinding that indicates if binding to the annotated property
>>>itself is allowed. The default would be true in both cases.
>>>
>>>    @AllowBinding(allowThis=false, property="*")
>>>    @DenyBinding(denyThis=false, property="*")
>>>
>>>That would simplify the expressions (and the code to parse them), but
>>>I don't know if it's the right approach.
>>>
>>>And finally, contrary to my original message on this subject, I now
>>>think @AllowBinding and @DenyBinding should be applicable to a class
>>>declaration so you can do this:
>>>
>>>    @StrictBinding
>>>    @AllowBinding(property="person**")
>>>    public class MyBean extends BaseActionBean {
>>>       private Person person;
>>>       // ...
>>>    }
>>>
>>>Instead of having to tag each property individually. Feedback is welcome.
>>>
>>>-Ben
>>>
>>>Gary Moselen wrote:
>>>
>>>    
>>>
>>>>>There is one thing I haven't come to a conclusion on yet, and I need
>>>>>your help with that. Since @AllowBinding and @DenyBinding are now
>>>>>specified on the property's field or getter or setter method, there
>>>>>needs to be some way in the property spec to refer to the annotated
>>>>>property itself. For example, this
>>>>>
>>>>>   @AllowBinding("**")
>>>>>   @DenyBinding("account**")
>>>>>   private Person person;
>>>>>
>>>>>says any property of person except account and all its sub-properties
>>>>>can be bound. But how does one specify that the person property itself
>>>>>can be bound? I could follow OGNL and use "#this". (I can't just use
>>>>>"this" because getThis() and setThis() are valid method names.) But I
>>>>>wanted to ask if anybody out there has a better idea.
>>>>>  
>>>>>
>>>>>        
>>>>>
>>>>Well the only time you ever want to bind to "this" is when there is a
>>>>TypeConverter for it and in that case you don't usually bind to nested
>>>>properties; *except* when you are using Stripernate which uses this as a
>>>>trick to hydrate the entity before the rest of the binding.
>>>>
>>>>My opinion was that the Stripernate trick is a not very natural use of
>>>>TypeConverters, but it's necessary because Stripes doesn't have a notion
>>>>of object hydration. In what other cases would binding to "this" be used
>>>>and there also be nested properties?
>>>>
>>>>I made a post about this a few days ago but nobody commented it :(
>>>>
>>>>Gary
>>>>  
>>>>
>>>>      
>>>>
>>
>>
>>
>>-------------------------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Stripes-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/stripes-users
>>  
>>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Stripes-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/stripes-users
>  
>



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Tim Fennell-3
It's funny, at first I had a bit of a similar reaction when folks  
starting thinking about type converters for mutable persistent  
objects, but as time went on I've come to think that not only is this  
a neat trick, it's actually conceptually correct too!

There are a set of persistent objects, and these objects for various  
reasons have a specific property or properties marked as their  
identity property.  Therefore, what more natural way to convert a  
simple value into a persistent entity that to look it up using this  
identity property?  You really are converting a String/int/long into  
the full object.

I think this makes a lot more sense now too that Aaron has a  
Formatter installed for hibernate objects that looks up the identity  
property and writes it out.  So you can now write things like:
     <stripes:hidden name="person"/>
without any knowledge of the structure of person, or it's identity  
property. Therefore the full loop is constructed where a Person can  
be externalized to a simple string, and converted back to a person  
again.

Maybe I'm just rationalizing, but this seems like quite a natural use  
of formatters/converters to me now.

-t

On Oct 24, 2006, at 11:25 PM, Gary Moselen wrote:

>> It seems to me that Stripernate has a few fans on this list, and
>> Stripernate does use type converters to bind directly into mutable  
>> bean
>> classes. And personally I think it's a pretty clever use of type
>> converters. At the very least, if it's a feature that Stripes  
>> supports
>> then I need to support it in my code as well.
>
> I think Stripernate is great too and the TypeConverter trick is clever
> but also weird. And this was an example of how it's weirdness causes
> problems; but I guess noone else is seeing it that way... otherwise  
> your
> binding annotations look good.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Gary Moselen
In reply to this post by Ben Gunter
One more idea for 'this' notation, a '.' prefix means 'this', it
defaults to '.'

@AllowBinding
private String foo;

equivalent to
@AllowBinding(property=".")
private String foo;

then for nested properties

@AllowBinding(property=".*")

means this and nested properties, while

@AllowBinding(property="*")

just means nested properties.

Seems like a nice shorthand.

Gary


Ben Gunter wrote:

> It seems to me that Stripernate has a few fans on this list, and
> Stripernate does use type converters to bind directly into mutable
> bean classes. And personally I think it's a pretty clever use of type
> converters. At the very least, if it's a feature that Stripes supports
> then I need to support it in my code as well.
>
> As for @AllowBindingNestedProperties, I allow the use of globs in the
> property names specifically to avoid the complexities that introduces.
> The access controls will honor @ValidateNestedProperties and @Validate
> annotations the same as an @AllowBinding. If you prefer this kind of
> behavior, all you have to do is make sure all your allowed properties
> have a @Validate associated with them (even if it's empty).
>
> -Ben
>
> Gary Moselen wrote:
>
>>The examples where the default is '#this' would be for types like
>>String, Date, DateTime, Quantity/Measure which are all immutable types
>>and don't have nested properties. And when you have a mutable bean class
>>then 99% of the time it makes no sense to bind to the bean itself, right?
>>
>>Which means that I think it should default to the property itself by
>>default and allow no nested properties, and you would use that for
>>immutable types.
>>
>>@AllowBinding
>>private String foo;
>>
>>In the other case binding to '#this' doesn't normally make sense, I
>>would probably say forget about binding to 'this' altogether as soon as
>>they provide a pattern.
>>
>>@AllowBinding("**")
>>private Person person;
>>
>>OR you could follow the same form as Stripes @AllowBindingNestedProperties
>>
>>Gary
>>
>>Ben Gunter wrote:
>>
>>  
>>
>>>No matter the data type of the bean property, you always need to allow
>>>binding to #this if you want the property bound.
>>>
>>>    @AllowBinding(property="#this")
>>>    private String something;
>>>
>>>So the short answer is that *every* allowed property needs to be
>>>referenced as #this. I hadn't thought of it until you brought up this
>>>question, but I suppose the default value of "property" should be
>>>"#this" (or whatever) so that one can do this instead:
>>>
>>>    @AllowBinding
>>>    private String something;
>>>
>>>Another approach would be to add a boolean element to @AllowBinding
>>>and @DenyBinding that indicates if binding to the annotated property
>>>itself is allowed. The default would be true in both cases.
>>>
>>>    @AllowBinding(allowThis=false, property="*")
>>>    @DenyBinding(denyThis=false, property="*")
>>>
>>>That would simplify the expressions (and the code to parse them), but
>>>I don't know if it's the right approach.
>>>
>>>And finally, contrary to my original message on this subject, I now
>>>think @AllowBinding and @DenyBinding should be applicable to a class
>>>declaration so you can do this:
>>>
>>>    @StrictBinding
>>>    @AllowBinding(property="person**")
>>>    public class MyBean extends BaseActionBean {
>>>       private Person person;
>>>       // ...
>>>    }
>>>
>>>Instead of having to tag each property individually. Feedback is welcome.
>>>
>>>-Ben
>>>
>>>Gary Moselen wrote:
>>>
>>>    
>>>
>>>>>There is one thing I haven't come to a conclusion on yet, and I need
>>>>>your help with that. Since @AllowBinding and @DenyBinding are now
>>>>>specified on the property's field or getter or setter method, there
>>>>>needs to be some way in the property spec to refer to the annotated
>>>>>property itself. For example, this
>>>>>
>>>>>   @AllowBinding("**")
>>>>>   @DenyBinding("account**")
>>>>>   private Person person;
>>>>>
>>>>>says any property of person except account and all its sub-properties
>>>>>can be bound. But how does one specify that the person property itself
>>>>>can be bound? I could follow OGNL and use "#this". (I can't just use
>>>>>"this" because getThis() and setThis() are valid method names.) But I
>>>>>wanted to ask if anybody out there has a better idea.
>>>>>  
>>>>>
>>>>>        
>>>>>
>>>>Well the only time you ever want to bind to "this" is when there is a
>>>>TypeConverter for it and in that case you don't usually bind to nested
>>>>properties; *except* when you are using Stripernate which uses this as a
>>>>trick to hydrate the entity before the rest of the binding.
>>>>
>>>>My opinion was that the Stripernate trick is a not very natural use of
>>>>TypeConverters, but it's necessary because Stripes doesn't have a notion
>>>>of object hydration. In what other cases would binding to "this" be used
>>>>and there also be nested properties?
>>>>
>>>>I made a post about this a few days ago but nobody commented it :(
>>>>
>>>>Gary
>>>>  
>>>>
>>>>      
>>>>
>>
>>
>>
>>-------------------------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Stripes-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/stripes-users
>>  
>>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Stripes-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/stripes-users
>  
>



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Gary Moselen
In reply to this post by Tim Fennell-3
How about this: You make ObjectTypeConverter a configurable property of
Stripes? Then that gets documented as a nice way of hooking in hydration
type code. I go and configure ObjectTypeConverter to be
EntityTypeConverter and I am happy because my existing
TypeConverterFactory just returns normal immutable TypeConverters like
DateTimeConverter and any object types being bound hit the configured
ObjectTypeConverter which is EntityTypeConverter?

I don't know why it bothers me so much the way it is now, but I think
this would be a clean solution without changing any concepts in Stripes.

Gary


Tim Fennell wrote:

>It's funny, at first I had a bit of a similar reaction when folks  
>starting thinking about type converters for mutable persistent  
>objects, but as time went on I've come to think that not only is this  
>a neat trick, it's actually conceptually correct too!
>
>There are a set of persistent objects, and these objects for various  
>reasons have a specific property or properties marked as their  
>identity property.  Therefore, what more natural way to convert a  
>simple value into a persistent entity that to look it up using this  
>identity property?  You really are converting a String/int/long into  
>the full object.
>
>I think this makes a lot more sense now too that Aaron has a  
>Formatter installed for hibernate objects that looks up the identity  
>property and writes it out.  So you can now write things like:
>     <stripes:hidden name="person"/>
>without any knowledge of the structure of person, or it's identity  
>property. Therefore the full loop is constructed where a Person can  
>be externalized to a simple string, and converted back to a person  
>again.
>
>Maybe I'm just rationalizing, but this seems like quite a natural use  
>of formatters/converters to me now.
>
>-t
>
>On Oct 24, 2006, at 11:25 PM, Gary Moselen wrote:
>
>  
>
>>>It seems to me that Stripernate has a few fans on this list, and
>>>Stripernate does use type converters to bind directly into mutable  
>>>bean
>>>classes. And personally I think it's a pretty clever use of type
>>>converters. At the very least, if it's a feature that Stripes  
>>>supports
>>>then I need to support it in my code as well.
>>>      
>>>
>>I think Stripernate is great too and the TypeConverter trick is clever
>>but also weird. And this was an example of how it's weirdness causes
>>problems; but I guess noone else is seeing it that way... otherwise  
>>your
>>binding annotations look good.
>>    
>>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Stripes-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/stripes-users
>  
>



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: proposed bind access changes

Ben Gunter
In reply to this post by Gary Moselen
I wanted to do something like that, but the problem is that the globs already can contain literal dots. Giving special meaning to a leading dot would just lead to confusion. I decided to go with {this} as the notation. So you can do

@AllowBinding                       - allow binding to this property
@AllowBinding(property="{this}")    - same as above
@AllowBinding(property="{this}*")   - bind this property and its properties
@AllowBinding(property="*")         - bind only properties of this property
@AllowBinding(property="{this}.*")  - same as above


The {this} token is only valid at the beginning of the string. In any other position it doesn't make sense.

-Ben

Gary Moselen wrote:
One more idea for 'this' notation, a '.' prefix means 'this', it 
defaults to '.'

@AllowBinding
private String foo;

equivalent to 
@AllowBinding(property=".")
private String foo;

then for nested properties

@AllowBinding(property=".*")

means this and nested properties, while 

@AllowBinding(property="*")

just means nested properties.

Seems like a nice shorthand.

Gary


Ben Gunter wrote:

  
It seems to me that Stripernate has a few fans on this list, and 
Stripernate does use type converters to bind directly into mutable 
bean classes. And personally I think it's a pretty clever use of type 
converters. At the very least, if it's a feature that Stripes supports 
then I need to support it in my code as well.

As for @AllowBindingNestedProperties, I allow the use of globs in the 
property names specifically to avoid the complexities that introduces. 
The access controls will honor @ValidateNestedProperties and @Validate 
annotations the same as an @AllowBinding. If you prefer this kind of 
behavior, all you have to do is make sure all your allowed properties 
have a @Validate associated with them (even if it's empty).

-Ben

Gary Moselen wrote:

    
The examples where the default is '#this' would be for types like 
String, Date, DateTime, Quantity/Measure which are all immutable types 
and don't have nested properties. And when you have a mutable bean class 
then 99% of the time it makes no sense to bind to the bean itself, right?

Which means that I think it should default to the property itself by 
default and allow no nested properties, and you would use that for 
immutable types.

@AllowBinding
private String foo;

In the other case binding to '#this' doesn't normally make sense, I 
would probably say forget about binding to 'this' altogether as soon as 
they provide a pattern.

@AllowBinding("**")
private Person person;

OR you could follow the same form as Stripes @AllowBindingNestedProperties

Gary

Ben Gunter wrote:

 

      
No matter the data type of the bean property, you always need to allow 
binding to #this if you want the property bound.

   @AllowBinding(property="#this")
   private String something;

So the short answer is that *every* allowed property needs to be 
referenced as #this. I hadn't thought of it until you brought up this 
question, but I suppose the default value of "property" should be 
"#this" (or whatever) so that one can do this instead:

   @AllowBinding
   private String something;

Another approach would be to add a boolean element to @AllowBinding 
and @DenyBinding that indicates if binding to the annotated property 
itself is allowed. The default would be true in both cases.

   @AllowBinding(allowThis=false, property="*")
   @DenyBinding(denyThis=false, property="*")

That would simplify the expressions (and the code to parse them), but 
I don't know if it's the right approach.

And finally, contrary to my original message on this subject, I now 
think @AllowBinding and @DenyBinding should be applicable to a class 
declaration so you can do this:

   @StrictBinding
   @AllowBinding(property="person**")
   public class MyBean extends BaseActionBean {
      private Person person;
      // ...
   }

Instead of having to tag each property individually. Feedback is welcome.

-Ben

Gary Moselen wrote:

   

        
There is one thing I haven't come to a conclusion on yet, and I need 
your help with that. Since @AllowBinding and @DenyBinding are now 
specified on the property's field or getter or setter method, there 
needs to be some way in the property spec to refer to the annotated 
property itself. For example, this

  @AllowBinding("**")
  @DenyBinding("account**")
  private Person person;

says any property of person except account and all its sub-properties 
can be bound. But how does one specify that the person property itself 
can be bound? I could follow OGNL and use "#this". (I can't just use 
"this" because getThis() and setThis() are valid method names.) But I 
wanted to ask if anybody out there has a better idea.
  

       

            
Well the only time you ever want to bind to "this" is when there is a 
TypeConverter for it and in that case you don't usually bind to nested 
properties; *except* when you are using Stripernate which uses this as a 
trick to hydrate the entity before the rest of the binding.

My opinion was that the Stripernate trick is a not very natural use of 
TypeConverters, but it's necessary because Stripes doesn't have a notion 
of object hydration. In what other cases would binding to "this" be used 
and there also be nested properties?

I made a post about this a few days ago but nobody commented it :(

Gary
  

     

          

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
 

      
------------------------------------------------------------------------

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

------------------------------------------------------------------------

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
 

    



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users