Home » Modeling » EMF » EMF delegates and databinding
| EMF delegates and databinding [message #718125] |
Tue, 23 August 2011 10:13  |
Eclipse User |
|
|
|
Originally posted by:
Hi,
For JS4EMF I have implemented general support for databinding, based on
recording the reading of EObject features within an EObject tree, during
the evaluation of an expression. If you record such dependencies, you
can attach adapters and re-evaluate the expression when the features are
changed.
Such recording is cumbersome in handwritten code, but fairly easy for an
interpreted language or when you generate code. E.g. for JS4EMF the
wrappers that Rhino uses can be made to record the dependencies. I would
guess this could be supported in OCL or Xbase, too. So the question is,
does it make sense for the delegate mechanism to do this in a
standardized way? E.g. specify a means for returning both a value from
evaluating an expression AND a notifier that tells when the expression
might change value, because a read feature has changed?
Hallvard
|
|
|
| Re: EMF delegates and databinding [message #718132 is a reply to message #718125] |
Tue, 23 August 2011 11:14  |
|
Am 23.08.2011 12:13, schrieb Hallvard Trætteberg:
> Hi,
>
> For JS4EMF I have implemented general support for databinding, based on recording the reading of EObject features
> within an EObject tree, during the evaluation of an expression. If you record such dependencies, you can attach
> adapters and re-evaluate the expression when the features are changed.
>
> Such recording is cumbersome in handwritten code, but fairly easy for an interpreted language or when you generate
> code. E.g. for JS4EMF the wrappers that Rhino uses can be made to record the dependencies. I would guess this could be
> supported in OCL or Xbase, too. So the question is, does it make sense for the delegate mechanism to do this in a
> standardized way? E.g. specify a means for returning both a value from evaluating an expression AND a notifier that
> tells when the expression might change value, because a read feature has changed?
That reminds me to https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF delegates and databinding [message #718162 is a reply to message #718132] |
Tue, 23 August 2011 12:47 |
| Eclipse User |
|
|
|
Originally posted by:
On 23.08.11 13.14, Eike Stepper wrote:
> Am 23.08.2011 12:13, schrieb Hallvard Trætteberg:
>> Hi,
>>
>> For JS4EMF I have implemented general support for databinding, based
>> on recording the reading of EObject features within an EObject tree,
>> during the evaluation of an expression. If you record such
>> dependencies, you can attach adapters and re-evaluate the expression
>> when the features are changed.
>>
>> Such recording is cumbersome in handwritten code, but fairly easy for
>> an interpreted language or when you generate code. E.g. for JS4EMF the
>> wrappers that Rhino uses can be made to record the dependencies. I
>> would guess this could be supported in OCL or Xbase, too. So the
>> question is, does it make sense for the delegate mechanism to do this
>> in a standardized way? E.g. specify a means for returning both a value
>> from evaluating an expression AND a notifier that tells when the
>> expression might change value, because a read feature has changed?
>
> That reminds me to https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
Yes, I know of this feature request. However, it's more reasonable for a
scripting language or DSL to have such a feature, since the cost will
usually be small compared to other overhead, and not every Ecore user
will need to pay this cost.
Hallvard
|
|
|
| Re: EMF delegates and databinding [message #718194 is a reply to message #718162] |
Tue, 23 August 2011 14:51 |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
I'm not sure I understand who would end up managing this notifier
thing. The delegate is passed the object with the feature and is
certainly able to fire notifications to that object when the feature's
value changes for whatever reason. Isn't that sufficient?
On 23/08/2011 5:47 AM, Hallvard Trætteberg wrote:
> On 23.08.11 13.14, Eike Stepper wrote:
>> Am 23.08.2011 12:13, schrieb Hallvard Trætteberg:
>>> Hi,
>>>
>>> For JS4EMF I have implemented general support for databinding, based
>>> on recording the reading of EObject features within an EObject tree,
>>> during the evaluation of an expression. If you record such
>>> dependencies, you can attach adapters and re-evaluate the expression
>>> when the features are changed.
>>>
>>> Such recording is cumbersome in handwritten code, but fairly easy for
>>> an interpreted language or when you generate code. E.g. for JS4EMF the
>>> wrappers that Rhino uses can be made to record the dependencies. I
>>> would guess this could be supported in OCL or Xbase, too. So the
>>> question is, does it make sense for the delegate mechanism to do this
>>> in a standardized way? E.g. specify a means for returning both a value
>>> from evaluating an expression AND a notifier that tells when the
>>> expression might change value, because a read feature has changed?
>>
>> That reminds me to https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>
> Yes, I know of this feature request. However, it's more reasonable for
> a scripting language or DSL to have such a feature, since the cost
> will usually be small compared to other overhead, and not every Ecore
> user will need to pay this cost.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF delegates and databinding [message #718267 is a reply to message #718194] |
Tue, 23 August 2011 18:47 |
| Eclipse User |
|
|
|
Originally posted by:
On 23.08.11 16.51, Ed Merks wrote:
>
> I'm not sure I understand who would end up managing this notifier thing.
> The delegate is passed the object with the feature and is certainly able
> to fire notifications to that object when the feature's value changes
> for whatever reason. Isn't that sufficient?
The proposal is to define a standard way of asking a delegate to record
dependencies during evaluation of expressions, e.g. add a parameter that
is an object to which the delegate can add an EObject/EStructuralFeature
pair for each feature it reads. E.g
interface EObjectFeatureDependencyRecorder {
recordDependency(EObject, EStructuralFeature);
}
A method that evaluates expression has an additional parameter of this
class, that has its recordDependency method called during evaluation of
the expression. When the result of evaluating the expression is
returned, all dependencies will have been collected and the caller will
have enough information to listen for relevant change events and know
when the expression needs to be re-evaluated. It's the callers
responsibility to attach the listeners, based on the recorded dependencies.
Clearer?
Hallvard
>
>
> On 23/08/2011 5:47 AM, Hallvard Trætteberg wrote:
>> On 23.08.11 13.14, Eike Stepper wrote:
>>> Am 23.08.2011 12:13, schrieb Hallvard Trætteberg:
>>>> Hi,
>>>>
>>>> For JS4EMF I have implemented general support for databinding, based
>>>> on recording the reading of EObject features within an EObject tree,
>>>> during the evaluation of an expression. If you record such
>>>> dependencies, you can attach adapters and re-evaluate the expression
>>>> when the features are changed.
>>>>
>>>> Such recording is cumbersome in handwritten code, but fairly easy for
>>>> an interpreted language or when you generate code. E.g. for JS4EMF the
>>>> wrappers that Rhino uses can be made to record the dependencies. I
>>>> would guess this could be supported in OCL or Xbase, too. So the
>>>> question is, does it make sense for the delegate mechanism to do this
>>>> in a standardized way? E.g. specify a means for returning both a value
>>>> from evaluating an expression AND a notifier that tells when the
>>>> expression might change value, because a read feature has changed?
>>>
>>> That reminds me to https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>>
>> Yes, I know of this feature request. However, it's more reasonable for
>> a scripting language or DSL to have such a feature, since the cost
>> will usually be small compared to other overhead, and not every Ecore
>> user will need to pay this cost.
>>
>> Hallvard
|
|
| |
| Re: EMF delegates and databinding [message #718577 is a reply to message #718267] |
Wed, 24 August 2011 17:23 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 23/08/2011 11:47 AM, Hallvard Trætteberg wrote:
> On 23.08.11 16.51, Ed Merks wrote:
>>
>> I'm not sure I understand who would end up managing this notifier thing.
>> The delegate is passed the object with the feature and is certainly able
>> to fire notifications to that object when the feature's value changes
>> for whatever reason. Isn't that sufficient?
>
> The proposal is to define a standard way of asking a delegate to
> record dependencies during evaluation of expressions, e.g. add a
> parameter that is an object to which the delegate can add an
> EObject/EStructuralFeature pair for each feature it reads. E.g
>
> interface EObjectFeatureDependencyRecorder {
> recordDependency(EObject, EStructuralFeature);
> }
>
I see. We'd definitely want to look at the notification stuff that Axel
worked on for use in OCL...
> A method that evaluates expression has an additional parameter of this
> class, that has its recordDependency method called during evaluation
> of the expression. When the result of evaluating the expression is
> returned, all dependencies will have been collected and the caller
> will have enough information to listen for relevant change events and
> know when the expression needs to be re-evaluated. It's the callers
> responsibility to attach the listeners, based on the recorded
> dependencies.
The listening part sounds like something else that can be handled in a
generic way.
>
> Clearer?
>
> Hallvard
>
>>
>>
>> On 23/08/2011 5:47 AM, Hallvard Trætteberg wrote:
>>> On 23.08.11 13.14, Eike Stepper wrote:
>>>> Am 23.08.2011 12:13, schrieb Hallvard Trætteberg:
>>>>> Hi,
>>>>>
>>>>> For JS4EMF I have implemented general support for databinding, based
>>>>> on recording the reading of EObject features within an EObject tree,
>>>>> during the evaluation of an expression. If you record such
>>>>> dependencies, you can attach adapters and re-evaluate the expression
>>>>> when the features are changed.
>>>>>
>>>>> Such recording is cumbersome in handwritten code, but fairly easy for
>>>>> an interpreted language or when you generate code. E.g. for JS4EMF
>>>>> the
>>>>> wrappers that Rhino uses can be made to record the dependencies. I
>>>>> would guess this could be supported in OCL or Xbase, too. So the
>>>>> question is, does it make sense for the delegate mechanism to do this
>>>>> in a standardized way? E.g. specify a means for returning both a
>>>>> value
>>>>> from evaluating an expression AND a notifier that tells when the
>>>>> expression might change value, because a read feature has changed?
>>>>
>>>> That reminds me to
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
>>>
>>> Yes, I know of this feature request. However, it's more reasonable for
>>> a scripting language or DSL to have such a feature, since the cost
>>> will usually be small compared to other overhead, and not every Ecore
>>> user will need to pay this cost.
>>>
>>> Hallvard
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF delegates and databinding [message #718625 is a reply to message #718577] |
Wed, 24 August 2011 21:20 |
| Eclipse User |
|
|
|
Originally posted by:
On 24.08.11 19.23, Ed Merks wrote:
> Hallvard,
>
> Comments below.
>
> On 23/08/2011 11:47 AM, Hallvard Trætteberg wrote:
>> On 23.08.11 16.51, Ed Merks wrote:
>>
>> The proposal is to define a standard way of asking a delegate to
>> record dependencies during evaluation of expressions, e.g. add a
>> parameter that is an object to which the delegate can add an
>> EObject/EStructuralFeature pair for each feature it reads. E.g
>>
>> interface EObjectFeatureDependencyRecorder {
>> recordDependency(EObject, EStructuralFeature);
>> }
>>
> I see. We'd definitely want to look at the notification stuff that Axel
> worked on for use in OCL...
The article was very interesting reading. It describes an analytic
method for computing the objects for which an expression may evaluate to
a different value, after a particular change event. There are however
two shortcomings to this approach if used for the purpose of databinding
(correct me if I'm wrong):
1) It assumes you already have the change event, and computes the
expressions that may need re-evaluation. E.g. if the feature o.p has
changed, you know that the expression o.p needs to be re-evaluated.
We're interested in knowing which events to listen for, given an
expression. E.g. if you want to know whether the expression o.p needs
re-evaluation, you should listen for change events for the o.p.
2) I believe the approach works for OCL, because OCL has certain
limitations that make the analysis tractable. Scripting languages in
general, e.g. Javascript or Xbase, are not limited in this way and
hence, and analytic method will not work in the general case.
So, a mechanism for delegates to support re-evaluation of expressions
only when necessary, cannot rely on this technique. Instead, I think it
is more realistic to rely on a delegate's possibility for recording the
actual reading of features. Both approaches where expressions are
interpreted and where expressions are translated to Java can support this.
>> It's the callers
>> responsibility to attach the listeners, based on the recorded
>> dependencies.
>
> The listening part sounds like something else that can be handled in a
> generic way.
Yes, given the dependencies (object/feature pairs), a fairly simple and
generic class can implement the adapter role (that listens) and notifier
role that tells when one of the relevant changes have occurred. (JS4EMF
has such a class).
Hallvard
|
|
| |
| Re: EMF delegates and databinding [message #718726 is a reply to message #718695] |
Thu, 25 August 2011 07:09 |
| Eclipse User |
|
|
|
Originally posted by:
On 25.08.11 06.58, Ed Willink wrote:
>
>> 2) I believe the approach works for OCL, because OCL has certain
>> limitations that make the analysis tractable. Scripting languages in
>> general, e.g. Javascript or Xbase, are not limited in this way and
>> hence, and analytic method will not work in the general case.
>
> Thanks for reminding me. I was beginning to wonder why I struggle to
> support OCL.
>
> Beauty is perhaps in the eye of the beholder.
>
> Being side-effect free and declarative is a fundamental design intent of
> OCL; hardly a limitation. And when you want to analyze your programs
> these characteristics support you. Java is very familiar and flexible,
> but ultimately, like assembler, too much flexibility limits what can be
> achieved.
We need different languages for different purposes and OCL does its job
well! I'm lecturing about model-based software development including
constraints and OCL the coming weeks and will mention this case.
Hallvard
|
|
|
Goto Forum:
Current Time: Wed Apr 24 14:15:03 GMT 2024
Powered by FUDForum. Page generated in 0.03060 seconds |
] 
Search
Help
Register
Login
Home
