why the hell would you want to add
something random into _javascript_ and css? those are static 99% of the
time! if it by default appended the last_modified file date i would be
much more impressedbut this is also a bit stupid. The last modified file date is already used for caching resourcesThat
lastmodifiedtime is already set correctly for package resources.The expire header could be set better i guess. But that is a very small penalty because if it expiresit just checks in a head request if the lastmodification time is also changed. If not it doesn't get the file again.
So it for the
Selects should be working with latest svn. Don't forget to clear IE's
cache, it tends to help.
-Matej
Stefan Lindner wrote:
select tag had a problem in Model Dialogs in IE. But it should have
been
solved by now. Try to do a svn update to get the latest model window
code.
I did a svn
To prevent these things from happening, could we add a version number
to the script? So wicket-ajax-1.2.2.js? that would prevent browser
caching from giving support headaches.
For Wicket snapshots, we could generate the current time in milli's as
a version number.
Martijn
On 9/18/06, Matej
+1 for versioned _javascript_. I am seeing more and more people suggest putting something like ?rand=132123 into their css/_javascript_/image urls to avoid this kind of caching.FYI: Ruby on Rails does this automatically for you... =)
On 9/18/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
To prevent
that will be very ugly, what about all the other resources?maybe we can make packagedresource append the wicket version into the url if the file is coming out of a wicket.* package/foo/wicket-ajax.js - /foo/wicket-
ajax.jsver=1.2.2-IgorOn 9/18/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
To
On 9/18/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
+1 for versioned _javascript_. I am seeing more and more people suggest putting something like ?rand=132123 into their css/_javascript_/image urls to avoid this kind of caching.that is idiotic.
why the hell would you want to add
something random
On 9/18/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
that will be very ugly, what about all the other resources?It depends on how it's implemented. there's no reason the version *needs* to be a part of the query string. The query string could just as well be something like:
or better yet append a last mod file date - packaged resources are files after all. in fact dont we already do that when we get HEAD request from the browser?-IgorOn 9/18/06,
Igor Vaynberg [EMAIL PROTECTED] wrote:
that will be very ugly, what about all the other resources?maybe we can make
sure, but that means modifying how we resolve the resources. if you make it a queryparam we dont need to change anything but the part that creates the url-IgorOn 9/18/06,
Ryan Sonnek [EMAIL PROTECTED] wrote:
On 9/18/06, Igor Vaynberg
[EMAIL PROTECTED] wrote:
that will be very ugly, what about
On 9/18/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
sure, but that means modifying how we resolve the resources. if you make it a queryparam we dont need to change anything but the part that creates the urlI'm not saying it'd be worth it, i'm just saying it's an option.
-Igor
On 9/18/06,
Ryan
On 9/18/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
On 9/18/06, Igor Vaynberg
[EMAIL PROTECTED] wrote:
On 9/18/06, Ryan Sonnek
[EMAIL PROTECTED] wrote:
+1 for versioned _javascript_. I am seeing more and more people suggest putting something like ?rand=132123 into their css/_javascript_/image urls
Ok. I'm done herethis is going nowhere, and I guarentee I'm not the only one out there that has run into this issue. It's too bad that this has turned into a mud slinging contest. The Rails team is obviously much more understanding of these issues and how to solve them.
On 9/18/06, Igor
On 9/18/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
Ok. I'm done herethis is going nowhere, and I guarentee I'm not the
only one out there that has run into this issue. It's too bad that this has
turned into a mud slinging contest. The Rails team is obviously much more
understanding of
On 9/18/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 9/18/06, Ryan Sonnek [EMAIL PROTECTED] wrote: Ok.I'm done herethis is going nowhere, and I guarentee I'm not the only one out there that has run into this issue.It's too bad that this has
turned into a mud slinging contest.The Rails team
On 9/18/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
Ok. I'm done herethis is going nowhere, and I guarentee I'm not the only one out there that has run into this issue. It's too bad that this has turned into a mud slinging contest. The Rails team is obviously much more understanding of these
I work on an application that undergoes weekly production releases, so
we've had to implement something very similar for both development and
production modes. There's just too high of risk if the user gets an out of
date version of the javascript.
I see.
The question is, what is the
You might change your production system every week, others might have
release cycles of 6 months. I've seen js files being 200k and more,
why should I want to load them again and again with every request? I
understand it makes sense for development, but for production?
Igor mentioned it is just 5
On 9/18/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
You might change your production system every week, others might have
release cycles of 6 months. I've seen js files being 200k and more,
why should I want to load them again and again with every request? I
understand it makes sense for
I work on an application that undergoes weekly production releases, so
we've had to implement something very similar for both development and
production modes. There's just too high of risk if the user gets an
out of date version of the _javascript_. so why would you not want to cache resources
this is exactly why the file last modified time is the best solution. all these problems and complex usecases just go away. If i release my app every week, that means every week, users will probably be pulling down the _javascript_ and css again even if those files haven't changed. if other users
Just so we're clear, i *never* suggested that _javascript_ and css be reloaded with each request. i just suggested using the random query param as a *possible* solution to get around these caching issues.the file last modified time is by far the most standard and correct solution.
On 9/18/06, Igor
So to summarize:
- add last modified date to packaged resources URI
- set caching header such that the resource never expires
This would be the best solution for all resources? Won't we get
someone from the clean URL brigade to haunt us? :-D
Martijn
--
Download Wicket 1.2.2 now! New Ajax
So basically, we should record server startup time (date) and instead of doing
response.setLastModifiedTime(Time.valueOf(-1));
in Resource.onResourceRequested, line 130, whe should do
response.setLastModifiedTime(Time.valueOf(serverStartupTime));
Correct? Or would we need to do more?
Eelco
IIUC:
we append the file's modification date to the URL of the static
resource, and set the cache header to never expire. This way the
client will only retrieve the resource once. If the resource is
updated, then the modification date changes, and hence the download
URL. The browser *needs* to
I successfully cheched out and built wicket from svn. I use a panel with
a form that contains
- a ListChoice
- a AutoCompleteTextField
Both works well in a normal page. But in a modal window both do not
work:
- the ListChoice is not displayed
- the AutoCompleteTextField triggers no event when a
On 9/17/06, Stefan Lindner [EMAIL PROTECTED] wrote:
- the ListChoice is not displayedselect tag had a problem in Model Dialogs in IE. But it should have been solved by now. Try to do a svn update to get the latest model window code.Frank
ListChoice should be visible in modal window from current svn.
I can imagine autocomplete not working, perhaps the autocomplete div has
lower z-index. Anyway, if you need autocomplete/datepicker/other
javascript components that have absolute positioning, you may need to
use the modal window in
28 matches
Mail list logo
