|Discussion: NatTable Roadmap [message #1389215]
||Fri, 27 June 2014 13:54
| Dirk Fauth
Registered: July 2012
Hi everybody, |
As mentioned with the NatTable 1.1 release, we planned to stop active development for the 1.x architecture. This decision was made because of several issues we see with the current architecture. Our plan was to focus on the 2.x architecture, which mainly meant to reimplement everything new.
We skipped that decision because of several reasons, mainly because it would be too much work in one step. Also we are aware of the growing user base of the NatTable 1.x architecture, and we want the NatTable community to grow further, to get more interested parties, contributors and committers, which will make such changes easier to staff.
The current idea is to perform a smooth transition from the old architecture to a new one. This is not possible for all changes, like event handling and offset rendering calculation to name a few. But for some of the major changes it looks like a good idea.
Although it will be possible to introduce some architectural changes into 1.x without breaking too much, there will be API changes users will have to follow. But with that smooth transition, users of NatTable 1.x are able to follow and will not have to implement everything new with the new architecture at first hand.
Below you will find the ideas on the roadmap for NatTable. I would like everyone to participate in a discussion about that. Also raise your hand if you like to help with the implementation or anything else regarding the future of NatTable.
The following is a first draf of a roadmap for the future of NatTable:
- Abstract out direct SWT dependencies
To support multiple UI toolkits it is necessary that the rendering calculations are independent of SWT. For this we will introduce interfaces to operate on, while the concrete implementations will be wrapper on UI toolkit classes that are served via factory.
This will have impact on users code for configuration of styles, listeners and menus. We will provide helper methods to make the code changes as easy as possible.
The following classes will need to be wrapped:
- Point, Rectangle
- Color, Font, Image
- Editor controls
- NatTable Canvas inheritance
- UI bindings (mouse and keyboard listener)
- DnD support
- To add support for other UI toolkits, the wrappers will use resolution independent rendering (e.g. JavaFX uses doubles for pixel coordinates).
- Extract the SWT dependent implementations to a new extension.
Doing this will change the installation process, as a new extension needs to be installed in order to render a NatTable.
This will also enable additional UI toolkit support.
- Remove painter states
Several painters have their own states additionally to the current styling, e.g. height/width calculation configuration in TextPainter. These states should all be style attributes so it is possible to completely style a NatTable declarative instead of creating different instances of painters.
- Update NatTable dependencies
- Update to Eclipse Helios (Bug 413208)
- Remove Apache Commons Lang dependency
- Introduce dependency injection
- Every NatTable instance will get its own DI context (in Eclipse 4 this means its own context in the DI context hierarchy).
- Support for several DI container/frameworks like Eclipse 4, Guice and Weld.
- It should be possible to add NatTable to an application that already uses DI (e.g. Eclipse 4) by using the existing container, without introducing new dependencies.
- It should still be possible to run NatTable in applications that doesn't use DI. In such cases NatTable will need to have its own container that is independent from the rest of the application.
- Only support already globally used instances like ConfigRegistry, UIBindingRegistry or the current active cell editor for dependency injection in this phase.
The above are just the first two main steps towards the new architecture. Implementing them in the current architecture will ensure the transition to the new architecture isn't a change with high costs for users and will ensure stability.
The following refactorings will need to be done to move to the 2.x architecture, where not all changes are yet planned or verified to work in the future:
- Extend the DI mechanism to also support creation and connection of layer compositions
- Refactor internal event handling
- Currently events and commands are mutable. This is causing strange side effects sometimes.
- Refactor ILayer interface to be smaller (e.g. create helper classes to provide general functions that doesn't need to be implemented all the time)
- Support really huge data sets (long ranges)
- Correct client area and offset calculation
- Implement unique cell identification without the need for index-position-transformations
- Add a configuration language and a corresponding editor to compose a NatTable
Additional tasks that can be done in parallel could be:
- CSS styling engine
- Refactor column grouping
- Add accessibility support
- Add support for lazy loading data and also remove items from memory on scrolling (e.g. Disposing images) for better memory handling. (scroll listeners)
- Refactor cell size configuration, remove SizeConfig from DataLayer and make it available in a global scope
- Move GroupBy interfaces and abstract implementations to NatTable Core, so it is also available using other list implementations
- Refactor LabelStack to implement itself the Collection interface which makes the usage easier
- Refactor configurations to follow the triangular concept of registry, ui bindings and layer (command handler) concept for every layer
Please start the discussion on the NatTable roadmap. Feel free to add additional ideas or contact us if you want to take a task.
Of course we would also welcome sponsors, which would enable us to spend more time on developing the future of NatTable.
Dirk & Edwin
[Updated on: Sat, 05 July 2014 07:41]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.01980 seconds