On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <[EMAIL PROTECTED]> wrote: > I totally agree that having the version in the filename and not in the query > string will be a-lot-better. > > Just wanted to point you to that option so you can include it in your > excellent analysis on caching *thanks* :-) > > People can use that option right now and get a more decent version later > (e.g. your versioned resource filenames, which is the *correct* way) > > Resources need some more love in wicket 1.5 - full ack! > And they are going to get it :) Resources are going to be much simpler in 1.5 - current code is too tangled and ambiguous.
-Matej > Cheers > Peter > > > Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger: > >> >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
