scope of snippet code & best practices

I have several different snippets in my templates that all rely on the return value of another snippet, "getDepartment". Right now each of the snippets that needs that value calls getDepartment... resulting in multiple calls to getDepartment per page, even though its always gonna return the same value on a given page.

I’m not the sharpest knife in the drawer, but I can see where that isn’t very efficient. So I set out to determine how to write it more efficiently.

Since my templates are based on nested chunks, starting with an outermost [[$html]] chunk, I think the most logical/mainstream solution is to do the following:

• Change the template code to [[$html? &dept=`[[getDepartment]]`]]
• Change the calls of the snippets that need that value to [[someDeptSnippet? &dept=`[[+dept]]`]]

Setting the value of $dept in the outermost chunk call should set all the [[+dept]] placeholders, effectively passing $dept as an argument to each snippet. (Right?)

So my question is, is that the best solution? Or is there a better one?

Now my constructive feedback.

It isn’t at all clear to me from reading the documentation on Snippets and Using Snippets that each snippet is saved/cached/access as a function... and has the scope limitation of a function. On first glance at how MODx appears to work, I was under the wrong assumption that I could write & use snippets in the manner that I used to write bad mixed HTML & procedural PHP... define a value $x in one PHP block, then have some HTML, then have another PHP block where I might, say, call a function and pass it the value of $x as an argument. This doesn’t work though, when each block of PHP is itself a function. It took me a long while of wandering in the wilderness to figure that out.

My suggestion, then, is to add something to the core documentation about snippets that 1) addresses the fact that they are going to be converted to functions, and all of the ramifications of that, and 2) provides some direction on how to pass values in the manner I’m looking to do up above. I think this would make the concept of snippets a lot more accessible & less mystical.

I’m not completely sure what you’re trying to do, but I think you might want to set a $_SESSION variable, which will be available to all the snippets. Also, chunks don’t take arguments, only snippets do.

Another method (in Revo) might be to create a property set containing the values you want and call the chunk with. The properties will be available as placeholders in the chunk and can be passed to the snippets as arguments:

What I’m trying to do is basically to get a bunch of TV values from a parent resource (not necessarily the direct parent... my function finds the right resource), and use them in various places (snippets) on the page. I’m pretty sure I answered my own question, that the alternative to running the "getDepartment" snippet over and over everytime I need one of the TV values is to call it in an outer/wrapper snippet and then pass it as an argument to each inner snippet that needs it.

Also, chunks don’t take arguments, only snippets do.

In Revo chunks can take arguments. I do it all the time and it works great.

Another method (in Revo) might be to create a property set containing the values you want and call the chunk with.

I don’t know if property sets would do what I want to do. Mainly because I need to run the getDepartment snippet to get the value. Can a property set contain a snippet ... use the return value of a snippet as one of its properties? My hunch is ’no’ - but MODx has surprised me many times before on things like this.

Not sure if this will work in Revolution, but in Evolution I’ve used a define():

header snippet - called at top of template


Then just use DEPARTMENT in your other snippets

Placeholders are what I use to share any kind of data between Snippets in a single request, along with techniques like loading objects on demand if they are not available as a placeholder. This allows for very flexible and fine-grained approaches to caching and order of processing.

Quote from: jrotering at Jul 07, 2010, 08:49 AM

In Revo chunks can take arguments. I do it all the time and it works great.

I stand corrected. I should have realized that they would since all elements get properties in Revo. I never thought to try it.

Quote from: BobRay at Jul 09, 2010, 12:44 AM

Quote from: jrotering at Jul 07, 2010, 08:49 AM

In Revo chunks can take arguments. I do it all the time and it works great.

I stand corrected. I should have realized that they would since all elements get properties in Revo. I never thought to try it.

In fact, the real benefit of passing properties to Elements like Chunks (or TemplateVariables, etc.) is that they are automatically set as placeholders only within the scope of execution of that Element, though this does include any Elements nested in the tag string or returned in the output of the Element. Any placeholders with the same keys that exist prior to the execution of the Element are restored to their original values afterwards.

Any placeholders with the same keys that exist prior to the execution of the Element are restored to their original values afterwards.

Let me see if I understand that correctly. Lets say I have two chunks:


outerchunk:


innerchunk:


And I make this chunk call:


This is the output I’d expect to see:


First, am I correct that that should be the output?
Second, is the fact that the final ph2 value = y, rather than z... is that an example that supports the point you are making in the sentence I quoted?

Quote from: jrotering at Jul 09, 2010, 12:55 PM

This is the output I’d expect to see:

<p>outer ph1 value: x</p>
<p>outer ph2 value: y</p>
<p>inner ph1 value: x</p>
<p>inner ph2 value: z</p>
<p>outer ph1 value: x</p>
<p>outer ph2 value: y</p>

First, am I correct that that should be the output?
Second, is the fact that the final ph2 value = y, rather than z... is that an example that supports the point you are making in the sentence I quoted?

You are correct on both your first and second points.