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

Current use cases:

In CK editor, when defining a link to an image

The following is currently generated ${link:{uuid:{0fa615af-207d-4a45-a3aa-9103d76e54d9},repository:{dam},handle:{/demo-project/about/subsection-articles/article/content/00/text_files/file},nodeData:{resource},extension:{jpg}}}

This uuid refers to a dam node identifier but should refer to an asset composite key such as jcr:0fa615af-207d-4a45-a3aa-9103d76e54d9

To achieve this, we need to look into 2 areas:
  • CKEditor and our plugin - where we generate such links
  • The link API - where we parse it

The current self-imposed limitation is that assets selected in CKEditor will link to the original asset, not to a variation. Therefore, it shouldn't be too much of a problem to stash the DAM composite key in either of the uuid or handle fields above (although it does seem a bit hackish).

The proposal below is left for reference but is more than what we can handle for 5.3

  │         ↳ since we're in a specific link type, we're free to use whatever attributes we want. Not sure any of the other attributes would make sense in the case of DAM.
  ↳ we introduce different formats per link type (alternatively we keep ${link}, default to the Website links, and add a type attribute)

# in the case of dam links, I see two possible extra attributes: 
  # inline: true/false - a simpler notation for Content-Disposition, somehow passed to the download servlet
  # data: true/false - would generate a regular URI (false), or a data URI (true)
  # come to think of it, these could be a single attribute with several possible values
# perhaps we could keep the extension, as an indicator of the type of link? Or added a mime-type attribute.
# perhaps we could generally add an alt-text attribute (although ${link} is really meant for the hfr


  • No labels