Great monolog Greg, I was waiting for another installment. :) To be honest, I have no particular feelings one way or another, so am happy to go with what you decide.
FYI, I am putting together an architecture document for an up coming project (which hopefully will kick off in July/August) and I am going to propose Pivot for one of the UIs, so until then I am happy for things like this to be in a state of 'flux'. Cheers, Chris 2009/6/8 Greg Brown <[email protected]> > I see two options for resolving this issue: >> >> 1) Continue to support Bindable, but move it out of pivot.wtkx, possibly >> to pivot.util or pivot.wtk. As a result of this move, we would lose support >> for @Load, since it depends on WTKXSerializer. However, we could retain >> support for @Bind. >> >> 2) Eliminate Bindable altogether. This seems drastic, especially since the >> annotations do tend to clean up the code a bit. However, there is a lot of >> code behind that support that needs to be maintained, and I'm not sure it is >> justified. >> > > A third alternative is to continue to support binding, but only for trusted > code. That would eliminate the the need for the bind processor as well as > the need to extend a Bindable base class. Obviously, the downside is that it > is not a universal solution since it couldn't be used in unsigned applets. > > If we decide to take this approach, I would suggest moving the bind() > method back into WTKXSerializer: > > public void bind(Object object) throws BindException { ... } > > This would allow us to use it on any class, not just instances of Bindable. > > Note that this method is not static - it would operate on instances of > WTKXSerializer that had already been called to readObject(). So we still > wouldn't need @Load, but we could support @Bind. > > >
