[BLOSSOM-290] Enable UI 6 definition usage in dialog/tab factories Created: 27/Jan/22  Updated: 03/Nov/22  Resolved: 13/Apr/22

Status: Closed
Project: Blossom
Component/s: None
Affects Version/s: 3.4.7
Fix Version/s: 3.5.0

Type: New Feature Priority: Major
Reporter: Mikaël Geljić Assignee: Canh Nguyen
Resolution: Done Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: 9d 0.5h
Original Estimate: Not Specified

Attachments: File BLOSSOM-290_improvements.patch    
Issue Links:
Relates
relates to BLOSSOM-288 Validator is always executed Closed
relates to BLOSSOM-295 Allow injection of Spring managed com... Closed
relates to MGNLUI-7100 Re-introduce definition builders Closed
relates to BLOSSOM-291 Migrate magnolia-blossom-sample-modul... Accepted
dependency
is depended upon by BLOSSOM-279 Validator configuration is not workin... Open
documentation
to be documented by BLOSSOM-296 DOC: Mgnl 6.2.18 - Support for UI 6 d... Closed
relation
Template:
Acceptance criteria:
Empty
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Support
Sprint: DevX 5, DevX 6
Story Points: 8
Team: DeveloperX

 Description   

Blossom currently relies on the UI Framework compatibility layer with no option to move to the 6 UI Framework. As a result, new definition features are not directly accessible to Blossom users, and the auto-conversion for custom fields is an additional step in the way.



 Comments   
Comment by Pascal Karrer [ 17/Feb/22 ]

Dear Magnolia Team

I would like to highlight the urgency of this ticket, as this ticket currently affects all our customer projects and therefore customers cannot use new features such as Live-Copy. I would therefore ask you to address this with the highest priority. 
We are using Blossom in all our projects and currently cannot switch to the UI6 or the new Pages app. Blossem is an official development approach from Magnolia, which we have been using in our Magnolia projects until now. 

Therefore I ask you to implement this ticket as soon as possible and allow our customers to use the new features.
Thanks a lot!

Pascal Karrer
Team Lead Magnolia @ Merkle

Comment by Mikaël Geljić [ 28/Feb/22 ]

Hi pkarrer, we are reviewing the issue and will get back to you. Do you have a SUPPORT ticket open to follow best with the Support team on that?

Meanwhile, here are some preliminary research notes from my side:

Invocation hook

  • UiConfig/TabBuilder is a stateful builder + M5 reference holder
  • we miss a "holder" for a UI 6 definition (replacing UiConfig, TabBuilder)
  • or can we rather leverage return type on @TabFactory methods?
  • dialog factories as lambdas? (where to inline) pbly too far-fetched

Style of config-by-code

  • plain configured-definitions, verbose but ok to start with, would unblock the use case
  • groovy can help reduce verbosity on top of this
  • "with" closure pattern (avoid storing intermediate def references, but still verbose)
  • generated builders (never did, heaviest)

Generated builders

  • not APT, because no generalized annotation for fields, tabs, actions
  • => ClassGraph for type scanning
  • delegate to generic builder library? all annotation driven, some hard to wire in
Comment by Mikaël Geljić [ 31/Mar/22 ]

Based on early feedback (from beschle, thanks!), this works great for simple fields, not for complex fields, because we type the list of properties as List<FieldDefinition>. Patching it to List<EditorPropertyDefinition> should do the trick.

Comment by Björn Eschle [ 31/Mar/22 ]

One more request Can we change the signature to this:

@TabFactory("someTab")
public List<EditorPropertyDefinition> someTab() {} 

instead of:

@TabFactory("someTab")
public void someTab(final List<EditorPropertyDefinition> properties) {}  
Comment by Björn Eschle [ 01/Apr/22 ]

Hello @Mika,

I've implemented the discussed changes including the signature change:

  • BLOSSOM-290 Delegate dialog/tab method parameter resolution to spring HandlerMethodArgumentResolvers
  • BLOSSOM-290 Implement support for complex fields (EditorPropertyDefinition)
  • BLOSSOM-290 Change tab method signature

I've attached a patch file. If you could provide us write access to the repository we could also directly create a pull-requests?

Comment by Mikaël Geljić [ 08/Apr/22 ]

This ticket brings support for UI 6 definitions in Blossom's @DialogFactories and @TabFactories. \o/

The new usage is a little bit different (no fluent builders), but still quite concise.

The key difference is that @TabFactories may now return a List<EditorPropertyDefinition>—simply add your FieldDefinitions to it—instead of injecting the former TabBuilder. Blossom then generates a form-dialog definition, with a tabbed layout. See the sample below:

@TabFactory("Content")
public List<EditorPropertyDefinition> contentTab() {
    TextFieldDefinition heading = new TextFieldDefinition();
    heading.setName("heading");
    RichTextFieldDefinition body = new RichTextFieldDefinition();
    body.setName("body");
    body.setRequired(true);

    return List.of(heading, body);
}

The update preserves support for multiple tab-factories, @TabOrder, post-processing via @PostCreate (see this other sample), and @DialogFactory methods.

Comment by Björn Eschle [ 08/Apr/22 ]

Hey @Mika,

I've created a PR in the ui module which adds builder support for the field definitions: https://git.magnolia-cms.com/projects/PLATFORM/repos/ui/pull-requests/2048/overview

Unfortunately creating the builders solely in blossom was pretty verbose.

Comment by Doreen Heigener [ 26/Apr/22 ]

Are there any updates on this ticket? It is closed, but the PR from Björn is still open?

Kind regards,
Doreen

Comment by Mikaël Geljić [ 27/Apr/22 ]

Hi Doreen,
I filed MGNLUI-7100 to track re-introduction of definition builders in the Magnolia 6 UI Framework—this will come earliest in 6.2.19. We are yet to update the ticket number in the PR/commit message.
Meanwhile I'm about to release Blossom 3.5.0. See the usage of native Magnolia 6 UI definitions in my comment above.
Cheers,
Mika

Generated at Sun Feb 11 23:32:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.