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 6 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 below, which is probably having to much impact to do in the short term.
Anyway... the below doesn't really solve everything. My gut feeling is that we're overlooking the imaging integration with CKEditor. The simple cases where one links to a document such as a pdf in a rich text field are covered, but isn't the most common case the one where we select an image ? And in that case, there's a good chance you actually want to display a resized image rather than link to the original.

 

${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, 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