| [CDO] MARS Enhancements [message #1694348] |
Mon, 04 May 2015 15:31  |
Eclipse User |
|
|
|
My company is building an application on top of EMF and CDO.
Current plans are to:
1. Allow the user to run a local repo when the application is started as
described in:
https://wiki.eclipse.org/Run_a_CDO_container_inside_eclipse_runtime
2. Use a CDOViewProvider to allow our UIs to work with both XMI and CDO
resources.
3. Create UIs with EMF Parsley and NAT Table to be able to work with EMF
based files and CDO repositories.
Questions:
A. I see that the CDO Mars release allows the user to create a local
repo. Does this deprecate the need to explicitly do #1 ?
B. Will the CDOViewProvider change in anyway? Can we still use this for
our agnostic UIs and still utilize the new functionality in the Project
Explorer and the CDO Editor?
C. Will be adding menus, query selection & filtering to the UI we are
creating. Can these be added as well to trees in the ProjectExplorer
and CDO Editors?
thanks for any information on this,
John
|
|
|
| Re: [CDO] MARS Enhancements [message #1694359 is a reply to message #1694348] |
Mon, 04 May 2015 17:35  |
|
Am 04.05.2015 um 17:31 schrieb John E. Conlon:
> My company is building an application on top of EMF and CDO.
>
> Current plans are to:
>
> 1. Allow the user to run a local repo when the application is started as described in:
> https://wiki.eclipse.org/Run_a_CDO_container_inside_eclipse_runtime
>
> 2. Use a CDOViewProvider to allow our UIs to work with both XMI and CDO resources.
>
> 3. Create UIs with EMF Parsley and NAT Table to be able to work with EMF based files and CDO repositories.
>
>
> Questions:
>
> A. I see that the CDO Mars release allows the user to create a local repo. Does this deprecate the need to explicitly
> do #1 ?
That could be the case. It's probably best that you take a look at the current master branch of CDO. You'll find the new
APIs and implementations in o.e.e.cdo.explorer(.ui)
> B. Will the CDOViewProvider change in anyway?
CDO 4.4, our Mars release, will not break APIs. I've added a CDOViewProvide2 extension interface that you can utilize if
you want. It mostly provides you with a means to influnce the reverse mapping from URI to resource path in your provider
implementation.
That said, it's possible that after Mars I'll introduce an additional mechanism to allow client applications to specify
their own custom per-view resource "address space". This would address two current problems: (1) the need to normalize()
URIs before passing them to resources sets that are based on the new CDOCheckout layer (or any similar custom address
space layer) and (2) the need to have a meaningless first path segment in custom URI formats just because the canonical
format has the repo name in the first path segment and many places in CDO are using the static method
CDOURIUtil.extractResourcePath() method. If/when this new change comes it most likely wouldn't change the existing
CDOViewProvider mechanism.
> Can we still use this for our agnostic UIs
What is that?
> and still utilize the new functionality in the Project Explorer and the CDO Editor?
I'm not 100% sure I understand the concerns, but currently the new mechanism does not change much in the core w.r.t. URI
handling.
> C. Will be adding menus, query selection & filtering to the UI we are creating. Can these be added as well to trees
> in the ProjectExplorer and CDO Editors?
I have no reason to think that wouldn't be possible. In the end all these facilities (e.g. the new CDOExplorer's CNF
contribution for the Project Explorer and the CDOEditor) connect their JFace viewers with the workbench page selection.
So you should be able to contribute commands and menus, just as CDO does itself.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] MARS Enhancements [message #1694376 is a reply to message #1694359] |
Tue, 05 May 2015 00:16 |
| Eclipse User |
|
|
|
On 05/04/2015 12:35 PM, Eike Stepper wrote:
> Am 04.05.2015 um 17:31 schrieb John E. Conlon:
>> My company is building an application on top of EMF and CDO.
>>
>> Current plans are to:
>>
>> 1. Allow the user to run a local repo when the application is started
>> as described in:
>> https://wiki.eclipse.org/Run_a_CDO_container_inside_eclipse_runtime
>>
>> 2. Use a CDOViewProvider to allow our UIs to work with both XMI and
>> CDO resources.
>>
>> 3. Create UIs with EMF Parsley and NAT Table to be able to work with
>> EMF based files and CDO repositories.
>>
>>
>> Questions:
>>
>> A. I see that the CDO Mars release allows the user to create a local
>> repo. Does this deprecate the need to explicitly do #1 ?
> That could be the case. It's probably best that you take a look at the
> current master branch of CDO. You'll find the new APIs and
> implementations in o.e.e.cdo.explorer(.ui)
It looked like that older approach would be replaced from what I saw in
your recent demo of the new functionality. I will checkout the master
branch for more details.
>
>> B. Will the CDOViewProvider change in anyway?
> CDO 4.4, our Mars release, will not break APIs. I've added a
> CDOViewProvide2 extension interface that you can utilize if you want. It
> mostly provides you with a means to influnce the reverse mapping from
> URI to resource path in your provider implementation.
>
> That said, it's possible that after Mars I'll introduce an additional
> mechanism to allow client applications to specify their own custom
> per-view resource "address space". This would address two current
> problems: (1) the need to normalize() URIs before passing them to
> resources sets that are based on the new CDOCheckout layer (or any
> similar custom address space layer) and (2) the need to have a
> meaningless first path segment in custom URI formats just because the
> canonical format has the repo name in the first path segment and many
> places in CDO are using the static method
> CDOURIUtil.extractResourcePath() method. If/when this new change comes
> it most likely wouldn't change the existing CDOViewProvider mechanism.
>
>> Can we still use this for our agnostic UIs
> What is that?
I was just referring to the UIs we will be building that will just use
URIs and CDOViewProviders. From what you said above I expect these will
work in the new release as well.
>
>> and still utilize the new functionality in the Project Explorer and
>> the CDO Editor?
> I'm not 100% sure I understand the concerns, but currently the new
> mechanism does not change much in the core w.r.t. URI handling.
Great
>
>> C. Will be adding menus, query selection & filtering to the UI we are
>> creating. Can these be added as well to trees in the ProjectExplorer
>> and CDO Editors?
> I have no reason to think that wouldn't be possible. In the end all
> these facilities (e.g. the new CDOExplorer's CNF contribution for the
> Project Explorer and the CDOEditor) connect their JFace viewers with the
> workbench page selection. So you should be able to contribute commands
> and menus, just as CDO does itself.
Thought so as well. Thanks
best regards,
John
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02498 seconds
] 
Search
Help
Register
Login
Home
