Migrating a pattern to Vaadin 7 (or: was this a bad choice?)

General
1

I have lots of elements in my app’s UI that depend on whether the user is logged in or out, what role they’re assigned, etc. Initially I had a bunch of spaghetti logic that would activate or deactivate UI elements based on these conditions, but since I’m using Scala and Scaladin, I wanted a neater way to do this. So I created a bunch of RepaintRequestListeners and a helper class like so:

abstract class PaintIf(f: => Boolean) extends Paintable.RepaintRequestListener {
def repaintRequested(event:Paintable.RepaintRequestEvent) {
println("Requesting repaint of "+event.getPaintable)
event.getPaintable match {
case c:com.vaadin.ui.Component =>
println("Caption: "+c.getCaption)
c.setVisible(f)
case _ =>
}
}
}

Then I could do things like:

class IsAuthenticated extends PaintIf(State.app.get.subject.isAuthenticated)

And, in a button definition:

menu.components += new LinkButton {
caption = “Jobs”
clickListeners += showJobs()
p.addListener(new IsAuthenticated)
}

When a user’s access rights change, I merely call repaintAll on the component that needs to update, and everything gets repainted based on the current access rights.

Neat solution, I thought, until I migrated to Vaadin 7 and saw that Paintable was deprecated.

So was this a bad idea? Is this mechanism replaced with something else in 7? I’d rather not have to spaghetti around a bunch of state changes, and would rather keep them alongside the declaration of the UI element if I can.

Thanks.

2

I don’t want to comment whether the idea was bad or not. If it worked, maybe it was a good idea.
How to fix it though in V7, I’m not 100% sure, but I guess you could do a Component extension
Creating a component extension
. And in that extension’s beforeClientResponse() do the checks.

3

Nice! Thanks, that looks like it should work.