Apologies if the following already has been addressed in the MODX forums. I could not find my particular Q&A there, nor in the usual Bob / Mary / Mark etc. MODX guru sites.
I have created a getResources call that provides the desired result, and with satisfactory performance. However, I worry that responsiveness will suffer as the number of resources grows.
I can't cache the call naïvely because it returns a result that is time-dependent.
The call pulls a list of Event resources. It uses a TV, eventDate, to order the list. The "tvFilters" and "limit" arguments work together to discard all but one resource, the Event whose eventDate indicates it is to occur next in the future.
I imagine that the uncached getResources call (See below.) must do a ton of work in order to return that single Event. It's a shame not to cache it, considering that the call's result doesn't change very often. Yet I don't see how to guarantee the correct result unless the call runs uncached.
I'd like to "pay" for pulling and sorting the Events just once (i.e., cache that intermediate result), then compute uncached the sole result Event.
Improvement ideas anyone?
Here's the code:
[[!getResources:default=`<h3>
Information on future events is currently unavailable. Please check again later.
</h3>`?
&parents=`6`
&showUnpublished=`1`
&showDeleted=`0`
&includeContent=`1`
&tvPrefix=``
&includeTVs=`1`
&processTVs=`1`
&tvFilters=`eventDate>>[[currentDatetime]]`
&sortbyTVType=`datetime`
&sortbyTV=`eventDate`
&sortdirTV=`ASC`
&limit= `2`
&tpl_1= `home_news_or_event_RenderTpl`
&tpl_2= `homeMainEventsLinkTpl`
]]
BTW, the use of
may seem strange. It and the "default" argument form a hack to cope with the possibility that there may not be any yet-to-occur Events among the targeted resources.
☆ A M B ☆