Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option.
However, changing filename instead of using query string has certain
advantages, see
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

Furthermore, setting this option does not effect expires or cache-control
headers. still only one hour, which is far from being aggressive. If you
want to change that, you'll still have to explicitly mount all resources
with your desired cache duration.

Johan suggested (comment on 
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
my second article ) "what i can do is make it a setting:
IResourceSettings.getResourceCacheDuration()". If such a setting is
available, using
IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would
make more sense. 

I still think though that this isn't enough and resources should get a focus
in upcoming wicket versions. Some might argue, that resources shouldn't be
served by Wicket at all, but I really don't like to use proxies, CDNs or
whatever voodoo for low traffic web sites: server-side performance isn't an
issue there while client-side performance is.

regards


Peter Ertl wrote:
> 
> That's not true.
> 
> this settings will generate urls like:
> 
>    /resources/[package+class]/javascript.js?lm=[lastmodified]
> 
> read it again : "add Last Modified Time To Resource Reference Url"
> 
>>> getApplication
>>> ().getResourceSettings
>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)    ??
> 
> It will not sent the "LastModified" header as you think.
> 
> So whenever the resource changes the url changes, too.
> 
> Try it out and see :-)
> 
> I did test it in Firefox. There will be no "IfModified" requests from  
> the browser.
> 
> Everything will be completely cached in the browser until the resource  
> has changed.
> 
> Cheers
> Peter
> 
> 
> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
> 
>>
>> honestly, no, I didn't. however, using last modified times still  
>> results in
>> an HTTP request and a "304 Not Modified" reply. better than nothing,  
>> but
>> client-side caching is still preferable.
>>
>> regards
>>
>>
>> Peter Ertl wrote:
>>>
>>> @stefan: did you take into account
>>>
>>>
>>> getApplication
>>> ().getResourceSettings
>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true)    ??
>>>
>>> Cheers
>>> Peter
>>>
>>>
>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>
>>>> sfussenegger now has access to wicketstuff...
>>>>
>>>> i dont know which parts should go into wicket itself, i can tell you
>>>> that the part where you merge the files by listing them out  
>>>> upfront is
>>>> probably not going to make it in because it breaks encapsulation...
>>>>
>>>> -igor
>>>>
>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> I just finished the 4th and last entry of my series "Wicket  
>>>>> Interface
>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>> of my apps
>>>>> with YSlow and started optimizing it's interface rendering speed  
>>>>> [1].
>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>> files, causes
>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>> modify
>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>> (e.g.
>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>> resources
>>>>> at application startup (using a class classed MergedResourceStream)
>>>>> to
>>>>> reduce the number of resources a client has to download [4],
>>>>> including
>>>>> code). I was able to increase interface loading times considerably,
>>>>> so it's
>>>>> surely worth a look.
>>>>>
>>>>> I feel that it would also be worth to discuss, whether this work
>>>>> could be
>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>> make the
>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>> commit
>>>>> access ;) - and wait for your feedback.
>>>>>
>>>>> The links:
>>>>> [1]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>> Wicket Interface Speed-Up
>>>>> [2]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>> Headers
>>>>> [3]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>> [4]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP  
>>>>> Requests
>>>>>
>>>>> -----
>>>>> -------
>>>>> Stefan Fußenegger
>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> -- 
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: 
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to