I thing we should look at what that append to url does, because i dont like the query string either, i also rather have it in the url path itself.
Also such a resource cache duration can be added. But i also rather have it configured by resoure(reference) like HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod) Johan On 8/29/08, Stefan Fußenegger <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]