I know that with Resources, you can do things dynamically without knowing the name or id of the Resource and print out values for the resource’s Title, template, alias, etc using:
[[*pagetitle]]
[[*template]]
[[*alias]]
How is this accomplished with Chunks and/or Snippets without knowing their name or id?
If you just want to display the content of a chunk or the return value of a snippet, you use this:
Snipppets: [[SnippetName]]
Chunks: [[ChunkName]]
In you want a specific field of a chunk or snippet, you need to call $modx->getObject().
In the first case, you need the name of the chunk or snippet. In the second, you need the name or ID. MODX has no way of knowing which chunk or snippet you need unless you provide a name (in the case of tags) or an id (in the case of getObject() calls).
@bobray Thank you for your quick reply!
Needing to know the name or ID is what I was afraid of. I was hoping that there was something in the code that I have overlooked where I didn’t need to know the name or ID. Ideally, when writing a chunk or a snippet having that chunk or snippet know its name or ID would help a lot.
For example, if my chunk were called “MyChunk” and its ID were 3 - I would like to write this into “MyChunk”:
And wherever I call “MyChunk” it would print out:
Name of this chunk: MyChunk
ID of this chunk: 3
If that is not possible, then my suspicions are correct and I have not overlooked anything in the MODX code. I’ll just have to think on an alternative route…
This will print the content and ID for snippets, but I still can’t find anything for chunks.
print_r($this->_content);
print_r($this->id);
Try this:
On the properties tab when editing the chunk, add two properties
Name: MyName
Value: Chunk’s Actual Name
Name: MyId
Value: 12 (Chunk’s Actual id)
Then add these tags to the chunk:
My Name is [[+MyName]]
My ID is [[+MyId]]
That would definitely work to accomplish the task. Thank you for the advice @bobray !
Perhaps I should suggest a Feature Request so that users do not have to go the Property Set route, but instead, have something more dynamic like what is done with the Resources.
I think some short tags for chunks and snippets would be nice because the chunk and snippet should be aware of itself via short tags, like [[+chunkname]], [[+chunkid]], etc.
I’m curious. Can you explain why you need this? I can’t think of a use case for it.
I was looking at someone’s support web page and they had the same form multiple times on that page. It was “Did you find this information helpful?” forms.
The support page had different sections of different types of help. Each section was a MODX chunk. Inside each chunk was a formit snippet. Each formit needed some uniqueness added to it, like the Formit submitVar & successMessagePlaceholder. The form code also had some elements that needed to be unique as well.
Since each section was a chunk with almost identical formit snippet calls and form code, I had originally thought to see if MODX chunks had short tags that could identify itself. Then I could give the formit snippets and form code some uniqueness. My thoughts were to do something like this with formit snippet call and place [[+chunkname]] where needed, since MODX Chunk names are unique:
[[!FormIt?
&hooks=`FormItSaveForm,spam`
&formName=`Page: [[*alias]]`
&store=`1`
&validate=`nospam:blank`
&submitVar=`submit_ynform[[+chunkname]]`
&successMessage=`[[$tpl_support_successMessage]]`
&successMessagePlaceholder=`successMessagePlaceholder[[+chunkname]]`
&formFields=`helpful,section,url`
]]
I grew past that thought after realizing that the “Did you find this information helpful?” forms are going to be added to other pages multiple times. So, I settled upon writing a snippet called support_formit
because the Formit snippet call, form code, design, and functionality were going to be the same for each form. Calling one snippet that is going to do the exact same thing multiple locations throughout the website seemed to leave less room for error and design inconsistency.
The new snippet call is simply:
[[!support_formit? &form_section=
support_topic_1]]
Where the form_section value can be whatever you want when applying it to the help sections. The form_section just needs to be unique so that the functionality works specific to the section of the web page where the form is submitted.
Then you can see an example of how I use the snippet and the value of form_section when making a formit snippet call:
[[!FormIt?
&hooks=`FormItSaveForm,spam`
&formName=`Page: [[*alias]]`
&store=`1`
&validate=`nospam:blank`
&submitVar=`submit_ynform<?php echo $form_section; ?>`
&successMessage=`[[$tpl_support_successMessage]]`
&successMessagePlaceholder=`successMessagePlaceholder<?php echo $form_section; ?>`
&formFields=`helpful,section,url`
]]
I am sure that I could think of other ways why having short tags, like [[+chunkname]], [[+chunkid]], etc., for chunks and snippets would be useful. But my original thought is detailed above why I thought it would be useful at the time.
Thanks. That makes sense.
Bob
I just read your article about creating properties on a chunk. Very interesting. So I thought I’d give it a try.
I added these properites.
Then I added this inside the chunk.
[[+data1]] - [[+data2]]
However, the data is not displayed on the front-end. I must be missing something.
Is the TV connected to the Template of the page being displayed?
Are you using a chunk tag to pull in the chunk?
What TV?
I thought these [[+data1]] and [[+data2]] were pulling the info from the values in the chunk properties.
Do you call the chunk with the correct property set?
[[$somechunk@test]]
(The name of your property set seems to be “test”, based on the screenshot above.)
Otherwise the values from the default property set are used.
OK, got it.
I didn’t reference in the tutorial about calling the chunk that way. I’ve never seen that before.
Just out of curiosity, can the values in the properties be dynamic in any way, template variable, resource id, etc.?
Thanks. I learned something new today.
If you set the value of a property to a MODX tag like [[*my_tv]] or use syntax like this
[[$somechunk?
&data1=`[[*my_tv]]`
]]
then the MODX parser should (eventually) output the value of the corresponding TV.
Very cool. I didn’t know any of this.
Thanks.
My questions made no sense due to jetlag and lack of sleep. I’m glad you got it sorted. 