pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noel Grandin <noelgran...@gmail.com>
Subject Re: [DISCUSS] WTKX binding
Date Tue, 09 Jun 2009 06:36:25 GMT

How about
(3) Drop Bindable as a class altogether, and make the binding process
work without it.
I don't see that class really need to implement it anyhow.
Either that or make it an interface, and make the necessary classes
implement it.

Regards, Noel.

Greg Brown wrote:
> 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

View raw message