[e4-dev] e4 Views (Pure) - Status Update

[Joseph D Carroll Jr <jdsalingerjr@xxxxxxxxx>]

Here is a brief summary of some of the issues I have encountered while working on porting the different views.  Initially I wanted to focus on the views listed under general, at least in my mind these are the views that could be considered "core" RCP views.  I recently officially parted ways with my previous employer so I have been busy with that and haven't been able to spend much time with the views.  However, this week and next I was planning on looking at these and some performance testing.

Blocking issues (not really) :

• In the fragment editor, the "Find" feature for the element id does not work if the application model is named anything other than Application.e4xmi
• Bug 382717 (just noticed the patch and have not tested it)

Other issues :

• Required Minimum Execution Environment J2SE-1.5  (need annotations)
• Several plugins still have J2SE-1.4 as the min environment and simply changing this to 1.5 may cause some issues with generics and raw types (if not just a whole lot of compiler warnings).  An analysis would have to be made for each plugin to see if changing the environment would cause problems and if so how to deal.
• PageBookView
• Several of the views extend from PageBookView which has obvious dependencies on 3.x.  Aside from just migrating PBV to e4, this would be a strong candidate for model extension (IMO).  There is also the similar TableView and maybe even CommonNavigator.  So in general, should any of the supporting objects first become model objects?
• All e4 changes will be *Breaking Changes*

Practice & Theory :

• Should fragment naming schemes be set?
• Assumption -> The new e4 parts should be in their existing bundles and not separate o.e.e4.* bundles. <-
• But what about o.e.e4.* packages within the bundle?
• Since there is a general separation of church and state in o.e.e4.ui.workbench, should the "part" implementation be separate from the "presentation"?  Whereby any API provided by the part and maybe persistence is captured in the base object and a separate object provides the presentation (swt).
• The new e4 parts (views) will obviously break API, but before just diving into the migration process should we solicit a wish list for future api?

There are a couple of other issues (like collecting any applicable tags into a central location) but none of which need to be addressed at this point.

If anyone has any feedback or comments please do not hesitate, this is clearly still very much a moving target.  Again, unless there is opinion otherwise, the complete list of views I am focusing on are:

• Bookmarks
• Console
• Error Log
• Help
• Internal Web Browser
• Markers
• Navigator
• Outline
• Problems
• Progress 
• Properties
• Task List
• Tasks 
• Templates

Thanks,

JD