Hi Peter, I agree for renderXYZResourceReference(), but in this test it uses renderJavascript(String url).
On Fri, Nov 12, 2010 at 11:12 AM, Peter Ertl <pe...@gmx.org> wrote: > Now guess what?! > > You already got timestamps in the url for free (I did some work on caching > recently :-) > > You just have to override > > ResourceReference#getLastModified() > > and return a non-null time value which will automatically become part of > the url... > > The url will look something like this > > <link rel="stylesheet" type="text/css" > href="wicket/resource/my.sample.pages.HomePage/foo-ts1289556202970.css" /> > > With response headers something like: > > Expires: Sat, 12 Nov 2011 10:02:45 GMT > Cache-Control: public, max-age=31536000000 > > So it's cached very aggresively > > Having different urls for the same file (via changing timestamps) will > guarantee it's not already cached when the content changes > > This behavior can be enabled/disable globally by > Settings#setUseTimestampOnResources() > > Also see the javadoc for some explanation > > I also wrote a WIKI entry: > > https://cwiki.apache.org/WICKET/caching-in-wicket-15.html > > > Sample code: > > add(new AbstractBehavior() > { > @Override > public void renderHead(IHeaderResponse response) > { > final HashMap<String,Object> vars = new > HashMap<String, Object>(); > vars.put("url", "http://wicket.apache.org > "); > response.renderCSSReference(new > TextTemplateResourceReference(ShopHomePage.class, "foo.css", new > Model(vars)) > { > @Override > public Time getLastModified() > { > // never cached on re-render > (however this is quite stupid) > // you should only change > the timestamp when the content (-> variables) change > return Time.now(); > } > }); > } > }); > > > > The problem with reusing the same url for different request/responses is > > that the browser (private cache) or public caches can decide to use the > > cached response from previous request and thus the new JSON will never be > > used. Unless there is 'random' parameter in the URL which will solve the > > problem with #wasRendered(). > > > > > > Am 12.11.2010 um 09:10 schrieb Martin Grigorov: > > > Hi Jeremy, > > > > On Fri, Nov 12, 2010 at 12:57 AM, Jeremy Thomerson > > <jrthomer...@apache.org>wrote: > > > >> > >> > >> On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson < > jrthomer...@apache.org>wrote: > >> > >>> On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov <mgrigo...@apache.org > >wrote: > >>> > >>>> Notice that I touched AjaxHeaderContributionPage2_ajax_expected.html > and > >>>> removed expected javascript header contribution after Ajax request. > >>>> I think this is the proper fix because this JS url is already > contributed > >>>> by normal (non-Ajax) page load and it should not be redelivered later > by > >>>> Ajax contributions. > >>>> > >>> > >> So, the strange thing is that what makes this fail is that close() is > now > >> called after the component hierarchy traversal. The fact that it was > not > >> being called before really seems like a bug. But, closing it stops this > >> contribution from being rendered because it is rendered after the header > >> response is closed (and is therefore skipped). > >> > >> So, I have a couple questions: > >> > >> 1. First - is your statement above correct? If I add a css file in > the > >> page, and then contribute the same URL via AJAX, should it be added to > the > >> page a second time? You say no, but it appears that we've been > testing to > >> make sure that it is. I think there could be cases where it should - > what > >> if that URL returns dynamic css (js, etc) that has changed since the > page > >> was originally loaded? It could be JSON, for instance, that has > changed. > >> > >> org.apache.wicket.markup.html.IHeaderResponse.wasRendered(Object) checks > > whether something is already rendered. > > Maybe my understanding is wrong and this method checks only for the > current > > request/response. > > wicket-ajax.js also does some filtering in that area but I have to > re-check > > the code before saying something. > > The problem with reusing the same url for different request/responses is > > that the browser (private cache) or public caches can decide to use the > > cached response from previous request and thus the new JSON will never be > > used. Unless there is 'random' parameter in the URL which will solve the > > problem with #wasRendered(). > > > > About the test itself: for the Ajax request it returns "javascriptB". > What > > exactly is "B"?! Reading the test I cannot explain this right now. > > > >> > >> 1. Second - there's some strange order of operations happening here > >> that's causing this. I am about to walk out the door and haven't had > a > >> chance to fully investigate why this is happening. I wonder why > >> AjaxHeaderContribution2 overrides renderHead(HtmlHeaderContainer > >> container) rather than implementing the normal IHeaderContributor > >> method. Anybody know off the top of their head? > >> > >> Jeremy > >> > >
