Ok, the runtime part of this is done. Check out http://svn.apache.org/repos/asf/incubator/pivot/trunk/tutorials/src/pivot/tutorials/drawing/RotateLine.java to see what it looks like when used in an application.
I'll be finishing pivot.wtkx.BindProcessor soon, which will effectively inline the call to bind() so that it can run in a sandbox environment (e.g. applets). But this step will be optional -- in absence of running the annotation processor on your files during compilation, the binding will use the runtime implementation. FYI, the annotation processor can be seen at http://svn.apache.org/repos/asf/incubator/pivot/trunk/wtk/src/pivot/wtkx/BindProcessor.java. It currently injects the binding into an instance initializer, but I'll be changing it so that it replaces the bind() call with the appropriate code. Thoughts? -T On Wed, May 6, 2009 at 8:33 AM, Greg Brown <[email protected]> wrote: > It is optional. We've gone through a couple of design iterations recently, > but what we're currently talking about is creating an abstract base class > called pivot.wtkx.Bindable that you would extend if you wanted to use this > feature. This class would define a single method called bind() that would use > reflection to perform the binding at runtime. > > Since the reflection approach doesn't work in untrusted applets, we'll also > be providing a way to inline the bind logic. Todd has been working on a bind > processor that dynamically injects the binding code into annotated classes at > compile time, via javac. > > > On Wednesday, May 06, 2009, at 02:59AM, "Christopher Brind" > <[email protected]> wrote: >>This is an interesting discussion, but my view is that any kind of >>pre-processing should be an optional step. To me, one of the attractive >>things about Pivot is that (if I wanted) I could create an app using vi and >>javac. It is a discouraging thought that I might have to run something >>before or after javac as well. Additionally, one of the big turn offs for >>me about JavaFX is having to learn a new grammar. Pivot is pure Java and an >>XML structure that makes sense (because it ultimately represents an object >>model for which I have Javadocs). >> >>Now if you can generate class files from that XML that would be cool - as >>long as it's not required. >> >>I hope I haven't misunderstood the direction of this discussion. :) >> >>Cheers, >>Chris >> >> >> >>2009/5/6 Philippe Lhoste <[email protected]> >> >>> On 04/05/2009 16:26, Noel Grandin wrote: >>> >>>> Once you get into code generation, the world is your oyster :-) >>>> >>> >>> That's the road taken by JavaFX: to generate Java code out of their >>> language. >>> >>> But it definitely makes deployment a little harder (one extra build >>>> step), and code generation is not trivial. >>>> >>> >>> Indeed. Processing "language" (http://Processing.org) took this road, >>> using Antlr (a modified Java grammar): they take a simple "script" and add a >>> class declaration, a main() method, handle properly imports, adds F at the >>> end of literal decimal values, replace occurrences of 'color' "keyword" by >>> 'int', etc. >>> This makes it much easier to write small programs for newbies, while >>> remaining fully compatible with Java. >>> But the drawback is that the author never had the time to update to Java >>> 1.5 syntax (a quite different grammar file, available but yet to modify) so >>> we don't have access to typed collections, for each loops and such... >>> >>> A pre-processor is cool, but is quite some work to make it work and to >>> maintain... >>> And too much might be badly perceived by users (some people love JavaFX >>> language syntax, others hate it! -- I am in between, some features are cool, >>> others are irritating). >>> >>> -- >>> Philippe Lhoste >>> -- (near) Paris -- France >>> -- http://Phi.Lho.free.fr >>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> >> >
