[MGNLUI-4638] Chooser dialog in Vaadin 8 Created: 28/May/18  Updated: 22/Dec/21  Resolved: 20/Sep/18

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0

Type: Improvement Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Cedric Reichenbach
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLUI-5291 DOC: Re-implementation of chooser dia... Closed
dependency
is depended upon by MGNLUI-4517 Migrate LinkField to Vaadin 8 Closed
duplicate
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Documentation update required:
Yes
Date of First Response:
Epic Link: UI framework: forms, dialogs, content editing
Sprint: Basel 153, Basel 154, Basel 155, Basel 156
Story Points: 8

 Description   

Re-implementation of chooser dialog with Vaadin 8 powered UI framework. New strategy for resolving the definition. Current strategy is rather rigid:

  • choosers are bound to apps => there cannot be a chooser without an app. Also one app can hardly have two choosers.
  • chooser UI auto resolution logic works but maybe could be improved (the first encountered browser sub-app picked and chooser definition is derived from it)

possible solution:
Maybe rather associate choose dialogs with the caller sites (mostly - LinkFields). Let the link field describe chooser in its definition. If it would require "whatever is brought by 'that' app" - the current logic would still be sufficient.

However, the link field could point to a content type, maybe JCR workspace, or smth completely custom. That way every link field would be able to have their own unique chooser, but then the burden of creating it will be put on e.g. LinkFieldFactory and not on the respective app.

The latter probably not bad, cause it would potentially let us get rid of that hack that starts the app instances without showing their UI (see AppController#startAppWithoutFocusing or similar). Instead of that hack, a dedicated chooser dialog factory (or similar utility) should setup IoC context, find out where the choose dialog definition should come from and then instantiate it.

Improvements, can be split into a separate enhancement story:

  • Limit link field to a certain node type.
  • Ability to have multiple different chooser dialogs for the same app (workspace).
  • Multiselect in a chooser dialog.
  • Improve the APIs. Restrictive chooser callback today.


 Comments   
Comment by Antti Hietala [ 02/Aug/18 ]

Timebox to 5 SP. Create a naive choose dialog implementation. Basically a grid in a Vaadin window, that's it. Possibly leveraging the UI framework view building.

Generated at Mon Feb 12 09:18:36 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.