You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/04/21 15:43:40 UTC
Re: data binding question
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
Re: data binding question
Posted by Greg Brown <gk...@mac.com>.
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 <gk...@mac.com> 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
>>>>
>>>
>>
>>
Re: data binding question
Posted by Noel Grandin <no...@gmail.com>.
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 <gk...@mac.com> 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
>>>
>>
>
>
Re: data binding question
Posted by Greg Brown <gk...@mac.com>.
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
>>
>
Re: data binding question
Posted by Greg Brown <gk...@mac.com>.
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
>