I have a .swf in my rails application, located here:
/public/bin/editor/Editor.swf
It works fine, with one flaw, it gets cached often, so when we release a new version we are usually needing to tell the customers to clear their cache when they experience issues. My question is, how could I force the .swf to break cache when I release a new version? Something like:
/public/bin/editor/Editor.swf?timestamp=124158512132
I tried the above, but it did not seem to work. Any ideas would be great!
if you are using swfobject.js and want the item not be cached you need to add this, to the swf description:
swfobject.embedSWF( 'index.swf ?'+ new Date().getTime()...
of course you can change getTime() to the format you like.
Consider employing a versioning nomenclature to your editor. For example Editor_v1.01.005.swf
Here's a good format
app_major_minor_patch.swf
There are a number of benefits for doing this, and it will also solve your caching issue as well out of coincidence. :)
Related
I developed a project in flex and catalyst and the size of swf is too much, sometimes its take too much time to load. Product is already ready, so i cant change in code too much. Please help me to solve this issue. one more thing sometimes its load very fast and sometimes its take lots of time. Why its like that?
Quick answer is that there's no quick solution. There are several things you can do like caching RSLs (using the Adobe signed one), creating your own RSLs, dividing your application into modules, remove all embedded media and make it load on demand, use vectors (FXG) instead of bitmap files (png, jpg, etc) and make sure you don't add things that aren't needed.
All of these can make an application load faster and be much more responsive. The problem is that it's not a quick solution and needs quite a bit of architecting. Normally, you start this from the beginning of your project. From the sounds of it, you didn't know most of these concepts and you've added everything to one massive swf file (including RSLs).
You've got a long road ahead of you.
Do you have any query made to server? In that case it's better to check the server capabilities.
You're exporting a release build, not a debug build, right?
You can download SWFWire Inspector to examine what's in your file, and why it's so big. Like J_A_X said, it's probably mostly embedded assets, which you can try to load separately.
Disclaimer: I wrote this application
We're making changes to our main sprite and I'm debating the benefits of either changing its name completely or adding a query string to the end.
There's logic to keeping the old version to support Google cache, archive.com, etc., but it'd also be much cleaner on our system if I was to just edit the file and add a query string to the CSS image call:
#element-id { background-image: url('my-sprite.png?version1'); }
My question is, does anyone know of any browser issues with using a query string cache buster in a CSS file?
My suspicion is that browsers handle css image requests the same way whether it's from CSS files or via HTML, so, so long as my server is expressing header information properly I should be OK.
tl;dr Using query params is not a 100% solution.
There are basically two problems when using the asset pipeline:
Making sure your resources get cached when you want them to
Invalidating the cache when you rev the file.
Query string params will sometimes cause networks or browsers not to cache your resource at all. What's more as Mr. Irish points out "the query string approach is not reliable for clients behind a Squid Proxy Server" so it may me unreliable for busting the cache as well. Basically you don't want to have to rely on other peoples configuration.
A couple of references:
Rails Guides: Asset Pipeline - The Rails Asset Pipeline is built on Sprockets a project that has been focused on solving these types of problems for a good few years now. They specifically state in bold no less that "Not all caches will reliably cache content where the filename only differs by query parameters."
Steve Soulders Article on revving assets - Steve Souders is something of a web performance guru and author of the O'Reilly book "High Performance Websites" wrote this article referenced to in the Rails guides that suggests using filename revving to avoid issues with people behind proxy servers.
HTML5 Boilerplate Suggestion - The HTML5 Boilerplate project maintained by the venerable Paul Irish and Nicolas Gallagher use the .htaccess to essentially create a filter to do filename revving. They specifically suggest using filename revving in place of query string versions.
Unless the browser is seriously broken, there should be nothing wrong. Suppose you wanted to use a dynamic file, such as url('/layout.php?section=1') or something. Query strings are kind of required there, so if the browser didn't work it'd be broken quite badly.
The only issue you may run into is css files tend to be cached more than you would probably want. If the output of my-sprite.png?version1 is going to change often, it would be better placed on the page itself.
While developing a website I experience a weird bug.
From time to time my images or my css are missing.
It's not really predictable and therefore not reproducible.
Usually it happens after I edit my css, save it and reload the page (in the browser).
It's always syntactical correct CSS, so no compilation erros or anything similar.
I think it's the way Grails updates the running application, but I really can't say why or where it happens as it is quite rarely, but definitely annoying.
It doesn't matter if I run the application with my IDE (IntelliJ 9.0.4) or with the commandline (Windows).
The only thing I did not test so far is whether it happens only when I use the IDE or not.
Did anyone experience this?
EDIT:
Sorry for an unclear description:
"missing" means the browser is unable to load the corresponding ressource: "The Ressource () is not available"
Another Edit:
Thanks for the comments so far.
In addition to my main css-file and my images, which change quite frequently, my reset-css-file disappeared. I never touched it since creation, so I think one can exclude the compilation-script as cause of this mess. (further info in the comments)
Like John Smith I arrived here googling for this problem.
But I found another solution, and i hope that it helps you too.
I googled a little bit more and found this discussion Disabling static resource stuff, here i found a contributor of grails application, and author of Resources Plugin, Mark Palmer (take a look his website), telling what he is doing and answering the questions about this plugin.
Today, all you need to do is to update the Resources Plugin to version 1.2-RC1 or a recent one that will fix this problem.
When you say missing, do you mean that the changes are missing, or the whole stylesheet is missing? If it is just your latest changes, it is possible that your browser is caching the previous css file and isn't getting the latest changes. Try doing a "hard refresh" with something like CTRL+F5, or whatever hard refresh is in the browser that you are using. This will force a pull of the latest resources.
Really old question.. but for anybody googling this - I had similar issues with my CSS because of Windows file format on the Linux systems. Once I changed the format to unix, I still had to restart the server for the css to download. Note that somehow the css were downloading earlier although the format was windows and the issue was intermittent.
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.
I had an idea for "cheap" version control of the css of one of my sites, but am thinking it may not be a good idea. Thought I'd throw it out here in case someone has a similar idea that works better (besides real svn, etc.)
My thought was to create a main css file like "sitename.css" then use #import inside this file to connect to the most recent file with updates. I'd name these imported files by date, eg: 20101222_css.css so I'd know when the last update was applied. When I have a change, I could make my edits, drop the update in the respective location, change the #import to the new file, and viola... updated on the site.
After reading about issues with #import, such as it loading AFTER the page finishes, I'm not too keen on this now.
Any ideas of a way to implement something similar without a full blown system? I do a lot of small project work for various people and thought this method may be a simple way to keep track of things.
Thanks for any ideas/suggestions.
Your idea would add additional page loads to your site for no good reason, which will be a performance hit. It would also expose your versioning to the outside world. And as you say it will suffer from slow loading speeds due to the way #import works.
But the real down-side of this technique is that it only works for CSS files. You haven't solved the problem for any other files on your site.
You seem to think it would be simpler to use than a real SVN setup, but if you end up coming up with different techniques like this for every type of file on your site, you could easily end up giving yourself more headaches than you solve.
SVN is actually quite straightforward to use. With a good GUI (try TortoiseSVN), it's so easy you almost forget its there. Seriously, use SVN. There's no need to come up with 'clever' alternatives.
Its not a good idea, especially if you push this into production. If you want "cheap" version control, download VisualSVN. Its free.
The guys at Yahoo use a technique that reminds me of what you describe:
<link rel="stylesheet" type="text/css" href="http://l.yimg.com/a/combo?arc/yui/reset_2.6.7.css&arc/yui/fonts_2.6.4.css&[....]/subfooter_0.0.12.css" />
It makes sense for them because it's a caching tecnique. They set HTTP headers so stuff never expires: if you load the site one year later and you haven't removed your browser's cache, you shouldn't need to fetch again any of the files that haven't changed.
However, it's by no means a sensible version control system. You already have a good bunch of real version control systems out there!