wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ertl <pe...@gmx.org>
Subject Re: svn commit: r1033843 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/ main/java/org/apache/wicket/resource/ main/java/org/apache/wicket/resource/aggregation/ main/java/org/apache/wicket/resource/dependencies/ main/java/org/
Date Fri, 12 Nov 2010 10:12:47 GMT
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
> <jrthomerson@apache.org>wrote:
> 
>> 
>> 
>> On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson <jrthomerson@apache.org>wrote:
>> 
>>> On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov <mgrigorov@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
>> 


Mime
View raw message