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
