We are currently using Tapestry 4.0.X, however, moving to 4.1 might be a better option than using a custom LinkRenderer or writing an EnhancementWorker.
Thanks. Carlos -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 1:51 PM To: Tapestry users Subject: Re: render() around advice I would do what Howard suggests - but if for some reason you really have to do it this other way there is a service point that allows you to do this without having to write an EnhancementWorker: http://tapestry.apache.org/tapestry4.1/tapestry-framework/hivedoc/module /tapestry.render.html On 5/7/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > 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 > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
