pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: data binding question
Date Wed, 21 Apr 2010 13:51:18 GMT
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
> 


Mime
View raw message