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