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]

Reply via email to