If you're going to do binding stuff, it is well worth looking at the eclipse binding library - in my opinion, it is the best available in the Java world at the moment. And its mostly toolkit agnostic, so it would be possible to use them in Pivot.
For myself, I'm using a home-grown binding layer in one of my Swing apps, but that was because my efforts pre-dated the Eclipse library. Binding is hard. Sometimes you want the binding to be bi-directional, sometimes you want uni-directional, sometimes a mixture of both. Sometimes you want it to be automatic, sometimes you want explicit pull/push. -- Noel On Wed, Apr 21, 2010 at 16:42, Greg Brown <[email protected]> wrote: > Two additional thoughts: > > - You'd probably want the binding to be bi-directional, such that when the > value changes in the component, it is propagated to the model. So these > monitors would also need to listen to the destination object (making > "destination" probably not the right term). > > - ScriptEngineBindingMonitor is probably not necessary, since a Map could be > used to wrap the engine's bind context. > > Maybe "context" is a better term for "source" and "target" is a better term > for "destination". > > On Apr 21, 2010, at 9:51 AM, Greg Brown wrote: > >> Of course, in order for the BeanPropertyMonitor to work, the bound bean >> would need to fire events as you described in your original email. >> >> On Apr 21, 2010, at 9:43 AM, Greg Brown wrote: >> >>> Moving this to the dev list (if you are not subscribed there, you probably >>> should be). >>> >>> I have been thinking about this, and I think it might be pretty easy to >>> achieve. Currently, we support the following syntax in WTKXSerializer: >>> >>> <Label text="$foo"/> >>> >>> This means "load the value of the local variable 'foo' into the text >>> property of this Label". I assume that what you would like it to mean is, >>> "load the value of the local variable 'foo' into the 'text' property of >>> this Label, and update 'text' whenever 'foo' changes". Is that correct? >>> Further, I assume that you'd also want to support nested properties, e.g.: >>> >>> <Label text="$foo.bar"/> >>> >>> I think this could be accomplished by a hypothetical set of monitor >>> classes. The first would need to monitor the script engine scope, and would >>> probably look like: >>> >>> ScriptEngineBindingMonitor(String key, Object object, String property) >>> >>> Assuming that "foo" is a Java bean, the second might look like: >>> >>> BeanPropertyMonitor(Object bean, String property, Object object, String >>> property) >>> >>> If "foo" is a Map, it might look like: >>> >>> MapValueMonitor(Map<String, ?> map, String key, Object object, String >>> property) >>> >>> These classes would attach themselves as listeners to their respective >>> sources, and propagate changes to the destination object (in this case, the >>> Label instance). >>> >>> Does that make sense? >>> >>> >>> On Apr 21, 2010, at 9:21 AM, Michael Allman wrote: >>> >>>> On Wed, 21 Apr 2010, Greg Brown wrote: >>>> >>>>>> I am also not a fan of MVC frameworks for GUI applications. Basically, I >>>>>> think their fundamental premise (that MVC is a valid approach to global >>>>>> application design) is crap, but I'll save it for another time or never. >>>>> >>>>> I used to agree with this, but now I see some value in the concept of a >>>>> macro-level MVC design. I don't know that using a framework is >>>>> necessarily the right way to accomplish it, but I do think the design >>>>> pattern is valid. I also think it works well with the load/store model, >>>>> since load()/store() is basically a higher-level get/set, and the event >>>>> support can be provided by Pivot's new pub/sub messaging API. >>>> >>>> I have no beef with macro components, as long as they're well-encapsulated >>>> with well-defined, minimal interfaces. >>>> >>>> On the other hand, I've seen designs where basically all of the high-level >>>> state is stored on a single class. Major yuck-o. I've seen "model" >>>> classes that are on the order of hundreds or thousands of lines of code. >>>> Then there are the global event dispatchers that everything is tied to. >>>> Kinda makes it hard to understand a class's interface and behavior when >>>> it's calling back to global objects. >>>> >>>> When every object is tied back to some application global data-structure >>>> or other object somewhere on high (usually through a reference to a static >>>> variable or method), I get nervous. It looks fragile. >>>> >>>> I gave a 20 minute preso on my thoughts on rich GUI application design >>>> earlier this year to my local flex user group. You might take a look if >>>> you feel like it. It's small. It's on my home page: >>>> >>>> https://www.allman.ms/ >>>> >>>> Ciao, >>>> >>>> Michael >>> >> > >
