Unfortunately in cases where rendering the link is inappropriate, we don't even want to render the portion of the template the link surrounds. It is my understanding that when the ILinkComponent is disabled the default renderer will output the template.
Carlos -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 1:33 PM To: Tapestry users Subject: Re: render() around advice The link components all have a disabled parameter, so it's just a matter of hooking that up. Depending on the rules for determining enabled vs. disabled, you may want to try creating your own binding prefix. For example, let's say you are basing this upon the user's role. <a jwcid="@DirectLink" disabled="role:!admin" listener="listener:doResetDB">Reset the Database</a> In this way, the logic for the expression "role:!admin" is centralized in the BindingFactory for prefix "role:", rather than scattered about or accessed from super-class properties or such. On 5/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Java 5 > Tapestry 4.0.x > > I would like to make runtime checks to determine if a link will render. > To avoid configuration tedium we do not want to use custom link > renderers. > > The desired solution would behave like around advice, it would: > - intercept the render() call (or some other method with HTML generation > responsibilities) > - make a runtime check based on the user authorizations and the target > (e.g. page, component etc) > - call/skip the superclasses/targets default render() implementation > > Based on a variety of other posts, it seems like the EnhancementWorker > and EnhancementOperation are best suited for this. > EnhancementOperation.addMethod() would allow me to extend the base > component class and add any arbitrary code. However, if any other > worker has modified the method, the EnhancementOperation will throw an > exception. I assume the same would happen if a worker attempted to use > extendMethodImplementation on the render() method. > > This might be a moot point, because I we don't use any > EnhancementWorker's that conflict with our impl. However, all things > being equal, I would like a guarantee that our enhancement won't cause a > runtime conflict. > > Is there a better way to provide these enhancements, perhaps using > Hivemind's proxy support? > > Thanks for any help! > > Carlos > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
