Page History

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:

• View and manipulate data from REST sources directly in a Magnolia app. Save time and effort.
• Easily configure apps that operate on REST sources. Avoid 4-6 weeks of Java development.
  
• Faster integrations. See Easy Integration Stories

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:

• See only relevant values in form fields. Make fewer mistakes and fill the form faster.
• Populate and validate the options in one field based on what the user chooses in another field.

Timebox to 13 SP, possible followed by smaller efforts.

Enables:

Ship 1-2 alternative ways to layout forms. The APIs are in place, even some implementation has started.

User benefit:

• Usability: Set address fields visually apart from other fields. Related controls are easier to identify.
• Make it easier for people to focus on smaller and more manageable groups.
• Reduce visual clutter and only show relevant information.
• Progressive disclosure: Defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.

Re-use 'validation bubble' effort from the past, try to provide universal validation/description UI regardless of the layout.

User benefit:

• Pinpoint which sub-field in a more complex field has invalid entry, so the user knows what to fix.

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:

• Select an item in an app and edit it immediately.
• Make small edits quickly without having to jump from one subapp to another.
• For example, scheduling many events. Several small edits.

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.

• (Find Bar does a full-text search and serves a different use case.)
• Find items faster.

• Configure searchable properties for an app so that they are relevant for users.

ValueContext needs generalisation (to conveniently cover the single vs multi selection cases)

JIRA: To do Aleksandr Pchelintcev

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

JIRA: To do Aleksandr Pchelintcev

Re-add the feature (should be simple with ValueContext). Question the abstraction of ImageProvider.

JIRA: To do Aleksandr Pchelintcev

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).

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.