url.page is in my @@cacheByVars list, that is why I'm confused. I am using /types/displayPageStandard, which has <!--- @@cacheByVars: url.page,url.month,url.year ---> (I've even set displayBody on dmHTML with the same settings)
I check the application.stCoapi['dmHTML'].stWebskins['displayPageStandard'] structure and it has, under cacheByVars, the value url.page. So by that understanding, every single HTML page should be cached using url.page as a hash. Everything is the same for the rule ruleEventsCalendar and the webskin displayTeaserCalendar (<!--- @@cacheByVars: url.page,url.month,url.year --->). Neither setup works, whether I go directly to the url for the dmhtml (such as /dmhtml/myhtmlpage) or to the navigation that has the proper dmhtml as the first child. Neither setup actually caches the page separately. It does so once, on the first load, and I can see in webskinCacheID page:2 as expected, but then every subsequent call goes to that webskin no matter the value of page. So something along the line is going wrong, and I have no idea where that might be. Tomek On Mon, Jun 1, 2009 at 4:24 AM, Mat Bryant <[email protected]> wrote: > It sounds like you need to add url.page to the @@cacheByVar list > > Basically, any variable referenced in the webskin which will change the > html rendered by the webskin needs to be added to the list. You state that > clicking page=1 is no different to page=2. That is correct, because as far > as the caching is concerned, url.page has no impact on the webskin. > > You need to tell the webskin that url.page has an effect on the webskin. > > -- > -- Matthew Bryant > Product Development Manager > Daemon Internet Consultants > Adobe Solutions Partner > http://www.daemon.com.au/ > p. 02 8302 4600 > f. 02 9380 4204 > > > > On Mon, Jun 1, 2009 at 1:19 PM, Tomek Kott <[email protected]> wrote: > >> to expand, basically, the first call to the page creates the base view. If >> i click on the page=2 button, things load up correctly. Clicking on page=1 >> does nothing, simply loads up cached page=2. This is consistent after >> resetting application. >> >> Should I just try cacheByURL instead? >> >> Tomek >> >> >> On Sun, May 31, 2009 at 11:03 PM, Tomek Kott <[email protected]>wrote: >> >>> hmm, I should rephrase that. It appears that those variables two are now >>> getting picked up in the metadata, as they should. Additionally, in the >>> application.objectbroker['ruleEventsCalendar'].stWebskins['displayTeaserCalendar'] >>> , I can see two objects, one with nothing in the webskincacheid, and the >>> other with: >>> stParam[AEVENTS]:{complex},stParam[BALLOWTRACE]:true,stParam[QEVENTS]:{complex},url.month:06,url.year:2009, >>> >>> which seems to imply that its picking up the caching variables (along >>> with some I did not set), but it is not caching it correctly. This is after >>> resetting the application. >>> >>> I know that the url parameters are getting picked up by the webskin (i >>> have <cfparam name="url.month"> with a default value within the webskin of >>> the 'displayTeaserCalendar', since it's getting dumped with a var="#url#" >>> call. However, if caching happens before the webskin is called, then it >>> wouldn't catch the url values. >>> >>> In either case, I've noticed that the rules I have which output a page >>> reference (<ft:pagination>) are also not getting cached correctly, even >>> though these are explicitly set to cacheByVars using fapi.setCacheByVar etc. >>> >>> >>> I guess all of that is to say I'm now even more confused as to what's >>> going wrong than before. >>> >>> Any further ideas would be great on how to trace this down. >>> >>> Tomek >>> >>> >>> On Sun, May 31, 2009 at 8:55 AM, Tomek Kott <[email protected]>wrote: >>> >>>> the problem is tha it should be cacheByVars, plural vars! >>>> >>>> I'll update the wiki when i get the chance. >>>> >>>> >>>> On Thu, May 28, 2009 at 7:18 PM, Blair McKenzie <[email protected]>wrote: >>>> >>>>> As far as I know that should work. I'll pass the question along to the >>>>> guy who wrote it. >>>>> >>>>> >>>>> On Fri, May 29, 2009 at 2:13 AM, Tomek Kott <[email protected]>wrote: >>>>> >>>>>> So I tried putting >>>>>> >>>>>> <!--- @@cacheStatus: 1 ---> >>>>>> <!--- @@cacheTimeout: 1400 ---> >>>>>> <!--- @@cacheByVar: url.year,url.month ---> >>>>>> >>>>>> and updating the app, but the caching still doesn't work. Do I need >>>>>> >>>>>> <!--- @@cacheStatus: 1 ---> >>>>>> <!--- @@cacheTimeout: 1400 ---> >>>>>> <!--- @@cacheByVar: "url.year","url.month" ---> >>>>>> >>>>>> or something? Or is there another way to add to the cacheByVar scope? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Tomek >>>>>> >>>>>> On Wed, May 27, 2009 at 7:42 PM, Blair McKenzie <[email protected]>wrote: >>>>>> >>>>>>> You would need to specify url.year, etc. >>>>>>> >>>>>>> The caching stuff can only use variables in a scope (e.g. >>>>>>> application, form). These variables are used to check the cache before >>>>>>> the >>>>>>> webskin. There is no way around that, as the goal is to avoid running >>>>>>> the >>>>>>> webskin unnecessarily. >>>>>>> >>>>>>> Blair >>>>>>> >>>>>>> >>>>>>> On Wed, May 27, 2009 at 12:43 PM, Tomek Kott >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I'm a little confused by the cacheByVar implementation. I am trying >>>>>>>> to use it on the displayEventsCalendar rule page, and the two >>>>>>>> variables that >>>>>>>> I want to hash on are the 'month' and 'year' url variables. so I just >>>>>>>> did >>>>>>>> the naive thing >>>>>>>> >>>>>>>> <!--- @@cacheByVar: year,month ---> >>>>>>>> >>>>>>>> That didn't seem to work by putting in the displayEventsCalendar. At >>>>>>>> which level of the caching mechanism do I need to put that code in? >>>>>>>> Does it >>>>>>>> go in that file (which is a rule display page) or does it go in the >>>>>>>> dmHTML >>>>>>>> page that holds it, or the container, or do I need to do url.year and >>>>>>>> url.month as the variables, for example? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Tomek >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message cos you are subscribed to "farcry-dev" Google group. To post, email: [email protected] To unsubscribe, email: [email protected] For more options: http://groups.google.com/group/farcry-dev -------------------------------- Follow us on Twitter: http://twitter.com/farcry -~----------~----~----~----~------~----~------~--~---
