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 >
