What Eelco meant is that allowEnabled does not dictate component visibility, allowRender does that. If allowRender returns false you will never get allowEnabled callback for the same component. allowEnabled dictates whether this component is enabled - normal mode or disabled - effectively read-only mode.
Our idea is to provide an interface that is completely free of implementation details, in fact it is nothing more then a callback interface for certain places in component lifecycle. -Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Maurice Marrink > Sent: Thursday, October 27, 2005 12:52 AM > To: wicket-develop@lists.sourceforge.net > Subject: RE: [Wicket-develop] integrating authorization > > Not sure i get what isn't, but disabling components based on > user authorization is also exactly what we need for our project. > > Yes throwing an exception should do the same trick. > > ________________________________ > > Maurice Marrink > www.topicus.nl > > -----Original Message----- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] > Sent: donderdag 27 oktober 2005 1:36 > To: wicket-develop@lists.sourceforge.net > Subject: Re: [Wicket-develop] integrating authorization > > Nope it isn't. It is one of the main things I want to use in > my current project. Not rendering components based on the > current roles of a user. Kind of like portal functionality. > > I didn't really think of the case of letting one component > trigger a page to be invalid. I see... good case too. I think > that might be an implementation detail though. Instead of > returning the boolean, a component may still throw an auth > related exception. That should work, right? > > Eelco > > > On 10/26/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > and Links/Labels are using allowEnabled for there visible state. > > Now that's great I wonder why we haven't thought of that > before, we'll > just > > use allowEnabled to dictate a components visibility!. It > makes so much > > sense! > > Sorry for being sarcastic here but is getting late :) You > can't have > > allowEnabled doing double duty here it will confuse the > hell > > out of people. > > But johan is right we need a way of letting a component / > model block > access > > to a page completely or just allow the page to be displayed but not > the > > component itself. > > And you know what, we already can by using actions like access, read > and > > write. If something does not have access it blocks the page, if it > does not > > have read the page will display but not the component. > > > > Maurice > > > > ________________________________________ > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > Behalf Of Johan > > Compagner > > Sent: donderdag 27 oktober 2005 1:14 > > To: wicket-develop@lists.sourceforge.net > > Subject: Re: [Wicket-develop] integrating authorization > > > > yes that i did get. > > So if one component on the page returns false for > allowRender() then > > the page it self is not visible (allowAccess() failes) > > > > and Links/Labels are using allowEnabled for there visible state. > > > > On 10/27/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > It works exactly like isVisible, with the exception that it will > > allways overrule isVisible (I'll put that in the docs). > > > > Eelco > > > > > > On 10/26/05, Johan Compagner <[EMAIL PROTECTED] > wrote: > > > where will allowRender() be called in wicket? > > >I think the most logical first place it the Page.checkAccess() or > > > Page.checkSecurity() that is also called besides checkAccess() > > > > > >Does then the implementation do the compleet check for the page? > > >So the page itself and then all the components on the page? > > >But how does it check the components and there model data? ( think > models > > > > > need some kind of marker interface like SecurityModel) > > > > > >Because it can be that a form's model data is saying i can't render > so > > the > > > page can be renderd > > >But a link can also say i can't be renderd but that > doesn't mean the > page > > > > > can't be rendered (just the link can't be rendered) > > > > > >Or if allowRender() is false in any component/model on the > page then > the > > > complete page can't be rendered > > >but then allowEnabled is used to say to a link that it can't be > visible > > (so > > > there are no non enabled links they are always not rendered) > > > > > > > > > > > > On 10/27/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > Here's the interface method we (Jonathan, Igor and I) think will > work: > > > > > > > > /** > > > >* Checks whether an instance of the given component class may > > be > > > created. > > > >* If this method returns false, a [EMAIL PROTECTED] > > AuthorizationException} > > > is thrown > > > >* in during construction. > > > >* > > > >* @param c > > > >*the component to check for > > > >* @return whether the given component may be created */ boolean > > > >allowCreateComponent(Class c); > > > > > > > > /** > > > >* Gets whether the given component may be rendered. If this > > > method returns > > > >* false, the component is not rendered, and neither are it's > > > children. > > > >* > > > >* @param c > > > >*the component to check for > > > >* @return whether the given component may be rendered */ > boolean > > > >allowRender(Component c); > > > > > > > > /** > > > >* <p> > > > >* Gets whether a component is allowed to be enabled. If this > > > method returns > > > >* true, a component may decide by itself (typically using it's > > > enabled > > > >* property) whether it is enabled or not. If this method > > returns > > > false, the > > > >* passed component is marked disabled, regardless it's enabled > > > property. > > > >* </p> > > > >* <p> > > > >* When a component is not allowed to be enabled (in effect > > > disabled through > > > >* the implementation of this interface), Wicket will try to > > > prevent model > > > >* updates too. This is not completely fail safe, as constructs > > > like: > > > >* > > > >* <pre> > > > >* User u = (User)getModelObject(); > > > >* u.setName ("got you there!"); > > > >* </pre> > > > >* > > > >* can't be prevented. Indeed it can be argued that any model > > > protection is > > > >* best dealt with in your model objects to be completely > > secured. > > > Wicket > > > >* will catch all normal use though. > > > >* > > > >* </p> > > > >* > > > >* @param c > > > >*the component to check for > > > >* @return whether a component is allowed to be enabled > */ boolean > > > >allowEnabled(Component c); > > > > > > > > Eelco > > > > > > > > > > > > On 10/26/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > > > > Well, then there's no special wicket support for that > nescesarry > > either. > > > > > > > > > > >I only want to test at a certain point what is inside the > model. > > And > > > if a > > > > > > user can see that object > > > > > >and if he can see it if he can alter it. > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > Get Certified Today * Register for a JBoss Training Course Free > > > > Certification Exam for All Training Attendees Through End of > 2005 > > > > Visit http://www.jboss.com/services/certification for > > > more information > > > > _______________________________________________ > > > > Wicket-develop mailing list > > > > Wicket-develop@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course Free > > Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for more > information > > _______________________________________________ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course Free > > Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for more > information > > _______________________________________________ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through > End of 2005 Visit http://www.jboss.com/services/certification > for more information _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through > End of 2005 Visit http://www.jboss.com/services/certification > for more information _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
