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).
Rough effort estimation
About 300 story points
Below can be found a table with description and coarse estimates of the possible further steps (time-wise* and priority-wise**).
* (Time-wise the tasks are estimated relatively to Aleksandr Pchelintcev, i.e. if the assignee of the issue wasn't fiddling with the UI thoroughly lately, some time has to be added to get in the context.)
** (Priority-wise the tasks go from the brightest ... ... to the coldest ) 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. User benefit: Timebox to 13 SP, possible followed by smaller efforts.
DEV-920
-
Getting issue details...
STATUS
Enables:
MGNLUI-2542
-
Getting issue details...
STATUS
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 User benefit:
MGNLUI-4439
-
Getting issue details...
STATUS
13 Validate foundation, APIs before next major. Ship with new major of REST Client any time. Ship 1-2 alternative ways to layout forms. The APIs are in place, even some implementation has started. User benefit:
DEV-983
-
Getting issue details...
STATUS
Re-use 'validation bubble' effort from the past, try to provide universal validation/description UI regardless of the layout. User benefit:
DEV-992
-
Getting issue details...
STATUS
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) User benefit:
DEV-991
-
Getting issue details...
STATUS
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. User benefit: Search content by title, creation date, author, duration, rank, or any combination of properties. Configure searchable properties for an app so that they are relevant for users.
DEV-993
-
Getting issue details...
STATUS
DEV-976
-
Getting issue details...
STATUS
ValueContext needs generalisation (to conveniently cover the single vs multi selection cases) 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
DEV-1001
-
Getting issue details...
STATUS
DEV-974
-
Getting issue details...
STATUS
DEV-978
-
Getting issue details...
STATUS
Remaining JCR data source configuration, full-text search support in lists etc.
DEV-1000
-
Getting issue details...
STATUS
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.
DEV-1006
-
Getting issue details...
STATUS
DEV-977
-
Getting issue details...
STATUS
Re-add the feature (should be simple with ValueContext). Question the abstraction of ImageProvider.
DEV-1002
-
Getting issue details...
STATUS
Currently not ported over from the old implementation. Need to see also how to do it better.
DEV-1005
-
Getting issue details...
STATUS
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
DEV-1003
-
Getting issue details...
STATUS
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).
DEV-989
-
Getting issue details...
STATUS
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.
DEV-990
-
Getting issue details...
STATUS
With 6.0 we would want to ship our own apps that are already based on the new API's. Ideally we'd just migrate the configuration and deprecate the current ones.
DEV-1010
-
Getting issue details...
STATUS
21 Users expect simpler configuration with the new UI framework. Consider using the improvements we get from content types effort and type references. We use type references for fields today but the mechanism can be used also elsewhere. 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.
DEV-1008
-
Getting issue details...
STATUS
Requires content type solution to be available. Would be nice to shave some config parts off the detail sub-app and form dialogs.
DEV-1007
-
Getting issue details...
STATUS
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 User benefit:
DEV-816
-
Getting issue details...
STATUS
See if it would be possible to re-use the UI tests for our own apps when they are ported to the new framework. Port the UI tests so they work with the newly migrated apps.
DEV-1009
-
Getting issue details...
STATUS
Finally incorporate Vaadin's push support. Replace poll with push. User benefits: UI reflects the current state on the server.
DEV-797
-
Getting issue details...
STATUS
There are probably bugs in the new UI implementation, maybe there will be potential blockers even. I can't estimate that, but I'd add at least 2.5-3 weeks for that on top of the total estimate.New features
Name Description: Estimate SP Depended upon by Resurface? Delivery Cross-field validation support 13 No Before 6.0 because new APIs are introduced. Rest integration No Forms with alternative layout 8 Maybe DEV-983 Before 6.0 Validation within composite fields 8 Yes, consider Ideally in 6.0 [optional] Master-detail sub-app 5 No after 6.0, independently [optional] Filterable columns in Grids 8 No after 6.0, independently Essential features
Name Description Estimate SP Depended upon by Resurface? Delivery Multi-value field UI 8 No 6.0 Multi-selection support in browser 8 No 6.0 Harden DS observation mechanism 13 No ideally 6.0 Chooser dialog 13 No 6.0 Migrate more fields 21 No 6.0 Harden JCR browsing implementation 13 No 6.0 Port form-dialog 8 No ideally in 6.0 but could be later Port more column renderers 8 No 6.0, grid doesn't know about the old renderers. Compatibility wrapper is an alternative. Re-instate previews in actionbar 5 No can be after 6.0 but some work must be done before 6.0 Keyboard shortcuts in the grids and forms 8 No 6.0, otherwise keyboard shortcuts won't work. Can be timeboxed to 5 SP. Implement Vaadin 8 - based inline row editing 8 No 6.0, basic inline editing capability is required. Enhancements can come later. Migration strategy
Name Description Estimate Resurface Delivery App descriptor migration 8 No 6.0 Legacy action support 8 No ideally 6.0 Migrate bundled content apps to new APIs No ideally 6.0 Configuration simplifications
Name Description Estimate Resurface Delivery Apply the type references where possible 13 No after 6.0 Content type powered config 8 No ideally in 6.0 but technically can be later Actions
DEV-959
-
Getting issue details...
STATUS
Name Description Estimate Resurface Delivery Re-start async action effort 21 No Can be done after 6.0, should probably postpone. Misc
Name Description Estimate Resurface Delivery UI tests 21 Yes, possibly. Resurface may introduce style name changes that break the UI tests. 6.0 if we migrate all our own apps to the UI framework by release date UI push support 8 No Can be done after 6.0 Unknown unknowables 21 Yes, Resurface may cause bugs 6.0