Ooops, I could not read the whole thread since I already deleted some of the previous mails :-(
Am 12.11.2010 um 11:36 schrieb Martin Grigorov: > 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 >>>> >> >>
