Re: visibility Behavior?

[Igor Vaynberg]

look at wicket-auth-roles, there the metadata storage is used to
attach permissions to arbitrary components. this doesnt have the
overhead of behaviors.

-igor

On Mon, Mar 30, 2009 at 8:19 AM, Ryan McKinley  wrote:
> I am working on some security integration (Ki/wicket), and am looking at a
> general way to set component visibility based on the user permissions/roles
> etc.
>
> Of course I could do:  component.setVisible( false ), but that gets really
> verbose when 'false' can be a rather long statement.
>
> Wicket-auth-roles uses the authorize actions annotation to disable
> "RENDER/ENABLE"
>
> I understand how to apply that if I construct a class with the annotation,
> but how would I apply something like that to an arbitrary component?
>
> Could this be implemented with a Behavior?
>
> Perhaps, beforeRender() could set enabled/visibility and cleanup() would
> restore it?
>
> It would be great to be able to do:
>
> WebMarkupContainer stuff = new WebMarkupContainer( "stats" );
> stats.add( new AuthorizationConstraint( "view: stats" );
>
> or something like that.
>
> Any pointers?  Am I missing another preferred way to do this?
>
> thanks
> ryan
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: visibility Behavior?

[Stephan Koch]

Hi Ryan,

works nice with behaviors. I use somehing like the following to
show/hide components based on my user roles:

public class MySecurityBehavior extends AbstractBehavior {

private boolean isVisible() {
// your logic for security checks...
}

@Override
public void bind(Component component) {
boolean visible = isVisible();
component.setVisibilityAllowed(visible);
component.setVisible(visible);
}

}

then just add that to your components.

-stephan

Ryan McKinley wrote:
> I am working on some security integration (Ki/wicket), and am looking at
> a general way to set component visibility based on the user
> permissions/roles etc.
> 
> Of course I could do:  component.setVisible( false ), but that gets
> really verbose when 'false' can be a rather long statement.
> 
> Wicket-auth-roles uses the authorize actions annotation to disable
> "RENDER/ENABLE"
> 
> I understand how to apply that if I construct a class with the
> annotation, but how would I apply something like that to an arbitrary
> component?
> 
> Could this be implemented with a Behavior?
> 
> Perhaps, beforeRender() could set enabled/visibility and cleanup() would
> restore it?
> 
> It would be great to be able to do:
> 
> WebMarkupContainer stuff = new WebMarkupContainer( "stats" );
> stats.add( new AuthorizationConstraint( "view: stats" );
> 
> or something like that.
> 
> Any pointers?  Am I missing another preferred way to do this?
> 
> thanks
> ryan
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

visibility Behavior?

[Ryan McKinley]

I am working on some security integration (Ki/wicket), and am looking  
at a general way to set component visibility based on the user  
permissions/roles etc.


Of course I could do:  component.setVisible( false ), but that gets  
really verbose when 'false' can be a rather long statement.


Wicket-auth-roles uses the authorize actions annotation to disable  
"RENDER/ENABLE"


I understand how to apply that if I construct a class with the  
annotation, but how would I apply something like that to an arbitrary  
component?


Could this be implemented with a Behavior?

Perhaps, beforeRender() could set enabled/visibility and cleanup()  
would restore it?


It would be great to be able to do:

WebMarkupContainer stuff = new WebMarkupContainer( "stats" );
stats.add( new AuthorizationConstraint( "view: stats" );

or something like that.

Any pointers?  Am I missing another preferred way to do this?

thanks
ryan

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org