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

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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
Proposal, which is probably having to much impact to do in the short term:

 

${dam-link:{key:{jcr:0fa615af-207d-4a45-a3aa-9103d76e54d9}}}
  │         ↳ 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)
# 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
 
qdqwd   
  • No labels