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