We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 7455
    • 2,204 Posts
    I like to make a call like this:

    {{chunk_[[UltimateParent]]}}

    I have a chunk called "chunk_1"

    so the result schould be the content of chunk_1, when I am on a page below that ultimate parent with id1
    But i get nothing out of it. does a chuck gets parsed before or after a snippet?

    I tryed this: {{chunk_[*tv*]}}, and that works great but I do not need a tv for this one just a chunk.

    is there a solution for this?

    Thanks

    Dimmy
      follow me on twitter: @dimmy01
      • 33337
      • 3,975 Posts
      AFAIK, recursive parsing is not supported 100% yet.

      Try this {{chunk_{{UltimateParent}}}} , and place [[UltimateParent]] in {{UltimateParent}}. I am not sure if it will work though tongue

      regards,

      zi
        Zaigham R - MODX Professional | Skype | Email | Twitter

        Digging the interwebs for #MODX gems and bringing it to you. modx.link
      • @zi -- that will probably not work, as we do not support nested tags of the same type currently

        @Dimmy -- chunks are processed first and I believe that will simply remove the snippet call inside the tag when no chunk with that name is found (the parser assuming the actual chunk name includes the snippet call since it’s not processed first). Try using a TV instead of a chunk, if practical in your site; that might actually work. If not, you could use a TV with a value something like this:

        @EVAL if ($output= runSnippet('UltimateParent')) echo $output;


        @ALL -- The MODx 1.0 roadmap will reveal a solution to this situation, allowing virtually unlimited tag nesting capabilities (with a configurable depth limit), and a parsing order based on tag order within the content (or in special cases, based on a sort_index field that can be used for various purposes with any type of MODx component).
          • 7455
          • 2,204 Posts
          Quote from: OpenGeek at Mar 31, 2006, 05:14 PM

          that will probably not work, as we do not support nested tags of the same type currently

          mm calling a snippet in a snippet call works fine if you do it like this;

          [!snippetcall?blabla=[[2ndsnippetcall]]!]

          take a look at this post:

          http://modxcms.com/forums/index.php/topic,3687.msg26786.html#msg26786

          greets Dimmy
            follow me on twitter: @dimmy01
          • Quote from: Dimmy at Mar 31, 2006, 06:37 PM

            mm calling a snippet in a snippet call works fine if you do it like this;

            [!snippetcall?blabla=[[2ndsnippetcall]]!]
            Indeed. It works since you are using different tags for the nested snippet and kind of tricking the parser by forcing the outer tag call to be parsed last as an uncached snippet, while the nested one gets parsed only during document generation from the db.
              • 32241
              • 1,495 Posts
              To help understanding Jason reply, check this code below.

              			// combine template and document variables
              			$source = $this->mergeDocumentContent($source);
              			// replace settings referenced in document
              			$source = $this->mergeSettingsContent($source);
              			// replace HTMLSnippets in document
              			$source = $this->mergeChunkContent($source);
              			// find and merge snippets
              			$source = $this->evalSnippets($source);
              			// find and replace Placeholders (must be parsed last) - Added by Raymond
              			$source = $this->mergePlaceholderContent($source);
              


              That’s the order of how MODx parser parsed all the corresponding tag. If you use document content/chunk/setting variables inside a snippet calling as a parameter for that specific snipet, than it’s theoritically will work. It all depends on the order of which one will be parsed first. In this case all document content, chunk, and setting variables will be parsed first before parsing snippet. So basically by the time the parser try o parse the snippet tag, all the previous chunk, document content, and template variables had been parsed before hand and substitued with the right value, so it will work.

              Example usage that work
              [[snippet_name? &param=`[*tv_name*]`]]
              [[snippet_name? &param=`{{chunk_name}}`]]
              {{[*tv_name*]}}
              


              Example usage that won’t work
              {{[[snippet_name]]}}
              [*[[snippet_name]]*]
              


              Another thing to note, when combining 2 snippets calling. If you use the uncached format [!snippet_name!], it will always being parsed the last. So if you have:
              [!snippet_last? &param=`[[snippet_param_name]]`!]
              

              It will works just fine.

              In fact, you can use it like this.
              [!snippet_last? &{{chunk_param_name}}=`[[snippet_param_name]]`!]
              or
              [!snippet_last? [[snippet_that_generate_dynamic_param]]!]
              


              Hope it does help some of you guys without confusing you guys more about MODx parser wink
                Wendy Novianto
                [font=Verdana]PT DJAMOER Technology Media
                [font=Verdana]Xituz Media
                • 7455
                • 2,204 Posts
                Thanks for the clear explenation of the pars order. would be nice to have a recursive parser to see if an element contains another element that needs parsing first. But I think that this is already worked on by the team?
                  follow me on twitter: @dimmy01
                • Quote from: Dimmy at Apr 01, 2006, 10:11 AM

                  Thanks for the clear explenation of the pars order. would be nice to have a recursive parser to see if an element contains another element that needs parsing first. But I think that this is already worked on by the team?
                  That’s correct Dimmy; I have a full recursive parsing implementation and it is coming in 1.0 (i.e. parsing nested tags as well as having each element process any tags contained in it’s own output), along with some other great features, further simplifications in tag syntax, and much more to be revealed after this next 0.9.x release.
                    • 10318
                    • 10 Posts
                    Can anyone give me a rough ETA on MODx 1.0?
                    • Quote from: FusionStudios at Jun 09, 2006, 06:34 AM

                      Can anyone give me a rough ETA on MODx 1.0?

                      It will most likely be available, at least in a preview stage around August/September; but, as with most open source projects, that timeline depends on too many factors to accurately estimate, including, but not limited to, the amount of bandwidth I have to work on it. Of course, large donations to the project (time, money, docs, code, forum moderation, etc.), client projects which help fund development of 1.0, and other similar contributions always help keep the timeline moving along more quickly.
                      8)