[MGNLSTK-1426] STKTemplatingFunctions: Provide functions to get image variations also for non assets (plain binary nodes) Created: 02/Sep/14  Updated: 06/Oct/14  Resolved: 04/Oct/14

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: None
Affects Version/s: None
Fix Version/s: 2.8.4

Type: Improvement Priority: Major
Reporter: Christian Ringele Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File STKTemplatingFunctions.patch     JPEG File URI2RepositoryMapping.jpg    
Issue Links:
Relates
relates to MGNLUI-3124 SaveUserDialogAction should process s... Closed
causality
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Release notes required:
Yes
Date of First Response:

 Description   

Since 5.x all images used in website scope are not binary nodes, but links to dam:assets form the assets app. The upload possibility was removed.

Problem:
If referencing images not stored in assets there is no possibility to get image variations through the stk imaging generator of non assets.

See:
The contact component doesn't get image variations anymore, as the image is not stored in the assets workspace but directly on the contact itself (mgnl:resource sub node).

Use case:
Any content app deciding to use the DamUploadFieldDefinition in its editor (as the Contacts app does) will not be retrievable when linked to it by the image variations. The imaging model would provide according methods, but this is in many cases not applicable as you might need to extend other model classes as super.

Solution:
Add general functionality to the STKTemplatingFunction providing alike methods as the ImageModel

I added a patch, which works well.
Usage in the component script:

//Possibility 1
[#assign link = stkfn.getImageVariationLinkFromBinary(binaryNode, model)]
<img src=${link!}>

//Possibility 2
[#assign renditionName = stkfn.getRenditionName(model)]
[#assign link2 = stkfn.getImageVariationLinkFromBinary(binaryNode, renditionName)]
<img src=${link2!}>

In order for the image/binary to be resolved, the according workspace has to be added to the URI2RepositoryMapping in the server configuration (see print screen "URI2RepositoryMapping.jpg".
The mapping in the "URI2RepositoryMapping.jpg" is just an example, where I placed an image into the user node (coming from MGNLUI-3124).

Open work:

  • Test cases
  • Java doc


 Comments   
Comment by Christian Ringele [ 02/Sep/14 ]

see last user comment.

Comment by Christian Ringele [ 11/Sep/14 ]

Updated Patch with 2 null checks

Comment by Federico Grilli [ 02/Oct/14 ]

Verify if there's a need for STKTemplatingFunctions.getRenditionName(..) or if we can put the logic therein contained into STKTemplatingFunctions.resolveImageVariationName(..) instead.

Comment by Federico Grilli [ 02/Oct/14 ]

For the release notes/docu

  • a new utility method (with different arg variants) has been added to the class called getImageVariationLinkFromBinary(..)
//Example 1 
[#assign link = stkfn.getImageVariationLinkFromBinary(binaryNode, model)]
<img src=${link!}>

//Example 2
[#assign variationName = stkfn.resolveImageVariationName(model)]
[#assign link2 = stkfn.getImageVariationLinkFromBinary(binaryNode, variationName)]
<img src=${link2!}>
Generated at Mon Feb 12 07:36:27 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.