pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gbr...@vmware.com>
Subject [DISCUSS] WTKX binding
Date Mon, 08 Jun 2009 18:17:29 GMT
Hi all,

I've recently been working on a "real-world" app using Pivot, and I've  
run into a situation where I'd like to use WTKX binding, but I can't.  
I want to create a FileBrowserSheet class that extends Sheet and loads  
its contents from a WTKX file.

In order for a Sheet subclass to take advantage of binding to process  
the WTKX, Sheet would somehow need to extend Bindable. However,  
Sheet's root base class is Component, which currently extends Object.  
We could conceivably make Component extend Bindable; however, we  
decided a while back for a variety of reasons that WTK classes should  
not be dependent on WTKX, and I would prefer to stick with that  
decision.

I think it will be fairly common for developers to want to bind to  
application-specific Window subclasses; for example, LoginDialog,  
FileOpenDialog, ContactInfoSheet, etc. I also think that any non- 
trivial application will want to define a main application window  
class rather than embedding the UI details in the application itself.  
For example, I might define MyApplication that implements Application,  
and MyApplicationWindow that extends Window. MyApplication would  
simply serve as the entry point into the application, playing the same  
role as the main() method in a typical Java application. We wouldn't  
be able to use binding in any of these use cases.

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.

I'm leaning pretty strongly towards #2. This is what the code in my  
FileBrowserSheet constructor looks like without binding (I'm assuming  
the existence of a template parameter in WTKXSerializer - that can be  
discussed as another topic, if necessary):

Resources resources = new Resources(this);
setTitle(resources.getString("title"));

WTKXSerializer<Component> wtkxSerializer = new  
WTKXSerializer<Component>(resources);
setContent(wtkxSerializer.readObject(this, "file_browser.wtkx"));

folderTreeView = wtkxSerializer.get("folderTreeView");
okButton = wtkxSerializer.get("okButton");
cancelButton = wtkxSerializer.get("cancelButton");

With binding, the final three lines would be replaced with bind(),  
which is very concise. However, the above code is still pretty  
readable. Yes, we have to manually assign the member variables, but is  
that really that much of a burden on developers? Is the simplification  
offered by the bind() method enough to justify the additional code  
maintenance of the Bindable class and the bind processor?

The bind processor is what we use to rewrite the Bindable class files  
at compile time so they can run in an untrusted applet. It is worth  
noting that the processor currently relies on undocumented features of  
the javac compiler. When binding seemed like it might be more  
generally useful, I thought that this would be an OK risk to take.  
However, now I don't think so.

I'm going to suggest that we eliminate the Bindable class and revert  
to the previous way of loading and processing WTKX. I've made some  
minor API additions that simplify the use of WTKXSerializer directly.  
pivot.util.Resources now takes a base object or class, so you can write:

Resources resources = new Resources(this);

If your class is named com.foo.MyClass, it will automatically load  
com.foo.MyClass.json.

I also added a readObject() overload to WTKXSerializer that takes an  
object and a resource name. Now, instead of this:

wtkxSerializer.readObject(getClass().getResource("foo.wtkx"));

you can write this:

wtkxSerializer.readObject(this, "foo.wtkx");

Again, minor changes, but they make the code that much more readable.

I understand that @Bind is pretty convenient, but it can't currently  
be used in what I suspect will be a common use case, and, in my  
opinion, adapting it such that it can be used for this purpose makes  
it less compelling (especially since it requires undocumented features  
of the compiler). Please let me know what you think.

Thanks,
Greg


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message