While I'm looking into things, this is the response from the server admin: > We do have java compiler caching turned on. Therefore the page code > doesn't get recompiled to a class every time the page loads. > (Performance would be very poor if we recompiled every page load - when > we clear the class cache, the server starts out very slow, and gains > speed as the cache is populated) We don't have content caching on as far > as I know. If the admin view relies on being differently compiled, that > may be the reason that you see the view.
So I don't know if that has anything to do with things...again, not a server admin myself. Though I can't see how it would effect anything, since the code itself stays the same, it is the running through the code etc that changes with the variables. Tomek On Tue, May 26, 2009 at 10:44 PM, Tomek Kott <[email protected]> wrote: > Thanks Blair for that explanation. I'll take a look at nj:display and > associated js code, and we'll see what I can find. > Tomek > > > On Tue, May 26, 2009 at 9:50 PM, Blair McKenzie <[email protected]> wrote: > >> The first issue shouldn't be a FarCry cache issue because the tray stuff >> is not inserted as part of a webskin. The display.cfm tag adds it after >> retrieving the HTML (from cache or dynamic, it doesn't know). Do you have >> any other levels of caching going on? >> >> The tray itself is updated by the same routine. It adds JS to >> a) redirect to tray.cfm / call a function on the parent to update the tray >> iFrame as appropriate or >> b) show the big tray icon. >> >> Possible causes of the error: >> - the page itself is cfabort'ing before the JS can be added >> - JS on the page is erroring out and buggering up the tray JS >> - something is wrong with the function in tray.cfm that updates the tray >> iframe >> >> Look for parent.updateTray in the page source. >> >> Blair >> >> >> On Wed, May 27, 2009 at 11:33 AM, Tomek Kott <[email protected]>wrote: >> >>> Hi FarCriers, >>> >>> I just upgraded to FC5.1.4, and while I really like the new admin tray >>> (it's much nicer to edit in place etc), it is caching itself along with the >>> page. Essentially, if I am logged in as an admin, using the tray, and click >>> flush cache, the tray gets cached. So when I try to look at the page with a >>> normal user (either through another browser or on a different machine), it >>> first seems to load the page, but then forwards the page to the tray view, >>> which of course reverts to the login page. >>> >>> It is highly reminiscent of the caching problems I have seen with the old >>> tray as well. Since no one else has ever seemed to have the same problem, I >>> am at a lost to explain how this could come about. I know that the kind >>> folks at Daemon tried to reproduce my first error, but I was wondering if >>> anyone had any clues as to what could be causing that. Should I ask about >>> trusted caching in the shared host? Any other clues I can use without access >>> to the ColdFusion server? >>> >>> The second problem I am having is that when the tray is being used, it >>> occasionally disappears. So I might click on show containers (or whatever >>> its called) and it will update the page, but the task bar will disappear. >>> The frame for it is still there, but there is no code present at all. I am >>> wondering if these two things are related. I know that I saw this on my dev >>> server as well, but I mostly figured it was the klutzy jrun + cf server that >>> I was running. >>> >>> TIA, >>> >>> 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 -~----------~----~----~----~------~----~------~--~---
