On 23.05.2018 we have had a workshop where we discussed the proposed features. Even though the general feedback was positive and none of the features was rejected, there's still a lot of work to do to take the effort to the production-grade level.
Below is the proposed mind-map with possible further steps that we could take (the source XMind file is also attached).
New features
| Name | Description | Estimate |
|---|---|---|
| Rest integration | Develop an alternative to JCR for browsing and form viewing/editing. See the synergy with the REST client (or use some other approach). Goal - to have easily configurable REST browser and REST-based forms | 2 weeks |
| Cross-field validation support | The field hierarchy is now kept in the form binders, so technically it is available while form is active and could be injectable in the validators and/or fields themselves. Need to see how to better expose such hierarchy and how to address at least some of the issues related to the topic. | 2 weeks |
| Forms with alternative layout | Ship 1-2 alternative ways to layout forms (the API's are in place, even some implementation has started) | 3-5 days |
| Validation within composite fields | Re-use 'validation bubble' effort from the past, try to provide universal validation/description UI regardless of the layout | 1 week (though be trickier) |
| [optional] Master-detail sub-app | Test the flexibility of the new UI framework views and combine browser and detail in one sub-app (should be as easy as binding the pre-created form to the current selection in e.g. tree view) | 3-5 days |
| [optional] Filterable columns in Grids | The PoC solution contains column renderer which allows to filter tree grid by path. Consider productising such feature and see how would it be possible to incorporate it into configuration and implementation of the content views. | 1-2 weeks |
Essential features
| Name | Description | Estimate |
|---|---|---|
| Chooser dialog | DEV-974 - Getting issue details... STATUS | 1-2 weeks |
| Multi-value field UI | DEV-976 - Getting issue details... STATUS | 1 week |
| Migrate more fields | DEV-978 - Getting issue details... STATUS | 3 weeks (can be parallelised tho) |
| Port more column renderers | DEV-977 - Getting issue details... STATUS | 1-2 weeks (can be parallelised) |
| Harden JCR browsing implementation | (remaining DS configuration, full-text search support etc) | 1-2 weeks |
| Multi-selection support in browser | ValueContext needs generalisation (to conveniently cover the single vs multi selection cases) | 3-5 days |
| Harden DS observation mechanism | ContentChangeEvent replacement needs to be hardened: should be memory-leak safe, should be clear, corner-cases should be considered. Observation should also work for the case of the detail sub-app | 1-2 weeks |
| Re-instate previews in actionbar | Re-add the feature (should be simple with ValueContext). Question the abstraction of ImageProvider. | 3-5 days |
| Shortcuts in the grids and forms | Currently not ported over from the old implementation. Need to see also how to do it better. | 3-5 days |
| Port form-dialog | Thanks to the view-contexts and view improvements it is probably possible to make a form dialog implementation that shares most of the code with the detail sub-app, still requires quite some work. | 1-2 weeks |
| Implement Vaadin 8 - based inline row editing | Grid/TreeGrid has in-built editor API, which can play together with parts of the from framework improvements that we introduced (binders/propertysets etc). Add support for inline editing in Grid/TreeGrid | 1-2 weeks |
Migration strategy
| Name | Description | Estimate |
|---|---|---|
| App descriptor migration | Think of a strategy (special sub-app that takes an old descriptor and translates to the new or some hybrid descriptor). Consider migrating whatever is easily migrated (fields, columns etc). | 2-3 weeks |
| Legacy action support | It seems to be fairly sufficient to expose the selection context a set of JcrNodeAdapter to make some UI actions work. See how many we can cover by this and what is needed to cover more. | 1-2 weeks |
Configuration
| Name | Description | Estimate |
|---|---|---|
| Content type powered config | Requires content type solution to be available. Would be nice to shave some config parts off the detail sub-app and form dialogs. | 1 week (once content types are in) |
| Apply the type references where possible | New UI improvements do not make the descriptors any leaner as is (in order to not make the configuration less powerful). With type references for whatever possible we could mitigate this fact. | 2-2.5 weeks |
Actions
| Name | Description | Estimate |
|---|---|---|
| Re-start async action effort | Use Java 8 instead of Quartz. Try to ship the asynchronous-ness as a trait/mix-in of an action, not as some base abstract class | 2 weeks |
Misc
| Name | Description | Estimate |
|---|---|---|
| Unit testing | The effort is almost not covered by unit tests (the state of the API and implementation was fluctuating too much so far) | 3 weeks (+ maybe more since we'll need even more tests before final release) |
| UI tests | See if it would be possible to re-use the UI tests for our own apps when they are ported to the new framework | 2 weeks |
| UI push support | finally incorporate Vaadin's push support | 1 week |
Overview
Content Tools