[MAGNOLIA-2872] Further improve/consolidate Link api Created: 22/Sep/09  Updated: 11/Feb/13  Resolved: 02/Nov/12

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 5.0

Type: Improvement Priority: Minor
Reporter: Magnolia International Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-2619 relative links: the browser link tran... Closed
is related to MAGNOLIA-2051 Improve links API Closed
supersession
supersedes MAGNOLIA-2862 if some paragraph contains a link /us... Closed
supersedes MAGNOLIA-2865 Internal Page link in fckEdit: When t... Closed
supersedes MAGNOLIA-2768 NPE on link replacement for invalid l... Closed
supersedes MAGNOLIA-2867 Linking to non-activated pages breaks... Closed
supersedes MAGNOLIA-2259 Handle special characters properly wh... Closed
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)

 Description   

There are some places in the Link api that could be improved; the methods exposed by LinkFactory are inconsistent, for instance. (some of the methods take String parameters and fetch a node in the repository from that, others take a node - as a consequence, client code (or LinkFactory itself) gets messy - on some occasions, it has to use both methods, and exception handling gets messy, too. The fetching of nodes should be entirely handled by either LinkFactory itself - or the client code.
One example is at createLink(String uuid, String repository, String fallbackHandle, String nodeDataName, String extension, String anchor, String parameters)

There are other little quirks of the same sort that could use a little review/cleanup/rename - think testability and separation of concerns.
Also see MAGNOLIA-2259 - the solution to that issue introduced the usage of some jackrabbit API, which we should avoid.

Additionally, we should remove/review usage of deprecated classes (info.magnolia.cms.link.*) in our own code!

Some context: info.magnolia.module.fckeditor.dialogs.FckEditorDialog#convertToView and its usage of info.magnolia.link.LinkUtil#convertLinksFromUUIDPattern - this is a usecase where you don't want the exceptions to bubble up. The input might have multiple links, and depending on the use case (editor, rendering, ...) one might want to render the "broken" links (i.e <a href="/fallbackHandle">my link</a>) or just the link description (my link, no surrounding <a>), or let an exception be thrown at the first broken link. (this is not something the api is currently target for, since LinkTransformer does not take html into account, and Link does not have a notion of it's content/description)

Another similar case for improvements: info.magnolia.freemarker.models.NodeDataModelFactory - if we replace the call to LinkUtil.convertUUIDsToLinks() by LinkUtil.convertLinksFromUUIDPattern(), like the deprecation of the former suggests, we realize we have to handle the LinkException; how? Ideally, unconvertible links should be handled within LinkUtil (some exception handler interface) - in some cases, we'll want to get "some" of the text back: with uuid links in certain cases, or in a html-cleaned up way in some others (strip the complete <a> tag?)


Generated at Mon Feb 12 03:40:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.