Page History
...
- 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.
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
${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
Overview
Content Tools