Jump to: navigation, search

Difference between revisions of "CDO/Explorer (work in progress)"

< CDO
(Other ViewParts?)
(Description)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This bugzilla is used for discussion and to track progress: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=258638 258638: CDO Explorer]
+
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=258638 Bugzilla 258638: CDO Explorer] is used for discussion and to track progress.
 
Everybody is invited to participate in whatever form!
 
Everybody is invited to participate in whatever form!
  
 
__TOC__
 
__TOC__
  
=Vision=
+
==Vision==
  
The CDO Explorer is a client-side RCP application that demonstrates all the core functionality of CDO. It is expected to provide re-usable user interface components as well as a default distribution in form of an RCP application. CDO users shall be enabled to download a single setup.exe file and install a complete technology stack, including repository server, database, the CDO Explorer client, possibly a CDO Admin client to (re-) configure the repository server.
+
The [[CDO]] Explorer is a client-side [[RCP]] application that demonstrates all the core functionality of CDO. It is expected to provide re-usable user interface components as well as a default distribution in form of an RCP application. CDO users shall be enabled to download a single setup.exe file and install a complete technology stack, including repository server, database, the CDO Explorer client, possibly a CDO Admin client to (re-) configure the repository server.
  
 
We'd like to demonstrate the following:
 
We'd like to demonstrate the following:
Line 23: Line 23:
 
* others?
 
* others?
  
=Description=
+
==Description==
 
The following screen stub can be used as a basis for more detailed UI descriptions.<br>
 
The following screen stub can be used as a basis for more detailed UI descriptions.<br>
 
'''The content of the open editors in the screen stub is irrelevant, it's just to illustrate the general use of the forms toolkit.'''<br>
 
'''The content of the open editors in the screen stub is irrelevant, it's just to illustrate the general use of the forms toolkit.'''<br>
The stub project is available via CVS: org.eclipse.emf/org.eclipse.emf.cdo/develop/incubation/CDOExplorer
+
The stub project is available via CVS: [http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.emf/org.eclipse.emf.cdo/incubation/CDOExplorer/?root=Modeling_Project org.eclipse.emf/org.eclipse.emf.cdo/incubation/CDOExplorer]
  
 
[[Image:Stub1.png]]
 
[[Image:Stub1.png]]
  
==Repository Browser ViewPart==
+
===Repository Browser ViewPart===
  
 
The root elements of the Repository Browser are CDO Repositories with all the CDO structure elements below them:
 
The root elements of the Repository Browser are CDO Repositories with all the CDO structure elements below them:
Line 36: Line 36:
 
* Virtual '''Resources''' node: CDOResourceFolder, CDOResource, CDOObject
 
* Virtual '''Resources''' node: CDOResourceFolder, CDOResource, CDOObject
  
Browser would allow to provide some basic actios as:
+
Browser would allow to provide some basic actions as:
  
 +
* Open object editors
 
* Copy & Paste CDOFolders and CDOResources
 
* Copy & Paste CDOFolders and CDOResources
 
* Delete CDOFolders and CDOResources
 
* Delete CDOFolders and CDOResources
 
* DnD (default behaviour would be cut & paste, could also be copy & paste by holding CONTROL key)
 
* DnD (default behaviour would be cut & paste, could also be copy & paste by holding CONTROL key)
* Rename CDOFolders & CDOResources
+
* Create, Rename, Move CDOFolders, CDOResources & CDOObjects
  
 
Items in the tree should be decorated, depicting some important aspects of their state.
 
Items in the tree should be decorated, depicting some important aspects of their state.
Line 49: Line 50:
 
Blocking UI thread should never happen.
 
Blocking UI thread should never happen.
  
The properties view should be populated with data from selected items in the browser.
+
The properties view should be populated with data from selected items in the browser. ('''EIKE''': properties view does not depend on the IDE but I guess it's rarely present in real RCPs!)
  
==Object Form EditorPart==
+
* Wizard-driven configuration definition: The new definition model would allow us to define how the different parts of a CDOSession/CDOView object are wired. Step by step, a configuration wizard will help user how to define that configuration. Help commands should be provided everywhere the user might feel lost. This wizard will be as simple as possible. Advanced features and other configuration aspects would be accessible through double click in the repository connection item. Furthermore, this item in the browser will be presented as a higher level "repository connection" concept to the user, being in fact a CDOView.
  
==Other ViewParts?==
+
===Object Form EditorPart===
  
* Log View: Shows server side events, not fine-grained. Events like folder/resource created, moved, deleted, modified. Lock set/released. Successful commits, conflictive commits. Each action should be logged together with a timestamp, user-name...  
+
===Other ViewParts?===
 +
 
 +
* Log View: Shows server side events, not fine-grained. Events like folder/resource created, moved, deleted, modified. Lock set/released. Successful commits, conflictive commits. Each action should be logged together with a timestamp, user-name... ('''EIKE''': Vik, do yu really mean server-side events??)
 
** Allow saving the log to a file
 
** Allow saving the log to a file
 
** Create a report through BIRT
 
** Create a report through BIRT
** We might even create a Log Model ("CDO Event Model"), so we can persist it in the CDO repository as well :P We could then extract statistics from this log model to identify user behaviour, bottlenecks, more detailed statistics... Queries might be applied over this log model
+
** Optional (low priority): We might even create a Log Model ("CDO Event Model"), so we can persist it in the CDO repository as well :P We could then extract statistics from this log model to identify user behaviour, bottlenecks, more detailed statistics... Queries might be applied over this log model. We should also consider existing usage monitoring technologies and TPTP.
  
 
* Object change history: A view that would show a list of all the registered changes of an object selected in another focused ViewPart or EditorPart. User could "pin" this view so it stops listening to further selection changes, so the history of certain object remains in the ViewPart while navigating.  
 
* Object change history: A view that would show a list of all the registered changes of an object selected in another focused ViewPart or EditorPart. User could "pin" this view so it stops listening to further selection changes, so the history of certain object remains in the ViewPart while navigating.  
 
**Is it possible to perform queries over a list of objects states in time through our query API? Something like "give me all object states between 1 January and 6 February".
 
**Is it possible to perform queries over a list of objects states in time through our query API? Something like "give me all object states between 1 January and 6 February".
  
==Other EditorParts?==
+
===Other EditorParts?===
  
 
* Extensible multi-page editor: User could contribute, through extension points, additional pages to the default editor. We could provide some nice pages too.
 
* Extensible multi-page editor: User could contribute, through extension points, additional pages to the default editor. We could provide some nice pages too.
  
=Design=
+
==Design==
  
 
The repository elements of the repository browser view are internally CDOViews or CDOAudits (switchable through properties). When they are '''not''' audits we enable modification actions for folder, resource and object creation and manipulation. All these ''commands'' are executed in background jobs and open a CDOTransaction, modify the object graph and commit.
 
The repository elements of the repository browser view are internally CDOViews or CDOAudits (switchable through properties). When they are '''not''' audits we enable modification actions for folder, resource and object creation and manipulation. All these ''commands'' are executed in background jobs and open a CDOTransaction, modify the object graph and commit.
  
=Bugzillas=
+
==Bugzillas==
 
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=258638 258638: CDO Explorer]
 
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=258638 258638: CDO Explorer]
 +
 +
