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:51:24 GMT
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 <pertl@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
>>> <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