[MGNLUI-3458] Backwards compatibility in DialogDefinitionRegistry and providers Created: 09/Jun/15 Updated: 01/Jul/15 Resolved: 26/Jun/15 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | dialogs |
| Affects Version/s: | 5.4 |
| Fix Version/s: | 5.4 |
| Type: | New Feature | Priority: | Neutral |
| Reporter: | Tobias Mattsson | Assignee: | Magnolia International |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | blossom, config, dialog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||
| Description |
| Comments |
| Comment by Mikaël Geljić [ 15/Jun/15 ] |
|
Linking to the related ticket in UI re: refactoring of the DialogDefinitionRegistry. |
| Comment by Mikaël Geljić [ 15/Jun/15 ] |
|
pushed current progress respectively to branches:
|
| Comment by Tobias Mattsson [ 15/Jun/15 ] |
|
Regarding MagnoliaMessageSource this would work in both 5.3 and 5.4 if LocaleProvider remains an interface. private static class StaticLocaleProvider implements LocaleProvider { private final Locale locale; public StaticLocaleProvider(Locale locale) { this.locale = locale; } @Override public Locale getLocale() { return locale; } public Locale get() { return getLocale(); } } As for ContextLocaleProvider I could change the code to use ComponentProvider.newInstance which would work in both 5.3 och 5.4. So that's not a problem. |
| Comment by Tobias Mattsson [ 15/Jun/15 ] |
|
Regarding DialogDefinitionRegistry I have now pushed my hackish workarounds on branch It solves these problems:
I know this hacks around the new design to reestablish the earlier design exactly. Hopefully we can find a more elegant solution. I'm very curious to see how this behaves in the new tooling. Does it just break down horribly and burn to the ground? Maybe it should be presented using some kind of placeholder and the provider should return that when called from anywhere but BlossomFormDialogPresenter. Mika could you give me some hints on how to test this with the tooling? |
| Comment by Tobias Mattsson [ 26/Jun/15 ] |
|
I've lowered the priority to neutral because after investigating this more I've realized the best option is to do a Blossom 3.1 release for 5.4 which adopts the new API both for registries + providers and for locale provider. To fit the new registry api Blossom will return an empty dialog when not called from BlossomFormDialogPresenter. The definition returned then will have presenterClass set so it can be acquired safely. Created |
| Comment by Magnolia International [ 26/Jun/15 ] |
|
Merged in the fix/DialogDefinitionRegistry-compatibility branch to provide a "compatibility" method in DialogRegistry, similar to what we did in TemplateRegistry. |
| Comment by Michael Mühlebach [ 29/Jun/15 ] |
|
The code for backward compatibility in DialogDefinitionRegistry and TemplateDefinitionRegistry could be improved because it is duplicated and uses assumptions about the definition Id we want to get rid of. |