[[Category:CDO]][[Category:EMF]]

Latest revision as of 13:14, 28 December 2010

Bugzilla 258638: CDO Explorer is used for discussion and to track progress. Everybody is invited to participate in whatever form!

Vision

The CDO Explorer is a client-side RCP application that demonstrates all the core functionality of CDO. It is expected to provide re-usable user interface components as well as a default distribution in form of an RCP application. CDO users shall be enabled to download a single setup.exe file and install a complete technology stack, including repository server, database, the CDO Explorer client, possibly a CDO Admin client to (re-) configure the repository server.

We'd like to demonstrate the following:

  • strict use of data binding
  • together with asynchronous node expansion
  • drag and drop of objects to create references
  • extensible repository browser view
  • extensible form editors for single objects
  • neat integration of all the optional CDO functionality, like:
    • query definition and execution
    • import/export of resources
    • resource browsing (integrated in the generic repository browser)
    • history browsing
    • explicit locking and a locks view
    • local and remote annotation of CDOModelElements
  • others?

Description

The following screen stub can be used as a basis for more detailed UI descriptions.
The content of the open editors in the screen stub is irrelevant, it's just to illustrate the general use of the forms toolkit.
The stub project is available via CVS: org.eclipse.emf/org.eclipse.emf.cdo/incubation/CDOExplorer

Stub1.png

Repository Browser ViewPart

The root elements of the Repository Browser are CDO Repositories with all the CDO structure elements below them:

  • Virtual Packages node: EPackage, EClass, EAttribute, EReference, EEnum, ...
  • Virtual Resources node: CDOResourceFolder, CDOResource, CDOObject

Browser would allow to provide some basic actions as:

  • Open object editors
  • Copy & Paste CDOFolders and CDOResources
  • Delete CDOFolders and CDOResources
  • DnD (default behaviour would be cut & paste, could also be copy & paste by holding CONTROL key)
  • Create, Rename, Move CDOFolders, CDOResources & CDOObjects

Items in the tree should be decorated, depicting some important aspects of their state. For instance, CDOFolder, CDOResource or CDOObject could have a read/write lock. An overlay icon and colored label should depict this.

Asynchronous refresh is an important requirement. We should make exemplary use of org.eclipse.emf.databinding. Blocking UI thread should never happen.

The properties view should be populated with data from selected items in the browser. (EIKE: properties view does not depend on the IDE but I guess it's rarely present in real RCPs!)

  • Wizard-driven configuration definition: The new definition model would allow us to define how the different parts of a CDOSession/CDOView object are wired. Step by step, a configuration wizard will help user how to define that configuration. Help commands should be provided everywhere the user might feel lost. This wizard will be as simple as possible. Advanced features and other configuration aspects would be accessible through double click in the repository connection item. Furthermore, this item in the browser will be presented as a higher level "repository connection" concept to the user, being in fact a CDOView.

Object Form EditorPart

Other ViewParts?

  • Log View: Shows server side events, not fine-grained. Events like folder/resource created, moved, deleted, modified. Lock set/released. Successful commits, conflictive commits. Each action should be logged together with a timestamp, user-name... (EIKE: Vik, do yu really mean server-side events??)
    • Allow saving the log to a file
    • Create a report through BIRT
    • Optional (low priority): We might even create a Log Model ("CDO Event Model"), so we can persist it in the CDO repository as well :P We could then extract statistics from this log model to identify user behaviour, bottlenecks, more detailed statistics... Queries might be applied over this log model. We should also consider existing usage monitoring technologies and TPTP.
  • Object change history: A view that would show a list of all the registered changes of an object selected in another focused ViewPart or EditorPart. User could "pin" this view so it stops listening to further selection changes, so the history of certain object remains in the ViewPart while navigating.
    • Is it possible to perform queries over a list of objects states in time through our query API? Something like "give me all object states between 1 January and 6 February".

Other EditorParts?

  • Extensible multi-page editor: User could contribute, through extension points, additional pages to the default editor. We could provide some nice pages too.

Design

The repository elements of the repository browser view are internally CDOViews or CDOAudits (switchable through properties). When they are not audits we enable modification actions for folder, resource and object creation and manipulation. All these commands are executed in background jobs and open a CDOTransaction, modify the object graph and commit.

Bugzillas