[MGNLUI-4517] Migrate LinkField to Vaadin 8 Created: 20/Jul/18  Updated: 26/Jun/19  Resolved: 21/Sep/18

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

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Federico Grilli
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-4516 Migrate more Vaadin fields to V8 cont... Closed
dependency
depends upon MGNLUI-4638 Chooser dialog in Vaadin 8 Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Documentation update required:
Yes
Date of First Response:
Epic Link: UI framework: dynamic forms and cross-field interaction
Sprint: Basel 153, Basel 154, Basel 155, Basel 156
Story Points: 13

 Description   

Acceptance criteria:

  • functionality-wise there should be no regression compared to the current status of M5-based link field.
    • i.e. one should be able to reference the content items from arbitrary apps
  • the definition should be prepared to allow referencing content from sources that aren't bound to any app (see the technical steps below)
  • Preview of selected item (image, contact) is displayed next to the link field.

The following technical steps need to be accomplished:

  • come up with a link field definiton that is less bound to the apps, so that we would eventually be able to link the content that is not connected to any app (content type, remote service etc). Ideally the definition should not require the app to be present, however though, it should still be possible to delegate the chooser resolution to an app.
  • carefully design interaction with chooser dialog (should be done as a joint venture with chooser dialog story DEV-974, which is a pre-requisite for this story)
  • provide Vaadin 8 based field factory

tips:

  • some relation to the select fields may be traced (both connect to a datasource after all, both select smth)


 Comments   
Comment by Christopher Zimmermann [ 31/Jul/18 ]

RE: "eventually be able to link the content that is not connected to any app (content type, remote service etc)". Does this ticket include how the link reference is "physically" stored? Or is it just about how the link/chooser is configured?

Comment by Aleksandr Pchelintcev [ 31/Jul/18 ]

czimmermann no, this story does not propose how exactly the link should be generated, which should be a datasource-specific operation anyway. What needs to be done in the scope of this story though is untiying the definition from the JCR-only concepts like IdentifierToPathConverter, which should be shifted away from the LinkFieldDefinition to its respective place.

Once the definition is non bound to any particular domain, it would be essentially possible to re-use the LinkFields with other domains.

Comment by Christopher Zimmermann [ 18/Sep/18 ]

So, if I am configuring a linkField to link to an asset - do I still need to provide:

identifierToPathConverter:
    class: info.magnolia.dam.app.assets.field.translator.AssetCompositeIdKeyTranslator
  

And for linking to a "normal" content app do i need to provide:

identifierToPathConverter:
         class: info.magnolia.ui.form.field.converter.BaseIdentifierToPathConverter

Or can the datasource in the app provide that?

Comment by Federico Grilli [ 18/Sep/18 ]

czimmermann no need to provide that anymore. M6 framework provides a strategy to resolve those converters starting from datasources. Quoting the javadoc from ItemToLinkConverterResolverStrategy can hopefully help clarifying this. At any rate, users do not need to specify those in configuration.

/**
 * Attempts to resolve an item to link {@link com.vaadin.data.Converter} for a given field based on its datasource configuration.
 * Typically item to link converters are used to represent a complex object as a simple object that references the complex one.
 * For instance, a JCR Node may be represented by its identifier, that is a plain String.
 * In this example, an item to link converter will be able to transform a Node to its identifier and vice versa.
 */
public interface ItemToLinkConverterResolverStrategy<PRESENTATION, MODEL> ...
Comment by Christopher Zimmermann [ 19/Sep/18 ]

Cool!

What if my linkfield is linking to an M5 style app, what works and doesn't in this case?
I guess none of the datasource based things work, or is there a sort of "compatibility layer"?

Comment by Federico Grilli [ 19/Sep/18 ]

That case currently won't work. A compatibility layer hasn't been considered yet afaik. However, migration is of course in our radar https://jira.magnolia-cms.com/browse/MGNLUI-4584

Comment by Christopher Zimmermann [ 20/Sep/18 ]

OK, makes sense.
I see developers getting tripped up by this - they follow a docs example of setting up a link field to M6 app, but it does not work when they do it because they try to link to M5 app with new syntax.

Is there a clear error message in the logs in this case?

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