| EMF transactions - why the special ExtendedPropertySheetPage? [message #989322] |
Wed, 05 December 2012 16:12  |
|
Hi,
Why does EMF transaction have its own ExtendedPropertySheetPage?
According to section4 in the blog http://techblog.goelite.org/making-your-emf-model-transactional/ it is to "substitute the non-transactional implementation" of ExtendedPropertySheetPage that EMF supplies. But there is no explaination as to why this is necessary.
Looking at the methods refresh and selectionChanged I fail to see why this is necessary since we can wrap our property source as with:
propertySheetPage.setPropertySourceProvider(new
TransactionalAdapterFactoryContentProvider(
(TransactionalEditingDomain) getEditingDomain(), adapterFactory));
Are there cases where this isn't enough?
The reason for asking is that we are aiming at implementing a more lightweight threadsafe approach where we do not need to support editing domains, commands etc and thus do not want to hook into the whole EMF Transactions framework.
Thanks for all input!
--Fredrik
|
|
|
| Re: EMF transactions - why the special ExtendedPropertySheetPage? [message #989331 is a reply to message #989322] |
Wed, 05 December 2012 16:33  |
|
Hi, Fredrik,
IIRC (it has been some years, now), the critical difference in this
extended property sheet page is that it performs UI refreshes in
read-only transactions, on the assumption that refreshes will read the
model. This is required for thread-safety amongst current reads and
writes, especially in proxy resolution and derived calculation of
features.
HTH,
Christian
On 2012-12-05 16:12:07 +0000, Fredrik Attebrant said:
> Hi,
>
> Why does EMF transaction have its own ExtendedPropertySheetPage?
> According to section4 in the blog
> http://techblog.goelite.org/making-your-emf-model-transactional/ it is
> to "substitute the non-transactional implementation" of
> ExtendedPropertySheetPage that EMF supplies. But there is no
> explaination as to why this is necessary.
>
> Looking at the methods refresh and selectionChanged I fail to see why
> this is necessary since we can wrap our property source as with:
>
> propertySheetPage.setPropertySourceProvider(new
> TransactionalAdapterFactoryContentProvider(
> (TransactionalEditingDomain) getEditingDomain(), adapterFactory));
>
> Are there cases where this isn't enough?
>
> The reason for asking is that we are aiming at implementing a more
> lightweight threadsafe approach where we do not need to support editing
> domains, commands etc and thus do not want to hook into the whole EMF
> Transactions framework.
> Thanks for all input!
> --Fredrik
|
|
|
Powered by
FUDForum. Page generated in 0.03180 seconds
] 
Search
Help
Register
Login
Home
