Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 120 rates

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.


  • 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

  • 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
    •, String)
  • messy info.magnolia.cms.util.LinkUtil and** deprecated methods
    • confusing names
    • missing methods to transform a node or a nodedata

Solution / Tasks

  • API


    Task List

  • Utils


    Task List

  • No labels


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

    • 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:

    value = LinkUtil.makeRelativePath(LinkHelper.convertUUIDtoHandle(value, this.getUuidToLinkRepository()),

    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. 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. But yes, creating a single and useful util class is the goal

  2. should become the single point of entry for the new linking API.

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

  3. 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. I would like to keep them out of scope, except we have good reasons for.