New Community Forums are coming. Watch this space for news.
Subscribe: RSS
  • I'm glad there's a workaround fo rthis issue, but it remains an issue. Chunks called from within a getResources template are not processed correctly. I wanted to use getResources to greate a list of documents for gallery. Here's a great example of why one owuld need a chiunk inside a tempalte: the gallert gets its' title and description through teh title attribule fo the "a" link. If you want to apply html to the titel and description in the gallery (colorbox, for example), you need to escape the html propery. I've done it this way:

    [[$galItemNameAndDescr:htmlent? &idx=`[[+idx]]`]]


    where the chunk galItemNameAndDesc looks like this:

    <p class="galItemTitle">[[+name]]</p>
    <p class="galItemDesc">[[+description]]</p>


    In the getResources template, this is used thusly:

    <a class="cboxgal" rel="colorboxLSP{[[+album]]}" href="[[+image]]" title="[[$galItemNameAndDescr:htmlent? &idx=`[[+idx]]`]]" alt="[[+name]]">

    <img class="[[+imgCls]]" src="[[+thumbnail]]" alt="[[+name]]" />

    </a>

    This allows me to pass html into colorbox, and it's impossible to do so without a chunk in the template.

    The above workaround by adding a fake variable idx does fix this problem.
      Revo 2.0.8-pl
    • Thanks OpenGeek... you just helped me solve a problem with an issue with a cached chunk in a getPage call!
        "Give a company a website, and they will be successful for now...
        Give a company a long-term web strategy, and they will be successful for a lifetime."

        Company Website: http://www.orbitalalliance.com
        Company Blog: http://www.orbitalalliance.com/blog
      • Quote from: opengeek at Mar 14, 2012, 09:45 AM

        You need a unique tag string for each iteration as any tag that is parsed with the same property values is cached and all instances replaced on the Resource from the first execution. Try adding a dummy property to the tag, like so...

        [[$image-news? &idx=`[[+idx]]`]]


        And this way you can also call it cacheable, since each run is unique.

        Thank you! Thank you! Thank you! Thank you! I've been banging my head on this issue tonight for longer than I'd care to admit. (Now I can move on to banging my head against other issues wink)

        I am curious about the reasoning behind this behavior. It doesn't cache the placeholder values in the enclosing chunk on each iteration, so why should it cache the placeholders in the nested chunk (or is it caching the included chunk entirely, but still,the enclosing chunk isn't being cached on each iteration)? Why doesn't indicating that the chunk shouldn't be cached work the way that one would expect? What would happen if the nested chunk had another chunk nested inside of it? (gonna try this one out and see if you have to propagate the dummy property down..). I'm wondering if this is a bug?
        • Quote from: opengeek at Mar 14, 2012, 07:43 PM
          There is no need to escape backticks; the tags are processed from the most deeply nested out...

          This is admittedly an edge case since most developers probably don't inline much JavaScript, but ES6 uses the backtick for template strings
          https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings#Expression_interpolation

          var a = 5;
          var b = 10;
          console.log(`Fifteen is ${a + b} and\nnot ${2 * a + b}.`);
          // "Fifteen is 15 and not 20."
          


          Without a way to escape the MODX parsing of backticks, I don't think you could use expression interpolation within MODX templates without triggering the MODX parser.
            jpdevries