Hi Karel,
Definitely that is one thing I've been looking at with our
application -- lots and lots of boilerplate code for listeners and
registering listeners, and tons of POJOs just to hold values for the
GUI, which are then transferred to the "real" objects.... I'd like to
have some automatic ways to register listeners, and then be able to use
Lambdas or closures for handling events (property change notifications).
So, sounds like we're pretty much on the same page with this (or am
I off base still?).... Feel free to share other thoughts as you see things.
Thanks,
~Roger
On 1/20/15 6:27 AM, Karel Hübl wrote:
Hi Roger,
We plan to use Pivot with Groovy in our next project. Expected use cases:
-Use closures instead of annonymous inner classes adapting common
Pivot interfaces – typically component listeners, asynchronous actions
-Use groovy beans for property bindable models. Now we use POJO’s, so
we need to implement model POJO, model property listener and property
change notification in POJO. We expect, we could intercept property
changes in Groovy using GroovyInterceptable.setProperty() and
implement org.apache.pivot.collections.Map on groovy bean parent /
trait. The goal is to be able to declare strictly properties on groovy
model classes and do not implement (boilerplate) support for Pivot
property change notifications.
May be, the first use case could be somehow supported in future Pivot
versions. I mean Pivot developers could have option to handle events
of Pivot components by setting Lambda (Closure) handlers instead of
implementing and registering custom listeners.
Regards Karel
*From:* Roger Whitcomb [mailto:roger.whitc...@actian.com]
*Sent:* Friday, January 16, 2015 12:21 AM
*To:* Pivot Users; 'd...@pivot.apache.org'
*Subject:* Anyone using ...?
Hi,
I’m curious about anyone using Pivot with either Java
8 Lambdas, or using Pivot with Scala or Groovy. If you are could you
let us know with a few comments about your experiences (good or bad)?
Basically thinking about changes / extensions to Pivot that we could
work on for future versions to more easily / compactly support these
newer languages.
Thanks,
~Roger Whitcomb
