Home » Modeling » EMF » [cdo] update ui on model change with cdoState = PROXY
|
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419928 is a reply to message #419925] |
Fri, 13 June 2008 13:35   |
|
Hi Cristi,
Comments below...
Cristi Angheluta schrieb:
> I've set up a cdo server with 2 acceptors tcp and jvm; storage in memory.
> A jvm client opens a transaction and modifies a model stored in
> server's memory. Another tcp client loads the model and displays in a
> widget with jface/emf databinding.
>
> Every time model changes on server, the tcp client receives an
> invalidation event at session level, that sets cdoState to PROXY.
Yes, this is correct. The server distributes remote invalidation
notifications that lead to object state being set to PROXY. The next
access (getter or setter call) to these objects will trigger a load
request from teh client.
> Anyway, I'm not able to refresh my widget with databinding. With a
> manual refresh everything is ok but looks like a "load on demand"
> operation.
In addition to the demand loading of remotely invalidated objects you
could add an IListener to the CDOSession that reacts to
CDOSessionInvalidationEvents. I recomment that you have a look at the
CDOEditor and the CDOEventHandler. I have no experience so far with the
EMF data binding but I guess the process should be something like:
- recognize CDOSessionInvalidationEvent
- pull out the dirtyCDOIDs (be careful, latest CDO uses CDOIDAndVersion
instead of only CDOID!)
- CDOObject object = view.getObject(dirtyID.getID(), false);
- if (object != null) object.cdoReload() (or just call any
getter or setter)
Note that the CDOObjects usually don't emit EMF change notifications on
remote invalidations/reloads!
If EMF databinding relies on such notifications you could try to call
view.setInvalidationNotificationsEnabled(true) to make the CDOObjects
emit special EMF notifications:
public interface CDOInvalidationNotification extends Notification
{
public static final int INVALIDATE = EVENT_TYPE_COUNT + 1;
}
Maybe this can be useful to make CDO remote invalidation visible at once
with EMF data binding.
I'd be very interested in your experiences in case you manage ;-)
Maybe you are willing to write a small report under
http://wiki.eclipse.org/User_Contributed_CDO_Documentation ...
> Can anybody point me to the right direction to find a way to
> automatically refresh the model? ... or how to reload objects with a
> dirty CDOID (gathered with a IListener on CDOSession)?
> Do I have to change the CDOFetchRuleManager instance in
> CDORevisionManagerImpl?
No, this one is more for gathering/managing rules that govern active
prefetching of objects ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419940 is a reply to message #419928] |
Fri, 13 June 2008 16:21 |
 Cristi Angheluta
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
------------J7p0pB26FPICbqtp5IvCd7
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi Eike,
My cdosession listener was calling
CDOStateMachine.INSTANCE.reload((InternalCDOObject) object) on every dirty
CDOObject instead of cdoObject.cdoReload(). Changing to what you suggest
does not solve my issue. (CDOIDAndVersion is not available ... I'm working
with CDO 1.0.0RC3 (I guess))
Enabling tracing for my cdo client showed the log in my attached
trace-1.txt
It's seems that it does not really reload my object and does not sets
clean state on my object. Now, a call to my refresh button (extracts the
value from cdoObject) showed the log captured in trace-2.txt. As you can
see it explicitly sets clean state on my object.
Setting view.setInvalidationNotificationsEnabled(true) indeed called an
Adapter that was previously attached to my observed object. The event is
of type CDOInvalidationNotificationImpl. Even with this event nothing
happened in my widget. My model needs more than an invalidation event ...
damn it! ;-) why? why?
I desperately set myCdoObject.eSetDeliver(true) just to capture a
modification event on my model.
Does reloading/setting the value of an cdoObject's feature notify EMF
listeners?
I've forgot to mention that I've just touched the EMF land ... so I'm a
real newbie.
Contributing to wiki whould be a nice thing but ... my english is so poor.
--
___________________________________________
Cristi Angheluta
Software Engineer
Bucharest Stock Exchange
34-36 Carol I Boulevard, 13th Floor
Bucharest, 020922, Romania
Mobile: +40-742-033-771
Phone: +40-21-3079512/166
Fax: +40-21-3079519
email: undisclosed@nomail.net
___________________________________________
"A minute to learn, a lifetime to master."
------------J7p0pB26FPICbqtp5IvCd7
Content-Disposition: attachment; filename=trace-1.txt
Content-Type: text/plain; name=trace-1.txt
Content-Transfer-Encoding: 7bit
PSelector [debug] Reading java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036]
TCPSelector [debug.buffer] Obtained Buffer@10
TCPSelector [debug.buffer] Read 27 bytes (EOS)
00 00 00 01 00 0e 00 00 01 1a 7d 7b 45 4d 00 00 00 01 01 00 00 00 00 00 00 00 02
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@10 --> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 1
ReceiveSerializer0 [debug.signal] Got signal id 14
Thread-3 [debug.signal] ================ Indicating InvalidationIndication
Thread-3 [debug.protocol] Read timeStamp: 13.06.2008 18:21:54
Thread-3 [debug.protocol] Reading 1 IDs
Thread-3 [debug.model] Reading CDOID of type 1 (OBJECT)
Thread-3 [debug.buffer] Retaining Buffer@10
Thread-3 [debug.object] INVALIDATE: ro.bvb.river.model.impl.XConnectionImpl
Thread-3 [debug] Processing event INVALIDATE in state CLEAN for XConnection@OID2 (data=1.213.370.514.098)
Thread-3 [debug.revision] Setting revised XConnection@OID2v34: 13.06.2008 18:21:54
Thread-3 [debug.object] Setting state PROXY for XConnection@OID2
Thread-3 [debug.signal] ================ Requesting VerifyRevisionRequest
Thread-3 [debug.protocol] Writing 0 IDs and versions
Thread-3 [debug.buffer] Obtained Buffer@10
Thread-3 [debug.buffer.stream] Put signal id 11
Thread-3 [debug.channel] Handling buffer from client: Buffer@10 --> Channel[0]
Thread-3 [debug] Ordering client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = true
TCPSelector [debug] Executing client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036]
TCPSelector [debug.buffer] Writing 10 bytes (EOS)
00 00 00 09 00 0b 00 00 00 00
TCPSelector [debug.buffer] Retaining Buffer@10
TCPSelector [debug] Ordering client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = false
TCPSelector [debug] Executing client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = false
TCPSelector [debug] Setting interest READ (was read|write)
Thread-3 [debug.signal] ================ Confirming VerifyRevisionRequest
Thread-3 [debug.protocol] Reading 0 timeStamps
Thread-3 [debug.object] RELOAD: ro.bvb.river.model.impl.XConnectionImpl
Thread-3 [debug] Processing event RELOAD in state PROXY for XConnection@OID2 (data=null)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036]
TCPSelector [debug.buffer] Obtained Buffer@10
TCPSelector [debug.buffer] Read 4 bytes (EOS)
00 00 00 08
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@10 --> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation -9
ReceiveSerializer0 [debug.signal] Discarding buffer
ReceiveSerializer0 [debug.buffer] Retaining Buffer@10
------------J7p0pB26FPICbqtp5IvCd7
Content-Disposition: attachment; filename=trace-2.txt
Content-Type: text/plain; name=trace-2.txt
Content-Transfer-Encoding: 7bit
main [debug.object] get(ExchangeModel@OID3, CDOFeature(ID=0, name=connection, type=OBJECT, referenceType=CDOClassRef(http:///ro/bvb/river/model, 1)), -1)
main [debug.object] READ: ro.bvb.river.model.impl.ExchangeModelImpl
main [debug.object] get(XConnection@OID2, CDOFeature(ID=0, name=status, type=CUSTOM, referenceType=null), -1)
main [debug.object] READ: ro.bvb.river.model.impl.XConnectionImpl
main [debug] Processing event READ in state PROXY for XConnection@OID2 (data=null)
main [debug.signal] ================ Requesting LoadRevisionRequest
main [debug.protocol] Writing referenceChunk: -1
main [debug.buffer] Obtained Buffer@10
main [debug.buffer.stream] Put signal id 7
main [debug.protocol] Writing 1 IDs
main [debug.protocol] Writing ID: OID2
main [debug.model] Writing CDOID of type 1 (OBJECT)
main [debug.channel] Handling buffer from client: Buffer@10 --> Channel[0]
main [debug] Ordering client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = true
main [debug.signal] ================ Confirming LoadRevisionRequest
TCPSelector [debug] Executing client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = true
main [debug.protocol] Reading 1 revisions
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036]
TCPSelector [debug.buffer] Writing 27 bytes (EOS)
00 00 00 0a 00 07 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 02 00 00 00 00
TCPSelector [debug.buffer] Retaining Buffer@10
TCPSelector [debug] Ordering client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = false
TCPSelector [debug] Executing client operation INTEREST WRITE java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected local=/192.168.250.205:56017 remote=/192.168.250.205:2036]
TCPSelector [debug.buffer] Obtained Buffer@10
TCPSelector [debug.buffer] Read 106 bytes (EOS)
00 00 00 09 01 00 1a 68 74 74 70 3a 2f 2f 2f 72 6f 2f 62 76 62 2f 72 69 76 65 72 2f 6d 6f 64 65 6c 00 00 00 00 01 01 00 00 00 00 00 00 00 02 00 00 00 23 00 00 01 1a 7d 7b 45 4d 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 03 00 00 00 00 01 00 09 43 4f 4e 4e 45 43 54 45 44 00 00 00 00 00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@10 --> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation -10
main [debug.model] Reading CDOID of type 1 (OBJECT)
main [debug.model] Reading CDOID of type 1 (OBJECT)
main [debug.model] Reading CDOID of type 1 (OBJECT)
main [debug.revision] Reading revision: ID=OID2, classRef=CDOClassRef(http:///ro/bvb/river/model, 1), className=XConnection, version=35, created=1.213.370.514.098, revised=0, resource=OID1, container=OID3, feature=-1
main [debug.revision] Read feature CDOFeature(ID=0, name=status, type=CUSTOM, referenceType=null): CONNECTED
main [debug.buffer] Retaining Buffer@10
main [debug.revision] Adding revision: XConnection@OID2v35, created=13.06.2008 18:21:54, revised=01.01.1970 02:00:00, current=true
main [debug.object] Setting revision: XConnection@OID2v35
main [debug.object] Setting state CLEAN for XConnection@OID2
noul status = CONNECTED
main [debug.object] get(XConnection@OID2, CDOFeature(ID=0, name=status, type=CUSTOM, referenceType=null), -1)
main [debug.object] READ: ro.bvb.river.model.impl.XConnectionImpl
------------J7p0pB26FPICbqtp5IvCd7--
|
|
|
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419942 is a reply to message #419940] |
Fri, 13 June 2008 16:30 |
|
Cristi Angheluta schrieb:
> Hi Eike,
>
> My cdosession listener was calling
> CDOStateMachine.INSTANCE.reload((InternalCDOObject) object) on every
> dirty CDOObject instead of cdoObject.cdoReload(). Changing to what you
> suggest does not solve my issue. (CDOIDAndVersion is not available ...
> I'm working with CDO 1.0.0RC3 (I guess))
>
> Enabling tracing for my cdo client showed the log in my attached
> trace-1.txt
>
> It's seems that it does not really reload my object and does not sets
> clean state on my object. Now, a call to my refresh button (extracts
> the value from cdoObject) showed the log captured in trace-2.txt. As
> you can see it explicitly sets clean state on my object.
>
> Setting view.setInvalidationNotificationsEnabled(true) indeed called
> an Adapter that was previously attached to my observed object. The
> event is of type CDOInvalidationNotificationImpl. Even with this event
> nothing happened in my widget. My model needs more than an
> invalidation event ... damn it! ;-) why? why?
My guess is that the EMF bindings require a usual EMF change
notification. The CDOInvalidationNotification is a user defined
notification. Maybe you can discover what code is triggered by the
binding adapters (or whatever they're called in data binding) when a
change notification arrives and do the same now when invalidation
notifications arrive?
>
> I desperately set myCdoObject.eSetDeliver(true) just to capture a
> modification event on my model.
>
> Does reloading/setting the value of an cdoObject's feature notify EMF
> listeners?
I think yes for setting, no for reloading but I'm currently not sure.
>
> I've forgot to mention that I've just touched the EMF land ... so I'm
> a real newbie.
>
> Contributing to wiki whould be a nice thing but ... my english is so
> poor.
That's no excuse ;-)
But first we need to get it working...
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419943 is a reply to message #419933] |
Fri, 13 June 2008 16:41 |
Cristi Angheluta
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Hi Simon,
Comments bellow.
On Fri, 13 Jun 2008 17:21:28 +0300, Simon McDuff <smcduff@hotmail.com>
wrote:
> Just a comments about EMF notifications
> I`m working (for CDO 2.0.0) on a EMF Notification that will give you the
> following:
I want it right now! ;-)
> - Notify Adapters every time a change is done remotely to this specific
> objects (and committed) . You will have access to the feature, the
> delta, etc.
Superb.
> - It is optimized. (Pushing, not polling) It will transfer you (from the
> server to the client) only the data for changes you requested. To
> request
> it.. it is pretty easy. You need to addd an adapter to your EObject you
> want to be notify.
Perfect.
> - You have access to the delta. Maybe at some point you could replicate
the change done remotely!! :-)
That's cool.
> Anyway, here the bugzilla link:
>
> 233490: Change Subscription
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=233490
I added myself to the cc of this "bug". Is this supposed to be a bug or an
improvment? ;-)
> Let me know if you have special requirements !!!
I hardly figured out what's CDO in the last 3 days so I'm not able to
create a requirement right now. Anyway, thank you ... I'll let you know.
> Simon
>
--
___________________________________________
Cristi Angheluta
Software Engineer
Bucharest Stock Exchange
34-36 Carol I Boulevard, 13th Floor
Bucharest, 020922, Romania
Mobile: +40-742-033-771
Phone: +40-21-3079512/166
Fax: +40-21-3079519
email: undisclosed@nomail.net
___________________________________________
"A minute to learn, a lifetime to master."
|
|
| | |
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419969 is a reply to message #419942] |
Mon, 16 June 2008 06:45 |
Cristi Angheluta
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
------------FIIWj4ZE8r3WGml5jBv4pO
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: 7bit
Comments bellow.
On Fri, 13 Jun 2008 19:30:23 +0300, Eike Stepper <stepper@sympedia.de>
wrote:
> Cristi Angheluta schrieb:
>> Hi Eike,
> My guess is that the EMF bindings require a usual EMF change
> notification. The CDOInvalidationNotification is a user defined
> notification. Maybe you can discover what code is triggered by the
> binding adapters (or whatever they're called in data binding) when a
> change notification arrives and do the same now when invalidation
> notifications arrive?
>
Hi Eike,
I discovered what was wrong with my emf databindings. The
org.eclipse.emf.databinding.EObjectObservableValue@firstListenerAdded(),
indeed receives a CDOInvalidationNotification but fails to fireChangeValue
because CDOInvalidationNotification does not have an eFeature attached (is
null).
To whom may be interested I created a subclass (see attachment)
CDOObjectObservableValue, of class EObjectObservableValue, that behaves (I
guess) accordingly to CDO intricacies.
This class can be used as to bind a value to a Label.
<code>
XConnection conn = ... //cdo object
IObservableValue lblv = SWTObservables.observeText(lbl);
//interested in status attribute of conn
IObservableValue emfv = new CDOObjectObservableValue(conn,
YourPackage.Literals.XCONNECTION__STATUS);
DataBindingContext ctx = new EMFDataBindingContext();
ctx.bindValue(lblv, emfv, null, null);
</code>
Cheers,
___________________________________________
Cristi Angheluta
Software Engineer
Bucharest Stock Exchange
34-36 Carol I Boulevard, 13th Floor
Bucharest, 020922, Romania
Mobile: +40-742-033-771
Phone: +40-21-3079512/166
Fax: +40-21-3079519
email: undisclosed@nomail.net
___________________________________________
"A minute to learn, a lifetime to master."
------------FIIWj4ZE8r3WGml5jBv4pO
Content-Disposition: attachment; filename=CDOObjectObservableValue.java
Content-Type: application/octet-stream; name=CDOObjectObservableValue.java
Content-Transfer-Encoding: Base64
aW1wb3J0IG9yZy5lY2xpcHNlLmNvcmUuZGF0YWJpbmRpbmcub2JzZXJ2YWJs ZS5E
aWZmczsNCmltcG9ydCBvcmcuZWNsaXBzZS5jb3JlLmRhdGFiaW5kaW5nLm9i c2Vy
dmFibGUuUmVhbG07DQppbXBvcnQgb3JnLmVjbGlwc2UuY29yZS5kYXRhYmlu ZGlu
Zy5vYnNlcnZhYmxlLnZhbHVlLklPYnNlcnZhYmxlVmFsdWU7DQppbXBvcnQg b3Jn
LmVjbGlwc2UuY29yZS5kYXRhYmluZGluZy5vYnNlcnZhYmxlLnZhbHVlLlZh bHVl
RGlmZjsNCmltcG9ydCBvcmcuZWNsaXBzZS5lbWYuY2RvLkNET0ludmFsaWRh dGlv
bk5vdGlmaWNhdGlvbjsNCmltcG9ydCBvcmcuZWNsaXBzZS5lbWYuY2RvLkNE T09i
amVjdDsNCmltcG9ydCBvcmcuZWNsaXBzZS5lbWYuY29tbW9uLm5vdGlmeS5O b3Rp
ZmljYXRpb247DQppbXBvcnQgb3JnLmVjbGlwc2UuZW1mLmNvbW1vbi5ub3Rp Znku
aW1wbC5BZGFwdGVySW1wbDsNCmltcG9ydCBvcmcuZWNsaXBzZS5lbWYuZGF0 YWJp
bmRpbmcuRU9iamVjdE9ic2VydmFibGVWYWx1ZTsNCmltcG9ydCBvcmcuZWNs aXBz
ZS5lbWYuZWNvcmUuRU9iamVjdDsNCmltcG9ydCBvcmcuZWNsaXBzZS5lbWYu ZWNv
cmUuRVN0cnVjdHVyYWxGZWF0dXJlOw0KDQpwdWJsaWMgY2xhc3MgQ0RPT2Jq ZWN0
T2JzZXJ2YWJsZVZhbHVlIGV4dGVuZHMgRU9iamVjdE9ic2VydmFibGVWYWx1 ZSB7
DQogICAgLyoqDQogICAgICogVGhlIG9sZCB2YWx1ZSB0aGF0IGNhbiBiZSBm b3Vu
ZCBpbiBvYnNlcnZlZCB2YWx1ZSBhdCBzcGVjaWZpZWQge0BsaW5rIEVTdHJ1 Y3R1
cmFsRmVhdHVyZX0NCiAgICAgKi8NCiAgICBwcml2YXRlIE9iamVjdCBvbGRW YWx1
ZTsNCiAgICANCiAgICAvKioNCiAgICAgKiBDcmVhdGVzIGFuIHtAbGluayBJ T2Jz
ZXJ2YWJsZVZhbHVlfQ0KICAgICAqIA0KICAgICAqIEBwYXJhbSBjZG9PYmpl Y3QN
CiAgICAgKiAgICAgICAgICAgIHRoZSBjZG8gb2JqZWN0IHRvIGJlIG9ic2Vy dmVk
DQogICAgICogQHBhcmFtIGVTdHJ1Y3R1cmFsRmVhdHVyZQ0KICAgICAqICAg ICAg
ICAgICAgaW50ZXJlc3RlZCBpbiBjaGFuZ2VzIG9mIHRoaXMge0BsaW5rIEVT dHJ1
Y3R1cmFsRmVhdHVyZX0NCiAgICAgKi8NCiAgICBwdWJsaWMgQ0RPT2JqZWN0 T2Jz
ZXJ2YWJsZVZhbHVlKENET09iamVjdCBjZG9PYmplY3QsIEVTdHJ1Y3R1cmFs RmVh
dHVyZSBlU3RydWN0dXJhbEZlYXR1cmUpIHsNCiAgICAgICAgdGhpcyhSZWFs bS5n
ZXREZWZhdWx0KCksIGNkb09iamVjdCwgZVN0cnVjdHVyYWxGZWF0dXJlKTsN CiAg
ICAgICAgdGhpcy5vbGRWYWx1ZSA9IHN1cGVyLmRvR2V0VmFsdWUoKTsNCiAg ICB9
DQogICAgDQogICAgcHVibGljIENET09iamVjdE9ic2VydmFibGVWYWx1ZShS ZWFs
bSByZWFsbSwgRU9iamVjdCBlT2JqZWN0LCBFU3RydWN0dXJhbEZlYXR1cmUg ZVN0
cnVjdHVyYWxGZWF0dXJlKSB7DQogICAgICAgIHN1cGVyKHJlYWxtLCBlT2Jq ZWN0
LCBlU3RydWN0dXJhbEZlYXR1cmUpOw0KICAgIH0NCiAgICANCiAgICBwcm90 ZWN0
ZWQgc3luY2hyb25pemVkIE9iamVjdCBnZXRBbmRTZXRPbGRWYWx1ZShPYmpl Y3Qg
bmV3VmFsdWUyU2V0QXNPbGRWYWx1ZSkgew0KICAgICAgICBPYmplY3Qgb1Zh bHVl
ID0gb2xkVmFsdWU7DQogICAgICAgIA0KICAgICAgICB0aGlzLm9sZFZhbHVl ID0g
bmV3VmFsdWUyU2V0QXNPbGRWYWx1ZTsNCiAgICAgICAgDQogICAgICAgIHJl dHVy
biBvVmFsdWU7DQogICAgfQ0KICAgIA0KICAgIC8qKg0KICAgICAqIEBzZWUg b3Jn
LmVjbGlwc2UuZW1mLmRhdGFiaW5kaW5nLkVPYmplY3RPYnNlcnZhYmxlVmFs dWUj
Z2V0T2JzZXJ2ZWQoKQ0KICAgICAqLw0KICAgIEBPdmVycmlkZQ0KICAgIHB1 Ymxp
YyBDRE9PYmplY3QgZ2V0T2JzZXJ2ZWQoKSB7DQogICAgICAgIHJldHVybiAo Q0RP
T2JqZWN0KSBzdXBlci5nZXRPYnNlcnZlZCgpOw0KICAgIH0NCiAgICANCiAg ICBA
T3ZlcnJpZGUNCiAgICBwcm90ZWN0ZWQgdm9pZCBmaXJzdExpc3RlbmVyQWRk ZWQo
KSB7DQogICAgICAgIGxpc3RlbmVyID0gbmV3IEFkYXB0ZXJJbXBsKCkgew0K ICAg
ICAgICAgICAgQE92ZXJyaWRlDQogICAgICAgICAgICBwdWJsaWMgdm9pZCBu b3Rp
ZnlDaGFuZ2VkKE5vdGlmaWNhdGlvbiBub3RpZmljYXRpb24pIHsNCiAgICAg ICAg
ICAgICAgICBpZiAobm90aWZpY2F0aW9uIGluc3RhbmNlb2YgQ0RPSW52YWxp ZGF0
aW9uTm90aWZpY2F0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAmJiBu b3Rp
ZmljYXRpb24uZ2V0Tm90aWZpZXIoKSBpbnN0YW5jZW9mIENET09iamVjdCkg ew0K
ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgQ0RP SW52
YWxpZGF0aW9uTm90aWZpY2F0aW9uIGludmFsaWRhdGlvbk5vdGlmaWNhdGlv biA9
IChDRE9JbnZhbGlkYXRpb25Ob3RpZmljYXRpb24pIG5vdGlmaWNhdGlvbjsN CiAg
ICAgICAgICAgICAgICAgICAgQ0RPT2JqZWN0IG5vdGlmaWVyID0gKENET09i amVj
dCkgaW52YWxpZGF0aW9uTm90aWZpY2F0aW9uLmdldE5vdGlmaWVyKCk7DQog ICAg
ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBpZiAoZ2V0 T2Jz
ZXJ2ZWQoKS5jZG9JRCgpLmVxdWFscyhub3RpZmllci5jZG9JRCgpKSAmJiAh aW52
YWxpZGF0aW9uTm90aWZpY2F0aW9uLmlzVG91Y2goKSkgew0KICAgICAgICAg ICAg
ICAgICAgICAgICAgLyoNCiAgICAgICAgICAgICAgICAgICAgICAgICAqIEZl dGNo
ZXMgdGhlIG5ldyB2YWx1ZSBpZiBQUk9YWS4gDQogICAgICAgICAgICAgICAg ICAg
ICAgICAgKi8NCiAgICAgICAgICAgICAgICAgICAgICAgIE9iamVjdCBuZXdW YWx1
ZSA9IG5vdGlmaWVyLmVHZXQoZVN0cnVjdHVyYWxGZWF0dXJlKTsNCiAgICAg ICAg
ICAgICAgICAgICAgICAgIE9iamVjdCBvVmFsdWUgPSBnZXRBbmRTZXRPbGRW YWx1
ZShuZXdWYWx1ZSk7DQogICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAg
ICAgICAgICAgICAgICAgIGZpbmFsIFZhbHVlRGlmZiBkaWZmID0gRGlmZnMu Y3Jl
YXRlVmFsdWVEaWZmKG9WYWx1ZSwgbmV3VmFsdWUpOw0KICAgICAgICAgICAg ICAg
ICAgICAgICAgZ2V0UmVhbG0oKS5leGVjKG5ldyBSdW5uYWJsZSgpIHsNCiAg ICAg
ICAgICAgICAgICAgICAgICAgICAgICBwdWJsaWMgdm9pZCBydW4oKSB7DQog ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZpcmVWYWx1ZUNoYW5nZShk aWZm
KTsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAg
ICAgICAgICAgICB9KTsNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAg ICAg
ICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgfTsNCiAgICAgICAg ZU9i
amVjdC5lQWRhcHRlcnMoKS5hZGQobGlzdGVuZXIpOw0KICAgIH0NCiAgICAN Cn0=
------------FIIWj4ZE8r3WGml5jBv4pO--
|
|
|
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419970 is a reply to message #419969] |
Mon, 16 June 2008 07:00 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
So is it a bug in EMF-Databinding or CDO? We are also going to look into
CDO to add 3-tier support into our EMF&Databinding-Driven RCP applications.
We are currently persisting/loading our models from a database using
iBatis. I see that CDO provides a teneo backend how complex is it to
replace it with an iBatis solution? Another question is how CDO supports
not to load a subgraph of the model on the client.
Tom
Cristi Angheluta schrieb:
> Comments bellow.
>
> On Fri, 13 Jun 2008 19:30:23 +0300, Eike Stepper <stepper@sympedia.de>
> wrote:
>
>> Cristi Angheluta schrieb:
>>> Hi Eike,
>
>> My guess is that the EMF bindings require a usual EMF change
>> notification. The CDOInvalidationNotification is a user defined
>> notification. Maybe you can discover what code is triggered by the
>> binding adapters (or whatever they're called in data binding) when a
>> change notification arrives and do the same now when invalidation
>> notifications arrive?
>>
>
> Hi Eike,
>
> I discovered what was wrong with my emf databindings. The
> org.eclipse.emf.databinding.EObjectObservableValue@firstListenerAdded(),
> indeed receives a CDOInvalidationNotification but fails to
> fireChangeValue because CDOInvalidationNotification does not have an
> eFeature attached (is null).
>
> To whom may be interested I created a subclass (see attachment)
> CDOObjectObservableValue, of class EObjectObservableValue, that behaves
> (I guess) accordingly to CDO intricacies.
>
> This class can be used as to bind a value to a Label.
>
> <code>
> XConnection conn = ... //cdo object
>
> IObservableValue lblv = SWTObservables.observeText(lbl);
> //interested in status attribute of conn
> IObservableValue emfv = new CDOObjectObservableValue(conn,
> YourPackage.Literals.XCONNECTION__STATUS);
>
> DataBindingContext ctx = new EMFDataBindingContext();
> ctx.bindValue(lblv, emfv, null, null);
>
> </code>
>
> Cheers,
> ___________________________________________
>
> Cristi Angheluta
> Software Engineer
>
> Bucharest Stock Exchange
> 34-36 Carol I Boulevard, 13th Floor
> Bucharest, 020922, Romania
>
> Mobile: +40-742-033-771
> Phone: +40-21-3079512/166
> Fax: +40-21-3079519
> email: undisclosed@nomail.net
> ___________________________________________
>
> "A minute to learn, a lifetime to master."
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419972 is a reply to message #419970] |
Mon, 16 June 2008 07:41 |
Cristi Angheluta
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Hi Tom,
1.It's not an EMF bug.
A CDOInvalidationNotification.eFeature() always returns a null value. It
invalidates a entire cdo object.
When I start using cdo with emf databindingg I used an instance of
EObjectObservableValue obtained from an
EMFObservables.observeValue(eobject, eStructuralFeature)
So, in EObjectObservableValue.firstListenerAdded their is an if condition:
"(eStructuralFeature == notification.getFeature() &&
!notification.isTouch())" that it's not met for a
CDOInvalidationNotification => no property change event is fired. Not to
mention that notification.getOldValue() and notification.getNewValue()
throw an UnsupportedOperationException.
I guess to fully support databinding for CDO objects we need a framework
on top of emf databinding to resolve all problems generated by the absence
of the feature involved in an invalidation.
Similar classes that I've posted earlier, on my previous post (as
attachment), has to be written to be used with observed lists, maps etc.
2.Regarding, teneo I cannot advise you at all. I use a "in memory store".
3. The same question I posted on
http://www.eclipse.org/newsportal/article.php?id=32939&g roup=eclipse.tools.emf#32939
regarding not loading a subgraph of server's CDO model.
On Mon, 16 Jun 2008 10:00:00 +0300, Tom Schindl
<tom.schindl@bestsolution.at> wrote:
> So is it a bug in EMF-Databinding or CDO? We are also going to look into
> CDO to add 3-tier support into our EMF&Databinding-Driven RCP
> applications.
>
> We are currently persisting/loading our models from a database using
> iBatis. I see that CDO provides a teneo backend how complex is it to
> replace it with an iBatis solution? Another question is how CDO supports
> not to load a subgraph of the model on the client.
>
> Tom
Regards,
___________________________________________
Cristi Angheluta
Software Engineer
Bucharest Stock Exchange
34-36 Carol I Boulevard, 13th Floor
Bucharest, 020922, Romania
Mobile: +40-742-033-771
Phone: +40-21-3079512/166
Fax: +40-21-3079519
email: undisclosed@nomail.net
___________________________________________
"A minute to learn, a lifetime to master."
|
|
|
| Re: [cdo] update ui on model change with cdoState = PROXY [message #419975 is a reply to message #419970] |
Mon, 16 June 2008 08:20 |
|
Hi Tom,
Comments below...
Tom Schindl schrieb:
> So is it a bug in EMF-Databinding or CDO? We are also going to look
> into CDO to add 3-tier support into our EMF&Databinding-Driven RCP
> applications.
No, I don't think that it's a bug in either technology. It's more a
mismatch of expactations ;-)
The CDOInvalidationNotification is not a usual EMF change notification
with particular eFeature, oldValue, newValue, etc. being set.
It is, as Cristi already realized, just a hint from the repository that
something in an object has changed (i.e. the version of the object has
been increased).
Consider that all these remote invalidations are sent over the network
and the repository does even not know if the client knows about a
particular object at all.
That's why I decided to only transfer CDOID+version instead of whole
commit-replicas over the wire. It's like a compromise between
information interest and bandwidth usage.
I believe that there are two intermediary solutions (until Simon comes
up with https://bugs.eclipse.org/233490):
1) Convert a CDOInvalidationNotification into multiple EMF change
notifications for *all* features of the respective class (without
knowing which particular features have changed).
2) On arrival of a CDOInvalidationNotification reload the object and
analyze the changes to the previous version and generate correct EMF
change notifications.
>
> We are currently persisting/loading our models from a database using
> iBatis. I see that CDO provides a teneo backend how complex is it to
> replace it with an iBatis solution?
Hard to say exactly ;-)
But given that you have excellent iBatis know-how and we have excellent
CDO know-how, we could work together like Martin and I did for the
Hibernate integration.
> Another question is how CDO supports not to load a subgraph of the
> model on the client.
In CDO containment association (in both directions) are loaded lazily.
There are some optimizations (all optional) to prefetch certain numbers
of contained objects but in general *all* objects are loaded (and
unloaded!) in isolation.
Cheers
/Eike
>
> Tom
>
> Cristi Angheluta schrieb:
>> Comments bellow.
>>
>> On Fri, 13 Jun 2008 19:30:23 +0300, Eike Stepper
>> <stepper@sympedia.de> wrote:
>>
>>> Cristi Angheluta schrieb:
>>>> Hi Eike,
>>
>>> My guess is that the EMF bindings require a usual EMF change
>>> notification. The CDOInvalidationNotification is a user defined
>>> notification. Maybe you can discover what code is triggered by the
>>> binding adapters (or whatever they're called in data binding) when a
>>> change notification arrives and do the same now when invalidation
>>> notifications arrive?
>>>
>>
>> Hi Eike,
>>
>> I discovered what was wrong with my emf databindings. The
>> org.eclipse.emf.databinding.EObjectObservableValue@firstListenerAdded(),
>> indeed receives a CDOInvalidationNotification but fails to
>> fireChangeValue because CDOInvalidationNotification does not have an
>> eFeature attached (is null).
>>
>> To whom may be interested I created a subclass (see attachment)
>> CDOObjectObservableValue, of class EObjectObservableValue, that
>> behaves (I guess) accordingly to CDO intricacies.
>>
>> This class can be used as to bind a value to a Label.
>>
>> <code>
>> XConnection conn = ... //cdo object
>>
>> IObservableValue lblv = SWTObservables.observeText(lbl);
>> //interested in status attribute of conn
>> IObservableValue emfv = new CDOObjectObservableValue(conn,
>> YourPackage.Literals.XCONNECTION__STATUS);
>>
>> DataBindingContext ctx = new EMFDataBindingContext();
>> ctx.bindValue(lblv, emfv, null, null);
>>
>> </code>
>>
>> Cheers,
>> ___________________________________________
>>
>> Cristi Angheluta
>> Software Engineer
>>
>> Bucharest Stock Exchange
>> 34-36 Carol I Boulevard, 13th Floor
>> Bucharest, 020922, Romania
>>
>> Mobile: +40-742-033-771
>> Phone: +40-21-3079512/166
>> Fax: +40-21-3079519
>> email: undisclosed@nomail.net
>> ___________________________________________
>>
>> "A minute to learn, a lifetime to master."
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 26 16:13:42 GMT 2024
Powered by FUDForum. Page generated in 0.04256 seconds |
] 
Search
Help
Register
Login
Home
