Implemented in 4.0

 

Page describes the problem prior to resolution

Magnolia 3 has a semi centralized mechanism to resolve links. Unfortunately it is not easy to use it to resolve single links because it has been written to transform content written by the fck editor.

Goal

  • it should be easy to create links when you have
    • a node
    • a nodedata (binaries)
    • a uuid and repository name
  • this is used to
    • create links in templates
    • process fck editor content based on the uuid patterns (out tag, content wrapper)
  • it must be configurable (similar to what we have today: /server/rendering/linkResolver)

Status / Problems

  • info.magnolia.cms.link.LinkResolver provides only methods to transform content strings with uuid links
  • in many places we instantiate a link transformer while we should use a centralized mechanism
    • info.magnolia.freemarker.MagnoliaObjectWrapper 114 & 116
    • info.magnolia.cms.link.LinkHelper.convertUUIDtoURI(String, String)
  • messy info.magnolia.cms.util.LinkUtil and info.magnolia.cms.link.LinkHelper** deprecated methods
    • confusing names
    • missing methods to transform a node or a nodedata

Solution / Tasks

  • API

    0%

    Task List

  • Utils

    0%

    Task List

  • No labels

7 Comments

  1. Jan Haderka

    Re "drop LinkResolver" task ... currently we have 3 classes doing quite similar things and in many cases calling each other internally

    • i.m.cms.link.LinkResolverIml
    • i.m.cms.link.LinkHelper
    • i.m.cms.util.LinkUtil

    LinkResolver is nearly not used anywhere in our code, so I'll deprecate the whole interface and it's impl.
    LinkHelper and LinkUtil are used equally often in our code, sometimes even on one line of code:

    i.m.cms.taglibs.Out:384
    value = LinkUtil.makeRelativePath(LinkHelper.convertUUIDtoHandle(value, this.getUuidToLinkRepository()),
 MgnlContext.getAggregationState().getMainContent().getHandle());

    Since LinkUtil is outside of link package, I would like to deprecate it as well and concentrate all usefull methods in LinkHelper. Any objections?

    1. Philipp Bracher

      the original intention has been:

      • util: this is what end users should use (existed before the other classes)
      • helper: util class which is used inside the API
      • resolver: pluggable implementation

      I hope this clarifies it a bit

      1. Philipp Bracher

        But yes, creating a single and useful util class is the goal

  2. Magnolia International

    info.magnolia.link should become the single point of entry for the new linking API.

    1. Jan Haderka

      just i.m.link? Are we dropping the cms from any new code? In that case I will deprecate all code in i.m.cms.link.* and move relevant parts of the code to the new package.

  3. Jan Haderka

    How about URI2RepositoryManager and URI2RepositoryMapping in {i.m.cms.beans.config}} package? Are they out of the scope for now or also part of the re-factoring?

    1. Philipp Bracher

      I would like to keep them out of scope, except we have good reasons for.