Skip to main content

Media snippet with description and location path?

Comments

4 comments

  • Holger Höbbel

    Hello Christopher,

    you can get both from the #item respectively the #medium object.

    The description is easy: #medium.getDescription()

    The path is a little more complex, as you have to iterate over the parent chain. Here a possible solution for both (if the folders can be more than 5 elements deep, the array at the beginning has to be defined bigger, e.g. [1..10])

    [1..5].fold(m:[#item], x -> if(m.last.parent==null || !m.last.parent.hasUid(),m,m.add(m.last.parent)))
            .filter(element -> element.uid!="root")
            .map(element -> element.getDisplayName(#global.language))
            .reverse()
            .toString("/") +  
    if(#medium.getDescription().isEmpty(),""," ( " + #medium.getDescription() + " )")

    Best regards,
    Holger

    0
  • Christopher Grothues

    Hello Holger,

    Thanks for the feedback!
    It looks really good, but there is currently a problem in that the path is now displayed twice in ContentCreator (as it seems that both the extract and the path are output in the default setting).
    Unfortunately, I don't currently know how I could provide different snippets in SiteArchitect and ContentCreator.
    I tried it with 

    if(#global.is(class("de.espirit.firstspirit.access.BaseContext$Env").ARCHITECT),"Only displayed in Architect")

    but it didn't work.


    Do you have any ideas about this?

    0
  • Christopher Grothues

    Hello everyone,

    does anyone (other than AI spam bots) have any ideas for a solution?
    Or is this a case for a bug ticket?

    Best regards,
    Christopher

    0
  • Holger Höbbel

    Hello Christopher,

    It is not possible to store different snippets for ContentCreator and SiteArchitect. 
    The fact that ContentCreator and SiteArchitect behave differently is also as expected.
    In this respect, everything is working as expected and there is no error. 

    However, I realise that the behaviour in this particular case is undesirable and not what is wanted. But I am concerned that a bug report will be rejected with the arguments written above.
    In this respect, I recommend that you submit a feature request instead, in which you explain the use case in detail. It would be helpful if you could show why this is an added value for many customers.

    Best regards,
    Holger

    0

Please sign in to leave a comment.