You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ca...@usitc.gov on 2007/05/07 19:12:15 UTC
render() around advice
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: render() around advice
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <hl...@gmail.com> 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, Carlos.Fernandez@usitc.gov <Ca...@usitc.gov> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> 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
Re: render() around advice
Posted by Howard Lewis Ship <hl...@gmail.com>.
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, Carlos.Fernandez@usitc.gov <Ca...@usitc.gov> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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