Wrong results of parent #3
Comments
|
Hey, thanks for an excellent report Hannes. I appreciate the clarity and detail! First, would you please check if I'm guessing you're using getResources? Something like where sphtestTpl is the chunk from the top of your post? (I set up a test on one of my sites, so the resource ID numbers will be different than yours, but the idea is the same.) After the resource has been cached, if you look in the cache you'll see it looks something like this: The regular cached calls to setPlaceholders have been evaluated and those placeholders filled in, and what's left is the uncached calls and those placeholders which depend on them. To verify this is in fact what's happening, change your tpl chunk just a little. Make the uncached calls like this: That way you'll see exactly what setPlaceholders is returning each time it's run. You should see that it's actually returning the correct values, but that the placeholders are getting overwritten before finally being evaluated. Does that explanation match what you're seeing? One way to prevent that from happening would be to do something like: That way the prefix changes with each iteration (ex1, ex2, ex3) and you don't have the problem of lots of placeholders with the same name and stuff getting overwritten. Or don't called it uncached, which is probably the best thing. Is there some reason you need to do that? |
|
Thanks for your answer. I really appreciate a sophisticated discussion. One can learn so much. My szenario is not so easy. I have Set up some Categories and the User may select some of the Elements from each category to be represented on his StartPage. Hence my The Chunk My The first works fine, the second does not. It always prints the ID of the last result. But after I changed it to: YES! This helps. A also tried your suggestion for First I thought I am in a hurry, I have to finish my Project, I will answer later, but now I even profit from having answered immediately, the new Way without the nested getResources call saves a lot of resources. Look at this: BEFORE: AFTER: Conclusion: while this Method works at first sight (call without caching disabled): It does not work if the Finally I speedtested the two approaches above. The average load time of cached was slightly faster (testing 100 Page calls). The winer is: regards, Hannes PS.: it shows that this issue is not concerned with setPlaceholders, but I think the result of our discussion is quite useful and should be mentioned in the Documentation. |
|
This is my suggestion for the Documentation, I just took notes for myself in german, here is my translation (it needs some improvment, maybe ;.) ). If This is only necessary if you explicitly set the ID of the resource in question. If you do not use |
|
Hi Hannes, Yes, I'll add a note to the documentation about this; it's something other people might encounter and scratch their heads about :-) Cached resources you can find in core/cache/resource/web/resources/. They're named by resource ID. They're instructive to look at and frequently offer some clues about how to improve performance or about what might be happening when you're trying to understand a problem, like in this case here. Would you be able to send me the whole start page template and all the chunks related to the getResources calls on it? I know you mostly have, but I'm still a bit confused about what you've got set up and why various snippets need to be called uncached. Seems like they shouldn't need to be. There are a few pitfalls with getResources and caching and sometimes you need to use a trick on two in order for things to work properly. Thanks for taking the time to make those performance graphs. They're interesting to look at! |
|
I'll try again: In my template use get Resources to retreve all the symlinks that are in the container. in the CHUNK Referring my screenshot above, The BTW: For the Stats, I use Apache jmeter http://jmeter.apache.org/ . Really easy to use. |
|
Yes, there's a lot of confusion around cached vs. uncached snippets. You'll see plenty of needlessly uncached snippets in code posted in the MODX forums, and even in some documentation. There's certainly a fair amount of confusion out there, so it can be an understandably hard thing to figure out for sure. Most of the time people use uncached snippets, there's no need to. So whenever you see that, it's good to stop and think whether there's any reason for it or not. Things work like this: if the snippet is called normally ( [[snippet]] ), then the first time somebody goes to that page the snippet runs and its output is stored in the cache. Effectively the snippet is replaced by its result, so it's no longer really there in the cache and whenever the page is accessed in the future, it doesn't have to run at all. Until the cache is cleared, at which point things start over. In order to determine which version to use, think about how often that element needs to be updated. Every time the page is loaded, or only when you add/delete/edit something in the manager? For most things it's the latter. You'd need uncached for, say, returning the results of a user's search (if that were cached, everybody would get the same results as the first search until the cache was cleared again). This seems a little strange to me First, since it's inside a getResources call [[+id]] should be [[+idx]]. idx is a placeholder getResources sets. It starts at one and increments with each iteration. [[+id]] is the id of the resource getResources is processing. In this case that would work ok, but [[+idx]] is more correct. Second, you don't need to set a placeholder for id since you already have that number in [[+content]]. In effect you're saying "What's the id of the resource who's id is X?". Well, the answer is always X right? So just use [[+content]] where you would have used [[+sph[[+id]].id]]. Make sense? jmeter does look like a useful tool. I'll have to look into it more. Thanks! |
|
Thanks for the explanation of caching or not. |
|
No, it your case getResources should definitely be cached. The system cache is automatically cleared whenever you add/edit/delete/unpublish/whatever any resource or element. So whenever your client logs in to the manager and changes something, the cache will be cleared and then rebuilt as people visit each page. Almost all of the time snippets should be cached. If you're not sure, cache it :-) Here are a couple of use cases though where you would legitimately call getResources uncached:
|
|
WOW, thank you! That was important. I had a wrong concept of that "Clear Cache" option in the resource. |
|
Going back to your original problem, I came across this blog post the other day which goes into a lot of detail about uncached snippets, placeholders and evaluation order. |
|
Yes, very interesting, good post, thank you! |
In a chunk which is called uncached
<[[!...]]>I unsed setPlaceholders to get some inforamtion from the current Parent resource.I wrote the following HTML to test the snippet after I recived unexpected results.
The result of
<[[+id]]>and<[[+parent]]>always show the right result. From the four setPlaceholders methods only this one had the right result after iterating over three resources from two different Parents:I thougth that all four should output the same result.
Here is the output of iterating over the three resources:
I hope this report will help to improve this handy snippet, I just deleted one of my snippets, because yours is so much better then mine, which had quite a limited approach.
Regards, Hannes
The text was updated successfully, but these errors were encountered: