Thanks for chiming in, Noel. Though I prefer the load/store model, I agree that there are use cases for both binding styles (automatic vs. push/pull). However, if the Eclipse binding stuff works with Pivot, then there's probably not as strong a case for adding it to the platform.
Michael, if you do look into it, I'd be interested to hear about your experience. On Apr 21, 2010, at 12:19 PM, Noel Grandin wrote: > 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 >>>> >>> >> >>
