Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » registering a time provider
registering a time provider [message #104984] Wed, 19 December 2007 19:45 Go to next message
Jean-Claude Cote is currently offline Jean-Claude CoteFriend
Messages: 56
Registered: July 2009
Member
Hi,

I'm working on an EMFT project called Temporality. This project focuses on
keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not hard
code access to the current time like this System.currentMilliseconds() but
rather hide access to the current time behind an interface and provide a way
to plug different time provider implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would be
to give developers a way to plug the implemenation of an interface. Can I
register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
...
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
...
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude
Re: registering a time provider [message #104987 is a reply to message #104984] Wed, 19 December 2007 20:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that
in turn provides the time (much like how an editing domain is associated
with the resource set). Then anyone can adapt it as they see fit...

jc wrote:
> Hi,
>
> I'm working on an EMFT project called Temporality. This project focuses on
> keeping a historical record of the state of modeled instances.
>
> A central concept of this feature is the current date. I'd rather not hard
> code access to the current time like this System.currentMilliseconds() but
> rather hide access to the current time behind an interface and provide a way
> to plug different time provider implementations.
>
> That way I could have a testing time provider and a runtime etc.
>
> What is the best way to plug this type of provider in EMF? The idea would be
> to give developers a way to plug the implemenation of an interface. Can I
> register such a class in an EPackage?
>
> interface TemporalDate {
> setNow(Date d);
> Date now();
> boolean areEqual(Date a, Date b, int granularity);
> }
>
> class RuntimeTemporalDate{
> ...
> Date now(){
> return new Date(System.currentMili);
> }
>
> }
>
> class DebugTemporalDate{
> Date now;
> ...
> void setNow(Date d){
> now = d;
> }
> }
>
> Thanks
> Jean-Claude
>
>
>
>
Re: registering a time provider [message #105003 is a reply to message #104987] Thu, 20 December 2007 19:55 Go to previous messageGo to next message
Jean-Claude Cote is currently offline Jean-Claude CoteFriend
Messages: 56
Registered: July 2009
Member
Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?

Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fkbu5i$1ha$1@build.eclipse.org...
> Jean-Claude,
>
> I probably don't understand the overall design well enough to give sound
> advice. It seems to me likely that things (operations on the model
> instances) will be running in some type of context and that this context
> would provide the time. Of course time changes as time passes, so it's
> likely that such a context would describe a delta between the "virtual"
> time (the time the context intends the operations to be interpreted
> against) and the actual time on the process'/machine's clock. Perhaps a
> resource set would have an adapter that would provide the context that in
> turn provides the time (much like how an editing domain is associated with
> the resource set). Then anyone can adapt it as they see fit...
>
> jc wrote:
>> Hi,
>>
>> I'm working on an EMFT project called Temporality. This project focuses
>> on keeping a historical record of the state of modeled instances.
>>
>> A central concept of this feature is the current date. I'd rather not
>> hard code access to the current time like this
>> System.currentMilliseconds() but rather hide access to the current time
>> behind an interface and provide a way to plug different time provider
>> implementations.
>>
>> That way I could have a testing time provider and a runtime etc.
>>
>> What is the best way to plug this type of provider in EMF? The idea would
>> be to give developers a way to plug the implemenation of an interface.
>> Can I register such a class in an EPackage?
>>
>> interface TemporalDate {
>> setNow(Date d);
>> Date now();
>> boolean areEqual(Date a, Date b, int granularity);
>> }
>>
>> class RuntimeTemporalDate{
>> ...
>> Date now(){
>> return new Date(System.currentMili);
>> }
>>
>> }
>>
>> class DebugTemporalDate{
>> Date now;
>> ...
>> void setNow(Date d){
>> now = d;
>> }
>> }
>>
>> Thanks
>> Jean-Claude
>>
>>
>>
>>
Re: registering a time provider [message #105004 is a reply to message #105003] Thu, 20 December 2007 20:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------060102070000050802070908
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jean-Claude,

Although I don't know why you want to provide the time via adapters to
single objects I have an idea for objects without resource set: You
could attach the adapter to resources and objects as well and if you
query the time provider for an object you could walk up the containment
tree until you find an adapter with the provider. I hope I don't say
non-sense ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


jc schrieb:
> Ed,
>
> If I understand correct you would suggest to create an adapter factory that
> adds a getNow() behavior to the EObjects.
>
> I would then register this factory with the resource set. Using the
> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
> provide me with the single adapter that provides the getNow() functionality.
>
> I like the idea of registering with the resource set. As you say this would
> enable anyone the ability to override this behavior.
>
> Is there a way to register adapter factories with resource sets by using
> extention points?
>
> Also one issue I have is that it does force my EObjects to be in a resource
> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>
> Thanks
> Jean-Claude
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fkbu5i$1ha$1@build.eclipse.org...
>
>> Jean-Claude,
>>
>> I probably don't understand the overall design well enough to give sound
>> advice. It seems to me likely that things (operations on the model
>> instances) will be running in some type of context and that this context
>> would provide the time. Of course time changes as time passes, so it's
>> likely that such a context would describe a delta between the "virtual"
>> time (the time the context intends the operations to be interpreted
>> against) and the actual time on the process'/machine's clock. Perhaps a
>> resource set would have an adapter that would provide the context that in
>> turn provides the time (much like how an editing domain is associated with
>> the resource set). Then anyone can adapt it as they see fit...
>>
>> jc wrote:
>>
>>> Hi,
>>>
>>> I'm working on an EMFT project called Temporality. This project focuses
>>> on keeping a historical record of the state of modeled instances.
>>>
>>> A central concept of this feature is the current date. I'd rather not
>>> hard code access to the current time like this
>>> System.currentMilliseconds() but rather hide access to the current time
>>> behind an interface and provide a way to plug different time provider
>>> implementations.
>>>
>>> That way I could have a testing time provider and a runtime etc.
>>>
>>> What is the best way to plug this type of provider in EMF? The idea would
>>> be to give developers a way to plug the implemenation of an interface.
>>> Can I register such a class in an EPackage?
>>>
>>> interface TemporalDate {
>>> setNow(Date d);
>>> Date now();
>>> boolean areEqual(Date a, Date b, int granularity);
>>> }
>>>
>>> class RuntimeTemporalDate{
>>> ...
>>> Date now(){
>>> return new Date(System.currentMili);
>>> }
>>>
>>> }
>>>
>>> class DebugTemporalDate{
>>> Date now;
>>> ...
>>> void setNow(Date d){
>>> now = d;
>>> }
>>> }
>>>
>>> Thanks
>>> Jean-Claude
>>>
>>>
>>>
>>>
>>>
>
>
>

--------------060102070000050802070908
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Jean-Claude,<br>
<br>
Although I don't know why you want to provide the time via adapters to
single objects I have an idea for objects without resource set: You
could attach the adapter to resources and objects as well and if you
query the time provider for an object you could walk up the containment
tree until you find an adapter with the provider. I hope I don't say
non-sense ;-)<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?

Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that in
turn provides the time (much like how an editing domain is associated with
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'm working on an EMFT project called Temporality. This project focuses
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not
hard code access to the current time like this
System.currentMilliseconds() but rather hide access to the current time
behind an interface and provide a way to plug different time provider
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would
be to give developers a way to plug the implemenation of an interface.
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude




</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------060102070000050802070908--
Re: registering a time provider [message #105006 is a reply to message #105003] Thu, 20 December 2007 22:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------090304050004010900080401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jean-Claude,

Comments below.

jc wrote:
> Ed,
>
> If I understand correct you would suggest to create an adapter factory that
> adds a getNow() behavior to the EObjects.
>
I was more thinking it would be on the resource set itself. The
resource set is also a Notifier and can also have adapters. Here's an
example of how we determine the editing domain for an EObject (in
AdapterFactoryEditingDomain):

static public EditingDomain getEditingDomainFor(EObject object)
{
Resource resource = object.eResource();
if (resource != null)
{
IEditingDomainProvider editingDomainProvider =

(IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc e,
IEditingDomainProvider.class);
if (editingDomainProvider != null)
{
return editingDomainProvider.getEditingDomain();
}
else
{
ResourceSet resourceSet = resource.getResourceSet();
if (resourceSet instanceof IEditingDomainProvider)
{
EditingDomain editingDomain =
((IEditingDomainProvider)resourceSet).getEditingDomain();
return editingDomain;
}
else if (resourceSet != null)
{
editingDomainProvider =
(IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc eSet,
IEditingDomainProvider.class);
if (editingDomainProvider != null)
{
return editingDomainProvider.getEditingDomain();
}
}
}
}

return null;
}


> I would then register this factory with the resource set. Using the
> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
> provide me with the single adapter that provides the getNow() functionality.
>
> I like the idea of registering with the resource set. As you say this would
> enable anyone the ability to override this behavior.
>
> Is there a way to register adapter factories with resource sets by using
> extention points?
>
No. I could imagine having a static method like the one above for
getting the time. If it fails to find an adapter on the resource or the
resource set, it could just use the system time...
> Also one issue I have is that it does force my EObjects to be in a resource
> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>
Yes, that's true. I'm not sure it so good to require the object itself
to hold the adapter (since once there is an adapter, changes will fire
notifications and that definitely affects performance). Expecting the
adapter on the resource or the resource set itself is perhaps better...
> Thanks
> Jean-Claude
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fkbu5i$1ha$1@build.eclipse.org...
>
>> Jean-Claude,
>>
>> I probably don't understand the overall design well enough to give sound
>> advice. It seems to me likely that things (operations on the model
>> instances) will be running in some type of context and that this context
>> would provide the time. Of course time changes as time passes, so it's
>> likely that such a context would describe a delta between the "virtual"
>> time (the time the context intends the operations to be interpreted
>> against) and the actual time on the process'/machine's clock. Perhaps a
>> resource set would have an adapter that would provide the context that in
>> turn provides the time (much like how an editing domain is associated with
>> the resource set). Then anyone can adapt it as they see fit...
>>
>> jc wrote:
>>
>>> Hi,
>>>
>>> I'm working on an EMFT project called Temporality. This project focuses
>>> on keeping a historical record of the state of modeled instances.
>>>
>>> A central concept of this feature is the current date. I'd rather not
>>> hard code access to the current time like this
>>> System.currentMilliseconds() but rather hide access to the current time
>>> behind an interface and provide a way to plug different time provider
>>> implementations.
>>>
>>> That way I could have a testing time provider and a runtime etc.
>>>
>>> What is the best way to plug this type of provider in EMF? The idea would
>>> be to give developers a way to plug the implemenation of an interface.
>>> Can I register such a class in an EPackage?
>>>
>>> interface TemporalDate {
>>> setNow(Date d);
>>> Date now();
>>> boolean areEqual(Date a, Date b, int granularity);
>>> }
>>>
>>> class RuntimeTemporalDate{
>>> ...
>>> Date now(){
>>> return new Date(System.currentMili);
>>> }
>>>
>>> }
>>>
>>> class DebugTemporalDate{
>>> Date now;
>>> ...
>>> void setNow(Date d){
>>> now = d;
>>> }
>>> }
>>>
>>> Thanks
>>> Jean-Claude
>>>
>>>
>>>
>>>
>>>
>
>
>


--------------090304050004010900080401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jean-Claude,<br>
<br>
Comments below.<br>
<br>
jc wrote:
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.
</pre>
</blockquote>
I was more thinking it would be on the resource set itself.&nbsp; The
resource set is also a Notifier and can also have adapters.&nbsp; Here's an
example of how we determine the editing domain for an EObject (in
AdapterFactoryEditingDomain):<br>
<br>
<blockquote><small>&nbsp; static public EditingDomain
getEditingDomainFor(EObject object)<br>
&nbsp; {<br>
&nbsp;&nbsp;&nbsp; Resource resource = object.eResource();<br>
&nbsp;&nbsp;&nbsp; if (resource != null)<br>
&nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IEditingDomainProvider editingDomainProvider =<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; (IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc e,
IEditingDomainProvider.class);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (editingDomainProvider != null)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; return editingDomainProvider.getEditingDomain();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ResourceSet resourceSet = resource.getResourceSet();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; if (resourceSet instanceof IEditingDomainProvider)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; EditingDomain editingDomain =
((IEditingDomainProvider)resourceSet).getEditingDomain();<br >
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return editingDomain;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; else if (resourceSet != null)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; editingDomainProvider =
(IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc eSet,
IEditingDomainProvider.class);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (editingDomainProvider != null)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return editingDomainProvider.getEditingDomain();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp; }<br>
<br>
&nbsp;&nbsp;&nbsp; return null;<br>
&nbsp; }</small><br>
</blockquote>
<br>
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?
</pre>
</blockquote>
No.&nbsp; I could imagine having a static method like the one above for
getting the time.&nbsp; If it fails to find an adapter on the resource or
the resource set, it could just use the system time...<br>
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">
Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
</pre>
</blockquote>
Yes, that's true.&nbsp; I'm not sure it so good to require the object itself
to hold the adapter (since once there is an adapter, changes will fire
notifications and that definitely affects performance).&nbsp; Expecting the
adapter on the resource or the resource set itself is perhaps better...<br>
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks
Jean-Claude



"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that in
turn provides the time (much like how an editing domain is associated with
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'm working on an EMFT project called Temporality. This project focuses
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not
hard code access to the current time like this
System.currentMilliseconds() but rather hide access to the current time
behind an interface and provide a way to plug different time provider
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would
be to give developers a way to plug the implemenation of an interface.
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude




</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------090304050004010900080401--
Re: registering a time provider [message #105007 is a reply to message #105004] Thu, 20 December 2007 22:19 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------020807000000040409060505
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Yes, I was thinking that would be the most flexible of all, i.e., check
the object, then the parent, until you get to the resource, then check
it, and finally the resource set. It's also relatively expensive to do
all this checking up the containment hierarchy, which is why I didn't
suggest it. I suppose an alternative would be to get the root object
(EcoreUtil.getRoot) and check it, then the resource and the resource set...


Eike Stepper wrote:
> Hi Jean-Claude,
>
> Although I don't know why you want to provide the time via adapters to
> single objects I have an idea for objects without resource set: You
> could attach the adapter to resources and objects as well and if you
> query the time provider for an object you could walk up the
> containment tree until you find an adapter with the provider. I hope I
> don't say non-sense ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
> jc schrieb:
>> Ed,
>>
>> If I understand correct you would suggest to create an adapter factory that
>> adds a getNow() behavior to the EObjects.
>>
>> I would then register this factory with the resource set. Using the
>> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
>> provide me with the single adapter that provides the getNow() functionality.
>>
>> I like the idea of registering with the resource set. As you say this would
>> enable anyone the ability to override this behavior.
>>
>> Is there a way to register adapter factories with resource sets by using
>> extention points?
>>
>> Also one issue I have is that it does force my EObjects to be in a resource
>> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>>
>> Thanks
>> Jean-Claude
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:fkbu5i$1ha$1@build.eclipse.org...
>>
>>> Jean-Claude,
>>>
>>> I probably don't understand the overall design well enough to give sound
>>> advice. It seems to me likely that things (operations on the model
>>> instances) will be running in some type of context and that this context
>>> would provide the time. Of course time changes as time passes, so it's
>>> likely that such a context would describe a delta between the "virtual"
>>> time (the time the context intends the operations to be interpreted
>>> against) and the actual time on the process'/machine's clock. Perhaps a
>>> resource set would have an adapter that would provide the context that in
>>> turn provides the time (much like how an editing domain is associated with
>>> the resource set). Then anyone can adapt it as they see fit...
>>>
>>> jc wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm working on an EMFT project called Temporality. This project focuses
>>>> on keeping a historical record of the state of modeled instances.
>>>>
>>>> A central concept of this feature is the current date. I'd rather not
>>>> hard code access to the current time like this
>>>> System.currentMilliseconds() but rather hide access to the current time
>>>> behind an interface and provide a way to plug different time provider
>>>> implementations.
>>>>
>>>> That way I could have a testing time provider and a runtime etc.
>>>>
>>>> What is the best way to plug this type of provider in EMF? The idea would
>>>> be to give developers a way to plug the implemenation of an interface.
>>>> Can I register such a class in an EPackage?
>>>>
>>>> interface TemporalDate {
>>>> setNow(Date d);
>>>> Date now();
>>>> boolean areEqual(Date a, Date b, int granularity);
>>>> }
>>>>
>>>> class RuntimeTemporalDate{
>>>> ....
>>>> Date now(){
>>>> return new Date(System.currentMili);
>>>> }
>>>>
>>>> }
>>>>
>>>> class DebugTemporalDate{
>>>> Date now;
>>>> ....
>>>> void setNow(Date d){
>>>> now = d;
>>>> }
>>>> }
>>>>
>>>> Thanks
>>>> Jean-Claude
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>


--------------020807000000040409060505
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Yes, I was thinking that would be the most flexible of all,
Re: registering a time provider [message #105009 is a reply to message #105003] Fri, 21 December 2007 05:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------070309050704000500020202
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Jean-Claude,

I remember that I commented on your proposal in the emft-dev list. Have
you already had the time to read these comments?

One of them seems a bit related to the question of where to attach your
time provider. The more objects are given the possibility to have their
own time (different from others) the more you introduce the possibility
to navigate an inconsistent object graph. Depending on your requirements
I suggest that you only attach one time provider to a whole resource
set. IMHO this is the only ay to make inter-resource cross references
consistently navigable.

I'd like to offer you again that we discuss how I solved the same issues
for my CDO technology (also EMFT). Among other things CDO also offers
support for time travelling through arbitrary object graphs and it could
eventually be possible that we were able to factor out a common
framework for cross-cutting model concerns like transparent versioning,
transparent persistence and the like.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



jc schrieb:
> Ed,
>
> If I understand correct you would suggest to create an adapter factory that
> adds a getNow() behavior to the EObjects.
>
> I would then register this factory with the resource set. Using the
> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
> provide me with the single adapter that provides the getNow() functionality.
>
> I like the idea of registering with the resource set. As you say this would
> enable anyone the ability to override this behavior.
>
> Is there a way to register adapter factories with resource sets by using
> extention points?
>
> Also one issue I have is that it does force my EObjects to be in a resource
> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>
> Thanks
> Jean-Claude
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fkbu5i$1ha$1@build.eclipse.org...
>
>> Jean-Claude,
>>
>> I probably don't understand the overall design well enough to give sound
>> advice. It seems to me likely that things (operations on the model
>> instances) will be running in some type of context and that this context
>> would provide the time. Of course time changes as time passes, so it's
>> likely that such a context would describe a delta between the "virtual"
>> time (the time the context intends the operations to be interpreted
>> against) and the actual time on the process'/machine's clock. Perhaps a
>> resource set would have an adapter that would provide the context that in
>> turn provides the time (much like how an editing domain is associated with
>> the resource set). Then anyone can adapt it as they see fit...
>>
>> jc wrote:
>>
>>> Hi,
>>>
>>> I'm working on an EMFT project called Temporality. This project focuses
>>> on keeping a historical record of the state of modeled instances.
>>>
>>> A central concept of this feature is the current date. I'd rather not
>>> hard code access to the current time like this
>>> System.currentMilliseconds() but rather hide access to the current time
>>> behind an interface and provide a way to plug different time provider
>>> implementations.
>>>
>>> That way I could have a testing time provider and a runtime etc.
>>>
>>> What is the best way to plug this type of provider in EMF? The idea would
>>> be to give developers a way to plug the implemenation of an interface.
>>> Can I register such a class in an EPackage?
>>>
>>> interface TemporalDate {
>>> setNow(Date d);
>>> Date now();
>>> boolean areEqual(Date a, Date b, int granularity);
>>> }
>>>
>>> class RuntimeTemporalDate{
>>> ...
>>> Date now(){
>>> return new Date(System.currentMili);
>>> }
>>>
>>> }
>>>
>>> class DebugTemporalDate{
>>> Date now;
>>> ...
>>> void setNow(Date d){
>>> now = d;
>>> }
>>> }
>>>
>>> Thanks
>>> Jean-Claude
>>>
>>>
>>>
>>>
>>>
>
>
>

--------------070309050704000500020202
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jean-Claude,<br>
<br>
I remember that I commented on your proposal in the emft-dev list. Have
you already had the time to read these comments? <br>
<br>
One of them seems a bit related to the question of where to attach your
time provider. The more objects are given the possibility to have their
own time (different from others) the more you introduce the possibility
to navigate an inconsistent object graph. Depending on your
requirements I suggest that you only attach one time provider to a
whole resource set. IMHO this is the only ay to make inter-resource
cross references consistently navigable.<br>
<br>
I'd like to offer you again that we discuss how I solved the same
issues for my CDO technology (also EMFT). Among other things CDO also
offers support for time travelling through arbitrary object graphs and
it could eventually be possible that we were able to factor out a
common framework for cross-cutting model concerns like transparent
versioning, transparent persistence and the like.<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?

Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that in
turn provides the time (much like how an editing domain is associated with
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'm working on an EMFT project called Temporality. This project focuses
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not
hard code access to the current time like this
System.currentMilliseconds() but rather hide access to the current time
behind an interface and provide a way to plug different time provider
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would
be to give developers a way to plug the implemenation of an interface.
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude




</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------070309050704000500020202--
Re: registering a time provider [message #105012 is a reply to message #105009] Fri, 21 December 2007 13:59 Go to previous message
Jean-Claude Cote is currently offline Jean-Claude CoteFriend
Messages: 56
Registered: July 2009
Member
This is a multi-part message in MIME format.

------=_NextPart_000_0042_01C843AF.C1925670
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Eike,

Yes I want to only support one TimeProvider for all objects. But I want =
developers to be able to inject custom TimeProviders if only for =
testing.

So basically I want the concept of a registry where the temporality =
subsystem can retrieve the TimeProvider object from and where developers =
can put custom TimeProviers.

I understand the idea that the ResourceSet holds on to such a registry =
however I would like it if it where possible to use a registry even when =
the objects are not in a ResourceSet or there are no ResourceSet created =
yet.

There will be only one TimeProvider I just want a nice EMF friendly way =
to access it.

Thanks
jc
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fkfj1u$l9j$1@build.eclipse.org...
Jean-Claude,

I remember that I commented on your proposal in the emft-dev list. =
Have you already had the time to read these comments?=20

One of them seems a bit related to the question of where to attach =
your time provider. The more objects are given the possibility to have =
their own time (different from others) the more you introduce the =
possibility to navigate an inconsistent object graph. Depending on your =
requirements I suggest that you only attach one time provider to a whole =
resource set. IMHO this is the only ay to make inter-resource cross =
references consistently navigable.

I'd like to offer you again that we discuss how I solved the same =
issues for my CDO technology (also EMFT). Among other things CDO also =
offers support for time travelling through arbitrary object graphs and =
it could eventually be possible that we were able to factor out a common =
framework for cross-cutting model concerns like transparent versioning, =
transparent persistence and the like.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



jc schrieb:=20
Ed,

If I understand correct you would suggest to create an adapter factory =
that=20
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the=20
EcoreUtil.getRegisteredAdapter() method I could get this factory which =
would=20
provide me with the single adapter that provides the getNow() =
functionality.

I like the idea of registering with the resource set. As you say this =
would=20
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using =

extention points?

Also one issue I have is that it does force my EObjects to be in a =
resource=20
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:fkbu5i$1ha$1@build.eclipse.org...
Jean-Claude,

I probably don't understand the overall design well enough to give sound =

advice. It seems to me likely that things (operations on the model=20
instances) will be running in some type of context and that this context =

would provide the time. Of course time changes as time passes, so it's=20
likely that such a context would describe a delta between the "virtual"=20
time (the time the context intends the operations to be interpreted=20
against) and the actual time on the process'/machine's clock. Perhaps a =

resource set would have an adapter that would provide the context that =
in=20
turn provides the time (much like how an editing domain is associated =
with=20
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
Hi,

I'm working on an EMFT project called Temporality. This project focuses=20
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not=20
hard code access to the current time like this=20
System.currentMilliseconds() but rather hide access to the current time=20
behind an interface and provide a way to plug different time provider=20
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea =
would=20
be to give developers a way to plug the implemenation of an interface.=20
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now =3D d;
}
}

Thanks
Jean-Claude




=20


------=_NextPart_000_0042_01C843AF.C1925670
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>
<DIV>Eike,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes I want to only support one TimeProvider for all objects. But I =
want=20
developers to be able to inject custom TimeProviders if only for =
testing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So basically I want the concept of a registry where the temporality =

subsystem can retrieve the TimeProvider object from and where developers =
can put=20
custom TimeProviers.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I understand the idea that the ResourceSet holds on to such a =
registry=20
however I would like it if it where possible to use a registry even when =
the=20
objects are not in a ResourceSet or there are no ResourceSet created =
yet.</DIV>
<DIV>&nbsp;</DIV>
<DIV>There will be only one TimeProvider I just want a nice EMF friendly =
way to=20
access it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks</DIV>
<DIV>jc</DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" &lt;<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>&gt; wrote =
in message=20
<A=20
=
href=3D"news:fkfj1u$l9j$1@build.eclipse.org">news:fkfj1u$l9j$1@build.ecli=
pse.org</A>...</DIV>Jean-Claude,<BR><BR>I=20
remember that I commented on your proposal in the emft-dev list. Have =
you=20
already had the time to read these comments? <BR><BR>One of them seems =
a bit=20
related to the question of where to attach your time provider. The =
more=20
objects are given the possibility to have their own time (different =
from=20
others) the more you introduce the possibility to navigate an =
inconsistent=20
object graph. Depending on your requirements I suggest that you only =
attach=20
one time provider to a whole resource set. IMHO this is the only ay to =
make=20
inter-resource cross references consistently navigable.<BR><BR>I'd =
like to=20
offer you again that we discuss how I solved the same issues for my =
CDO=20
technology (also EMFT). Among other things CDO also offers support for =
time=20
travelling through arbitrary object graphs and it could eventually be =
possible=20
that we were able to factor out a common framework for cross-cutting =
model=20
concerns like transparent versioning, transparent persistence and the=20
like.<BR><BR>Regards,<BR>Eike Stepper<BR>----<BR><A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</A><BR><=
A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</A><=
BR><BR><BR><BR>jc=20
schrieb:=20
<BLOCKQUOTE cite=3Dmid:fkehao$a93$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ed,

If I understand correct you would suggest to create an adapter factory =
that=20
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the=20
EcoreUtil.getRegisteredAdapter() method I could get this factory which =
would=20
provide me with the single adapter that provides the getNow() =
functionality.

I like the idea of registering with the resource set. As you say this =
would=20
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using =

extention points?

Also one issue I have is that it does force my EObjects to be in a =
resource=20
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Jean-Claude,

I probably don't understand the overall design well enough to give sound =

advice. It seems to me likely that things (operations on the model=20
instances) will be running in some type of context and that this context =

would provide the time. Of course time changes as time passes, so it's=20
likely that such a context would describe a delta between the "virtual"=20
time (the time the context intends the operations to be interpreted=20
against) and the actual time on the process'/machine's clock. Perhaps a =

resource set would have an adapter that would provide the context that =
in=20
turn provides the time (much like how an editing domain is associated =
with=20
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,

I'm working on an EMFT project called Temporality. This project focuses=20
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not=20
hard code access to the current time like this=20
System.currentMilliseconds() but rather hide access to the current time=20
behind an interface and provide a way to plug different time provider=20
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea =
would=20
be to give developers a way to plug the implemenation of an interface.=20
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now =3D d;
}
}

Thanks
Jean-Claude




</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0042_01C843AF.C1925670--
Re: registering a time provider [message #612914 is a reply to message #104984] Wed, 19 December 2007 20:15 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31478
Registered: July 2009
Senior Member
Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that
in turn provides the time (much like how an editing domain is associated
with the resource set). Then anyone can adapt it as they see fit...

jc wrote:
> Hi,
>
> I'm working on an EMFT project called Temporality. This project focuses on
> keeping a historical record of the state of modeled instances.
>
> A central concept of this feature is the current date. I'd rather not hard
> code access to the current time like this System.currentMilliseconds() but
> rather hide access to the current time behind an interface and provide a way
> to plug different time provider implementations.
>
> That way I could have a testing time provider and a runtime etc.
>
> What is the best way to plug this type of provider in EMF? The idea would be
> to give developers a way to plug the implemenation of an interface. Can I
> register such a class in an EPackage?
>
> interface TemporalDate {
> setNow(Date d);
> Date now();
> boolean areEqual(Date a, Date b, int granularity);
> }
>
> class RuntimeTemporalDate{
> ...
> Date now(){
> return new Date(System.currentMili);
> }
>
> }
>
> class DebugTemporalDate{
> Date now;
> ...
> void setNow(Date d){
> now = d;
> }
> }
>
> Thanks
> Jean-Claude
>
>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: registering a time provider [message #612930 is a reply to message #104987] Thu, 20 December 2007 19:55 Go to previous message
Jean-Claude Cote is currently offline Jean-Claude CoteFriend
Messages: 56
Registered: July 2009
Member
Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?

Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fkbu5i$1ha$1@build.eclipse.org...
> Jean-Claude,
>
> I probably don't understand the overall design well enough to give sound
> advice. It seems to me likely that things (operations on the model
> instances) will be running in some type of context and that this context
> would provide the time. Of course time changes as time passes, so it's
> likely that such a context would describe a delta between the "virtual"
> time (the time the context intends the operations to be interpreted
> against) and the actual time on the process'/machine's clock. Perhaps a
> resource set would have an adapter that would provide the context that in
> turn provides the time (much like how an editing domain is associated with
> the resource set). Then anyone can adapt it as they see fit...
>
> jc wrote:
>> Hi,
>>
>> I'm working on an EMFT project called Temporality. This project focuses
>> on keeping a historical record of the state of modeled instances.
>>
>> A central concept of this feature is the current date. I'd rather not
>> hard code access to the current time like this
>> System.currentMilliseconds() but rather hide access to the current time
>> behind an interface and provide a way to plug different time provider
>> implementations.
>>
>> That way I could have a testing time provider and a runtime etc.
>>
>> What is the best way to plug this type of provider in EMF? The idea would
>> be to give developers a way to plug the implemenation of an interface.
>> Can I register such a class in an EPackage?
>>
>> interface TemporalDate {
>> setNow(Date d);
>> Date now();
>> boolean areEqual(Date a, Date b, int granularity);
>> }
>>
>> class RuntimeTemporalDate{
>> ...
>> Date now(){
>> return new Date(System.currentMili);
>> }
>>
>> }
>>
>> class DebugTemporalDate{
>> Date now;
>> ...
>> void setNow(Date d){
>> now = d;
>> }
>> }
>>
>> Thanks
>> Jean-Claude
>>
>>
>>
>>
Re: registering a time provider [message #612932 is a reply to message #105003] Thu, 20 December 2007 20:20 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6506
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060102070000050802070908
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jean-Claude,

Although I don't know why you want to provide the time via adapters to
single objects I have an idea for objects without resource set: You
could attach the adapter to resources and objects as well and if you
query the time provider for an object you could walk up the containment
tree until you find an adapter with the provider. I hope I don't say
non-sense ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


jc schrieb:
> Ed,
>
> If I understand correct you would suggest to create an adapter factory that
> adds a getNow() behavior to the EObjects.
>
> I would then register this factory with the resource set. Using the
> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
> provide me with the single adapter that provides the getNow() functionality.
>
> I like the idea of registering with the resource set. As you say this would
> enable anyone the ability to override this behavior.
>
> Is there a way to register adapter factories with resource sets by using
> extention points?
>
> Also one issue I have is that it does force my EObjects to be in a resource
> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>
> Thanks
> Jean-Claude
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fkbu5i$1ha$1@build.eclipse.org...
>
>> Jean-Claude,
>>
>> I probably don't understand the overall design well enough to give sound
>> advice. It seems to me likely that things (operations on the model
>> instances) will be running in some type of context and that this context
>> would provide the time. Of course time changes as time passes, so it's
>> likely that such a context would describe a delta between the "virtual"
>> time (the time the context intends the operations to be interpreted
>> against) and the actual time on the process'/machine's clock. Perhaps a
>> resource set would have an adapter that would provide the context that in
>> turn provides the time (much like how an editing domain is associated with
>> the resource set). Then anyone can adapt it as they see fit...
>>
>> jc wrote:
>>
>>> Hi,
>>>
>>> I'm working on an EMFT project called Temporality. This project focuses
>>> on keeping a historical record of the state of modeled instances.
>>>
>>> A central concept of this feature is the current date. I'd rather not
>>> hard code access to the current time like this
>>> System.currentMilliseconds() but rather hide access to the current time
>>> behind an interface and provide a way to plug different time provider
>>> implementations.
>>>
>>> That way I could have a testing time provider and a runtime etc.
>>>
>>> What is the best way to plug this type of provider in EMF? The idea would
>>> be to give developers a way to plug the implemenation of an interface.
>>> Can I register such a class in an EPackage?
>>>
>>> interface TemporalDate {
>>> setNow(Date d);
>>> Date now();
>>> boolean areEqual(Date a, Date b, int granularity);
>>> }
>>>
>>> class RuntimeTemporalDate{
>>> ...
>>> Date now(){
>>> return new Date(System.currentMili);
>>> }
>>>
>>> }
>>>
>>> class DebugTemporalDate{
>>> Date now;
>>> ...
>>> void setNow(Date d){
>>> now = d;
>>> }
>>> }
>>>
>>> Thanks
>>> Jean-Claude
>>>
>>>
>>>
>>>
>>>
>
>
>

--------------060102070000050802070908
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Jean-Claude,<br>
<br>
Although I don't know why you want to provide the time via adapters to
single objects I have an idea for objects without resource set: You
could attach the adapter to resources and objects as well and if you
query the time provider for an object you could walk up the containment
tree until you find an adapter with the provider. I hope I don't say
non-sense ;-)<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?

Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that in
turn provides the time (much like how an editing domain is associated with
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'm working on an EMFT project called Temporality. This project focuses
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not
hard code access to the current time like this
System.currentMilliseconds() but rather hide access to the current time
behind an interface and provide a way to plug different time provider
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would
be to give developers a way to plug the implemenation of an interface.
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude




</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------060102070000050802070908--


Re: registering a time provider [message #612936 is a reply to message #105003] Thu, 20 December 2007 22:16 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31478
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090304050004010900080401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jean-Claude,

Comments below.

jc wrote:
> Ed,
>
> If I understand correct you would suggest to create an adapter factory that
> adds a getNow() behavior to the EObjects.
>
I was more thinking it would be on the resource set itself. The
resource set is also a Notifier and can also have adapters. Here's an
example of how we determine the editing domain for an EObject (in
AdapterFactoryEditingDomain):

static public EditingDomain getEditingDomainFor(EObject object)
{
Resource resource = object.eResource();
if (resource != null)
{
IEditingDomainProvider editingDomainProvider =

(IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc e,
IEditingDomainProvider.class);
if (editingDomainProvider != null)
{
return editingDomainProvider.getEditingDomain();
}
else
{
ResourceSet resourceSet = resource.getResourceSet();
if (resourceSet instanceof IEditingDomainProvider)
{
EditingDomain editingDomain =
((IEditingDomainProvider)resourceSet).getEditingDomain();
return editingDomain;
}
else if (resourceSet != null)
{
editingDomainProvider =
(IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc eSet,
IEditingDomainProvider.class);
if (editingDomainProvider != null)
{
return editingDomainProvider.getEditingDomain();
}
}
}
}

return null;
}


> I would then register this factory with the resource set. Using the
> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
> provide me with the single adapter that provides the getNow() functionality.
>
> I like the idea of registering with the resource set. As you say this would
> enable anyone the ability to override this behavior.
>
> Is there a way to register adapter factories with resource sets by using
> extention points?
>
No. I could imagine having a static method like the one above for
getting the time. If it fails to find an adapter on the resource or the
resource set, it could just use the system time...
> Also one issue I have is that it does force my EObjects to be in a resource
> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>
Yes, that's true. I'm not sure it so good to require the object itself
to hold the adapter (since once there is an adapter, changes will fire
notifications and that definitely affects performance). Expecting the
adapter on the resource or the resource set itself is perhaps better...
> Thanks
> Jean-Claude
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fkbu5i$1ha$1@build.eclipse.org...
>
>> Jean-Claude,
>>
>> I probably don't understand the overall design well enough to give sound
>> advice. It seems to me likely that things (operations on the model
>> instances) will be running in some type of context and that this context
>> would provide the time. Of course time changes as time passes, so it's
>> likely that such a context would describe a delta between the "virtual"
>> time (the time the context intends the operations to be interpreted
>> against) and the actual time on the process'/machine's clock. Perhaps a
>> resource set would have an adapter that would provide the context that in
>> turn provides the time (much like how an editing domain is associated with
>> the resource set). Then anyone can adapt it as they see fit...
>>
>> jc wrote:
>>
>>> Hi,
>>>
>>> I'm working on an EMFT project called Temporality. This project focuses
>>> on keeping a historical record of the state of modeled instances.
>>>
>>> A central concept of this feature is the current date. I'd rather not
>>> hard code access to the current time like this
>>> System.currentMilliseconds() but rather hide access to the current time
>>> behind an interface and provide a way to plug different time provider
>>> implementations.
>>>
>>> That way I could have a testing time provider and a runtime etc.
>>>
>>> What is the best way to plug this type of provider in EMF? The idea would
>>> be to give developers a way to plug the implemenation of an interface.
>>> Can I register such a class in an EPackage?
>>>
>>> interface TemporalDate {
>>> setNow(Date d);
>>> Date now();
>>> boolean areEqual(Date a, Date b, int granularity);
>>> }
>>>
>>> class RuntimeTemporalDate{
>>> ...
>>> Date now(){
>>> return new Date(System.currentMili);
>>> }
>>>
>>> }
>>>
>>> class DebugTemporalDate{
>>> Date now;
>>> ...
>>> void setNow(Date d){
>>> now = d;
>>> }
>>> }
>>>
>>> Thanks
>>> Jean-Claude
>>>
>>>
>>>
>>>
>>>
>
>
>


--------------090304050004010900080401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jean-Claude,<br>
<br>
Comments below.<br>
<br>
jc wrote:
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.
</pre>
</blockquote>
I was more thinking it would be on the resource set itself.&nbsp; The
resource set is also a Notifier and can also have adapters.&nbsp; Here's an
example of how we determine the editing domain for an EObject (in
AdapterFactoryEditingDomain):<br>
<br>
<blockquote><small>&nbsp; static public EditingDomain
getEditingDomainFor(EObject object)<br>
&nbsp; {<br>
&nbsp;&nbsp;&nbsp; Resource resource = object.eResource();<br>
&nbsp;&nbsp;&nbsp; if (resource != null)<br>
&nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IEditingDomainProvider editingDomainProvider =<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; (IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc e,
IEditingDomainProvider.class);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (editingDomainProvider != null)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; return editingDomainProvider.getEditingDomain();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ResourceSet resourceSet = resource.getResourceSet();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; if (resourceSet instanceof IEditingDomainProvider)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; EditingDomain editingDomain =
((IEditingDomainProvider)resourceSet).getEditingDomain();<br >
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; return editingDomain;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; else if (resourceSet != null)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; editingDomainProvider =
(IEditingDomainProvider)EcoreUtil.getExistingAdapter(resourc eSet,
IEditingDomainProvider.class);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (editingDomainProvider != null)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return editingDomainProvider.getEditingDomain();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp; }<br>
<br>
&nbsp;&nbsp;&nbsp; return null;<br>
&nbsp; }</small><br>
</blockquote>
<br>
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?
</pre>
</blockquote>
No.&nbsp; I could imagine having a static method like the one above for
getting the time.&nbsp; If it fails to find an adapter on the resource or
the resource set, it could just use the system time...<br>
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">
Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
</pre>
</blockquote>
Yes, that's true.&nbsp; I'm not sure it so good to require the object itself
to hold the adapter (since once there is an adapter, changes will fire
notifications and that definitely affects performance).&nbsp; Expecting the
adapter on the resource or the resource set itself is perhaps better...<br>
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks
Jean-Claude



"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that in
turn provides the time (much like how an editing domain is associated with
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'm working on an EMFT project called Temporality. This project focuses
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not
hard code access to the current time like this
System.currentMilliseconds() but rather hide access to the current time
behind an interface and provide a way to plug different time provider
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would
be to give developers a way to plug the implemenation of an interface.
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude




</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
<br>
</body>
</html>

--------------090304050004010900080401--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: registering a time provider [message #612938 is a reply to message #105004] Thu, 20 December 2007 22:19 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31478
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020807000000040409060505
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Eike,

Yes, I was thinking that would be the most flexible of all, i.e., check
the object, then the parent, until you get to the resource, then check
it, and finally the resource set. It's also relatively expensive to do
all this checking up the containment hierarchy, which is why I didn't
suggest it. I suppose an alternative would be to get the root object
(EcoreUtil.getRoot) and check it, then the resource and the resource set...


Eike Stepper wrote:
> Hi Jean-Claude,
>
> Although I don't know why you want to provide the time via adapters to
> single objects I have an idea for objects without resource set: You
> could attach the adapter to resources and objects as well and if you
> query the time provider for an object you could walk up the
> containment tree until you find an adapter with the provider. I hope I
> don't say non-sense ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
> jc schrieb:
>> Ed,
>>
>> If I understand correct you would suggest to create an adapter factory that
>> adds a getNow() behavior to the EObjects.
>>
>> I would then register this factory with the resource set. Using the
>> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
>> provide me with the single adapter that provides the getNow() functionality.
>>
>> I like the idea of registering with the resource set. As you say this would
>> enable anyone the ability to override this behavior.
>>
>> Is there a way to register adapter factories with resource sets by using
>> extention points?
>>
>> Also one issue I have is that it does force my EObjects to be in a resource
>> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>>
>> Thanks
>> Jean-Claude
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:fkbu5i$1ha$1@build.eclipse.org...
>>
>>> Jean-Claude,
>>>
>>> I probably don't understand the overall design well enough to give sound
>>> advice. It seems to me likely that things (operations on the model
>>> instances) will be running in some type of context and that this context
>>> would provide the time. Of course time changes as time passes, so it's
>>> likely that such a context would describe a delta between the "virtual"
>>> time (the time the context intends the operations to be interpreted
>>> against) and the actual time on the process'/machine's clock. Perhaps a
>>> resource set would have an adapter that would provide the context that in
>>> turn provides the time (much like how an editing domain is associated with
>>> the resource set). Then anyone can adapt it as they see fit...
>>>
>>> jc wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm working on an EMFT project called Temporality. This project focuses
>>>> on keeping a historical record of the state of modeled instances.
>>>>
>>>> A central concept of this feature is the current date. I'd rather not
>>>> hard code access to the current time like this
>>>> System.currentMilliseconds() but rather hide access to the current time
>>>> behind an interface and provide a way to plug different time provider
>>>> implementations.
>>>>
>>>> That way I could have a testing time provider and a runtime etc.
>>>>
>>>> What is the best way to plug this type of provider in EMF? The idea would
>>>> be to give developers a way to plug the implemenation of an interface.
>>>> Can I register such a class in an EPackage?
>>>>
>>>> interface TemporalDate {
>>>> setNow(Date d);
>>>> Date now();
>>>> boolean areEqual(Date a, Date b, int granularity);
>>>> }
>>>>
>>>> class RuntimeTemporalDate{
>>>> ....
>>>> Date now(){
>>>> return new Date(System.currentMili);
>>>> }
>>>>
>>>> }
>>>>
>>>> class DebugTemporalDate{
>>>> Date now;
>>>> ....
>>>> void setNow(Date d){
>>>> now = d;
>>>> }
>>>> }
>>>>
>>>> Thanks
>>>> Jean-Claude
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>


--------------020807000000040409060505
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Yes, I was thinking that would be the most flexible of all,


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: registering a time provider [message #612943 is a reply to message #105003] Fri, 21 December 2007 05:30 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6506
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070309050704000500020202
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Jean-Claude,

I remember that I commented on your proposal in the emft-dev list. Have
you already had the time to read these comments?

One of them seems a bit related to the question of where to attach your
time provider. The more objects are given the possibility to have their
own time (different from others) the more you introduce the possibility
to navigate an inconsistent object graph. Depending on your requirements
I suggest that you only attach one time provider to a whole resource
set. IMHO this is the only ay to make inter-resource cross references
consistently navigable.

I'd like to offer you again that we discuss how I solved the same issues
for my CDO technology (also EMFT). Among other things CDO also offers
support for time travelling through arbitrary object graphs and it could
eventually be possible that we were able to factor out a common
framework for cross-cutting model concerns like transparent versioning,
transparent persistence and the like.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



jc schrieb:
> Ed,
>
> If I understand correct you would suggest to create an adapter factory that
> adds a getNow() behavior to the EObjects.
>
> I would then register this factory with the resource set. Using the
> EcoreUtil.getRegisteredAdapter() method I could get this factory which would
> provide me with the single adapter that provides the getNow() functionality.
>
> I like the idea of registering with the resource set. As you say this would
> enable anyone the ability to override this behavior.
>
> Is there a way to register adapter factories with resource sets by using
> extention points?
>
> Also one issue I have is that it does force my EObjects to be in a resource
> in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?
>
> Thanks
> Jean-Claude
>
>
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fkbu5i$1ha$1@build.eclipse.org...
>
>> Jean-Claude,
>>
>> I probably don't understand the overall design well enough to give sound
>> advice. It seems to me likely that things (operations on the model
>> instances) will be running in some type of context and that this context
>> would provide the time. Of course time changes as time passes, so it's
>> likely that such a context would describe a delta between the "virtual"
>> time (the time the context intends the operations to be interpreted
>> against) and the actual time on the process'/machine's clock. Perhaps a
>> resource set would have an adapter that would provide the context that in
>> turn provides the time (much like how an editing domain is associated with
>> the resource set). Then anyone can adapt it as they see fit...
>>
>> jc wrote:
>>
>>> Hi,
>>>
>>> I'm working on an EMFT project called Temporality. This project focuses
>>> on keeping a historical record of the state of modeled instances.
>>>
>>> A central concept of this feature is the current date. I'd rather not
>>> hard code access to the current time like this
>>> System.currentMilliseconds() but rather hide access to the current time
>>> behind an interface and provide a way to plug different time provider
>>> implementations.
>>>
>>> That way I could have a testing time provider and a runtime etc.
>>>
>>> What is the best way to plug this type of provider in EMF? The idea would
>>> be to give developers a way to plug the implemenation of an interface.
>>> Can I register such a class in an EPackage?
>>>
>>> interface TemporalDate {
>>> setNow(Date d);
>>> Date now();
>>> boolean areEqual(Date a, Date b, int granularity);
>>> }
>>>
>>> class RuntimeTemporalDate{
>>> ...
>>> Date now(){
>>> return new Date(System.currentMili);
>>> }
>>>
>>> }
>>>
>>> class DebugTemporalDate{
>>> Date now;
>>> ...
>>> void setNow(Date d){
>>> now = d;
>>> }
>>> }
>>>
>>> Thanks
>>> Jean-Claude
>>>
>>>
>>>
>>>
>>>
>
>
>

--------------070309050704000500020202
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jean-Claude,<br>
<br>
I remember that I commented on your proposal in the emft-dev list. Have
you already had the time to read these comments? <br>
<br>
One of them seems a bit related to the question of where to attach your
time provider. The more objects are given the possibility to have their
own time (different from others) the more you introduce the possibility
to navigate an inconsistent object graph. Depending on your
requirements I suggest that you only attach one time provider to a
whole resource set. IMHO this is the only ay to make inter-resource
cross references consistently navigable.<br>
<br>
I'd like to offer you again that we discuss how I solved the same
issues for my CDO technology (also EMFT). Among other things CDO also
offers support for time travelling through arbitrary object graphs and
it could eventually be possible that we were able to factor out a
common framework for cross-cutting model concerns like transparent
versioning, transparent persistence and the like.<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
<br>
jc schrieb:
<blockquote cite="mid:fkehao$a93$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,

If I understand correct you would suggest to create an adapter factory that
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the
EcoreUtil.getRegisteredAdapter() method I could get this factory which would
provide me with the single adapter that provides the getNow() functionality.

I like the idea of registering with the resource set. As you say this would
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using
extention points?

Also one issue I have is that it does force my EObjects to be in a resource
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jean-Claude,

I probably don't understand the overall design well enough to give sound
advice. It seems to me likely that things (operations on the model
instances) will be running in some type of context and that this context
would provide the time. Of course time changes as time passes, so it's
likely that such a context would describe a delta between the "virtual"
time (the time the context intends the operations to be interpreted
against) and the actual time on the process'/machine's clock. Perhaps a
resource set would have an adapter that would provide the context that in
turn provides the time (much like how an editing domain is associated with
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'm working on an EMFT project called Temporality. This project focuses
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not
hard code access to the current time like this
System.currentMilliseconds() but rather hide access to the current time
behind an interface and provide a way to plug different time provider
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea would
be to give developers a way to plug the implemenation of an interface.
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now = d;
}
}

Thanks
Jean-Claude




</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------070309050704000500020202--


Re: registering a time provider [message #612949 is a reply to message #105009] Fri, 21 December 2007 13:59 Go to previous message
Jean-Claude Cote is currently offline Jean-Claude CoteFriend
Messages: 56
Registered: July 2009
Member
This is a multi-part message in MIME format.

------=_NextPart_000_0042_01C843AF.C1925670
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Eike,

Yes I want to only support one TimeProvider for all objects. But I want =
developers to be able to inject custom TimeProviders if only for =
testing.

So basically I want the concept of a registry where the temporality =
subsystem can retrieve the TimeProvider object from and where developers =
can put custom TimeProviers.

I understand the idea that the ResourceSet holds on to such a registry =
however I would like it if it where possible to use a registry even when =
the objects are not in a ResourceSet or there are no ResourceSet created =
yet.

There will be only one TimeProvider I just want a nice EMF friendly way =
to access it.

Thanks
jc
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fkfj1u$l9j$1@build.eclipse.org...
Jean-Claude,

I remember that I commented on your proposal in the emft-dev list. =
Have you already had the time to read these comments?=20

One of them seems a bit related to the question of where to attach =
your time provider. The more objects are given the possibility to have =
their own time (different from others) the more you introduce the =
possibility to navigate an inconsistent object graph. Depending on your =
requirements I suggest that you only attach one time provider to a whole =
resource set. IMHO this is the only ay to make inter-resource cross =
references consistently navigable.

I'd like to offer you again that we discuss how I solved the same =
issues for my CDO technology (also EMFT). Among other things CDO also =
offers support for time travelling through arbitrary object graphs and =
it could eventually be possible that we were able to factor out a common =
framework for cross-cutting model concerns like transparent versioning, =
transparent persistence and the like.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



jc schrieb:=20
Ed,

If I understand correct you would suggest to create an adapter factory =
that=20
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the=20
EcoreUtil.getRegisteredAdapter() method I could get this factory which =
would=20
provide me with the single adapter that provides the getNow() =
functionality.

I like the idea of registering with the resource set. As you say this =
would=20
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using =

extention points?

Also one issue I have is that it does force my EObjects to be in a =
resource=20
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:fkbu5i$1ha$1@build.eclipse.org...
Jean-Claude,

I probably don't understand the overall design well enough to give sound =

advice. It seems to me likely that things (operations on the model=20
instances) will be running in some type of context and that this context =

would provide the time. Of course time changes as time passes, so it's=20
likely that such a context would describe a delta between the "virtual"=20
time (the time the context intends the operations to be interpreted=20
against) and the actual time on the process'/machine's clock. Perhaps a =

resource set would have an adapter that would provide the context that =
in=20
turn provides the time (much like how an editing domain is associated =
with=20
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
Hi,

I'm working on an EMFT project called Temporality. This project focuses=20
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not=20
hard code access to the current time like this=20
System.currentMilliseconds() but rather hide access to the current time=20
behind an interface and provide a way to plug different time provider=20
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea =
would=20
be to give developers a way to plug the implemenation of an interface.=20
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now =3D d;
}
}

Thanks
Jean-Claude




=20


------=_NextPart_000_0042_01C843AF.C1925670
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>
<DIV>Eike,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes I want to only support one TimeProvider for all objects. But I =
want=20
developers to be able to inject custom TimeProviders if only for =
testing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So basically I want the concept of a registry where the temporality =

subsystem can retrieve the TimeProvider object from and where developers =
can put=20
custom TimeProviers.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I understand the idea that the ResourceSet holds on to such a =
registry=20
however I would like it if it where possible to use a registry even when =
the=20
objects are not in a ResourceSet or there are no ResourceSet created =
yet.</DIV>
<DIV>&nbsp;</DIV>
<DIV>There will be only one TimeProvider I just want a nice EMF friendly =
way to=20
access it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks</DIV>
<DIV>jc</DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" &lt;<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>&gt; wrote =
in message=20
<A=20
=
href=3D"news:fkfj1u$l9j$1@build.eclipse.org">news:fkfj1u$l9j$1@build.ecli=
pse.org</A>...</DIV>Jean-Claude,<BR><BR>I=20
remember that I commented on your proposal in the emft-dev list. Have =
you=20
already had the time to read these comments? <BR><BR>One of them seems =
a bit=20
related to the question of where to attach your time provider. The =
more=20
objects are given the possibility to have their own time (different =
from=20
others) the more you introduce the possibility to navigate an =
inconsistent=20
object graph. Depending on your requirements I suggest that you only =
attach=20
one time provider to a whole resource set. IMHO this is the only ay to =
make=20
inter-resource cross references consistently navigable.<BR><BR>I'd =
like to=20
offer you again that we discuss how I solved the same issues for my =
CDO=20
technology (also EMFT). Among other things CDO also offers support for =
time=20
travelling through arbitrary object graphs and it could eventually be =
possible=20
that we were able to factor out a common framework for cross-cutting =
model=20
concerns like transparent versioning, transparent persistence and the=20
like.<BR><BR>Regards,<BR>Eike Stepper<BR>----<BR><A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</A><BR><=
A=20
class=3Dmoz-txt-link-freetext=20
=
href=3D"http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</A><=
BR><BR><BR><BR>jc=20
schrieb:=20
<BLOCKQUOTE cite=3Dmid:fkehao$a93$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ed,

If I understand correct you would suggest to create an adapter factory =
that=20
adds a getNow() behavior to the EObjects.

I would then register this factory with the resource set. Using the=20
EcoreUtil.getRegisteredAdapter() method I could get this factory which =
would=20
provide me with the single adapter that provides the getNow() =
functionality.

I like the idea of registering with the resource set. As you say this =
would=20
enable anyone the ability to override this behavior.

Is there a way to register adapter factories with resource sets by using =

extention points?

Also one issue I have is that it does force my EObjects to be in a =
resource=20
in order for the EcoreUtil.getRegisteredAdapter() to work. Correct?

Thanks
Jean-Claude



"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:merks@ca.ibm.com">&lt;merks@ca.ibm.com&gt;</A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:fkbu5i$1ha$1@build.eclipse.org">news:fkbu5i$1ha$1@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Jean-Claude,

I probably don't understand the overall design well enough to give sound =

advice. It seems to me likely that things (operations on the model=20
instances) will be running in some type of context and that this context =

would provide the time. Of course time changes as time passes, so it's=20
likely that such a context would describe a delta between the "virtual"=20
time (the time the context intends the operations to be interpreted=20
against) and the actual time on the process'/machine's clock. Perhaps a =

resource set would have an adapter that would provide the context that =
in=20
turn provides the time (much like how an editing domain is associated =
with=20
the resource set). Then anyone can adapt it as they see fit...

jc wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,

I'm working on an EMFT project called Temporality. This project focuses=20
on keeping a historical record of the state of modeled instances.

A central concept of this feature is the current date. I'd rather not=20
hard code access to the current time like this=20
System.currentMilliseconds() but rather hide access to the current time=20
behind an interface and provide a way to plug different time provider=20
implementations.

That way I could have a testing time provider and a runtime etc.

What is the best way to plug this type of provider in EMF? The idea =
would=20
be to give developers a way to plug the implemenation of an interface.=20
Can I register such a class in an EPackage?

interface TemporalDate {
setNow(Date d);
Date now();
boolean areEqual(Date a, Date b, int granularity);
}

class RuntimeTemporalDate{
....
Date now(){
return new Date(System.currentMili);
}

}

class DebugTemporalDate{
Date now;
....
void setNow(Date d){
now =3D d;
}
}

Thanks
Jean-Claude




</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0042_01C843AF.C1925670--
Previous Topic:[CDO][0.8.0] TypeManager
Next Topic:[Temporality] Temporality design
Goto Forum:
  


Current Time: Thu Sep 24 06:10:58 GMT 2020

Powered by FUDForum. Page generated in 0.02160 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top