pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: [DISCUSS] WTKX binding
Date Tue, 09 Jun 2009 12:29:04 GMT
We actually do need a Bindable base class in order to support binding  
in untrusted code. However, if we decide to drop support for that, we  
could move the bind() method to WTKXSerializer and eliminate Bindable.  
Is that consistent with what you are suggesting?

On Jun 9, 2009, at 2:36 AM, Noel Grandin wrote:

> Hi
>
> 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
>>
>>
>


Mime
View raw message