It might be better if we turn off caching for dmNavigation by default. A lot of stuff goes through dmNavigation, and we can't expect develoopers to update the webskin cache variables every time they change something.
On Tue, Jun 2, 2009 at 2:34 AM, Tomek Kott <[email protected]> wrote: > *sigh* every time I think I understand FC, I don't. I should learn. > > I was so focused on the dmHTML cacheByVars that I forgot that usually the > page gets loaded through the dmNavigation node, and since my rules use a > default of the furl for the actionURL tag, it was calling > "<navigationNodeFURL>/?&page=2" which, of course, was checking against cache > of the dmNavigation, not the dmHTML. Having realized this, and adding > @@cacheByVars: url.page to displayPageStandard of dmNavigation (extended in > my own directory) caused the problems to go away completely. > > Tomek > > > On Mon, Jun 1, 2009 at 7:47 AM, Tomek Kott <[email protected]> wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
