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]
