I have not worked on JSPs for a long time and I'm not sure how to approach this issue.
I have this following code which tries to load a stylesheet in a page in the following way-
In JSP-
<link type="text/css" rel="stylesheet" href='<bean:message key="properties.file.key" bundle="propertiesFile" />' />
In propertiesFile.properties file-
properties.file.key=//dummy.website.com/absolute/path/of/cssFile.css
The same css file is downloaded and available locally as well.
Now, I want to fetch the cssFile.css from the dummy.website.com first, if I'm unable to do it (due to various reasons like the css may not be available anymore or the website may be blocked by the browser, etc...), I want to fetch it from the local location. Is there anyway I could do that?
Related
I'm using less for a web-app. In development environment, I have something like
<head>
<link rel="stylesheet/less" type="text/css" href="test.less"/>
<script src="//cdnjs.cloudflare.com/ajax/libs/less.js/3.0.2/less.min.js" ></script>
</head>
this is working correctly: my test.less file is downloaded and converted into valid css by less, automatically.
Now, If the user navigate in a particular section of the site, I need to download another .less file. To do so, I create a element on the fly like this:
<link rel="stylesheet/less" type="text/css" href="test2.less"/>
and append it to the head.
This is NOT working - at least in Chrome 66.0.3359.117 - because the browser is not triggering the file download at all.
I resolved the problem by modifying the link 'rel' attribute:
<link rel="stylesheet" type="text/css" href="test2.less"/>
This way, the browser correctly download the file test2.less; however, it's content is not automatically parsed by less, so it is not converted to valid .css
I think that when less.js is downloaded, it executes by searchings all element with attribute rel = "stylesheet/less" and parsing them - stop.
But after then, it "stops" listening to other .less files downloaded asynchronously.
There is a way to "trigger" less parsing?
Thank you
Ok, so far I've found a solution.
I bet there are more efficient solutions, but for now I'll proceed this way.
I append the element
<link rel="stylesheet/less" type="text/css" href="test2.less"/>
in the head of the document, and this is not triggering the file download.
After that, I call the function
less.registerStylesheets().then(less.refresh);
This is causing less to read again the document, ask for all documents and parsing again them all... not efficient, but it works.
I wonder if exist a method to tell to less to import just a single file...
Edit: a small improvement:
instead of doing
less.registerStylesheets().then(less.refresh);
I can do
less.sheets.push(link);
less.refresh();
link is the reference to the link created. This way less won't read again all the document, searching for links; instead, it will just prepare the XHR for the new link created and parse that.
There may be a better forum for this, but here's my problem:
I'm using several different CDN sites for CSS, jQuery, jQuery Mobile, jQuery.validate, etc. Sometime in the very recent past (last few days) the CSS that jQuery validate uses stopped highlighting the affected text boxes in red, and changing the messages to a red font.
I initially thought it was the addition of blockUI.js & css, but then I noticed that all of my fiddles I created to make the bits & pieces of this project had been affected as well, and none of them had ever had blockUI added to them, so that wasn't it.
Then I thought maybe something had changed in Chrome, so I tried in Firefox, same thing. I have a remote server where I upload test code, and it was still working normally, until I reloaded the page, then the same thing. That tells me that the change occurred in one of the CDN based files.
My question is, since I don't have downloaded versions of each of the .js & .css files, how can I determine what the change was? Is it possible to download the previous version (the version numbers in my references hasn't changed, so there's no way to tell from them.
I know I can simply go create my own .css for the highlighting & font issues, but it seems like whoever hosts these various CDN's shouldn't change them underneath you? FWIW, my primary suspect is: http://jquery.bassistance.de/validate/demo/css/screen.css, especially since it hasn't been versioned. I haven't had a chance to try to verify this yet.
For reference I'm using this array of CDN locations for my current project:
<link href="http://malsup.com/jquery/block/block.css?v3" rel="stylesheet">
<link href="http://code.jquery.com/mobile/1.4.2/jquery.mobile-1.4.2.min.css" rel="stylesheet">
<link href="http://jquery.bassistance.de/validate/demo/css/screen.css" rel="stylesheet">
<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-2.1.1.js"></script>
<script type="text/javascript" src="http://code.jquery.com/mobile/1.4.2/jquery.mobile-1.4.2.js"></script>
<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.12.0/jquery.validate.js"></script>
<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.12.0/additional-methods.js"></script>
<script type="text/javascript" src="http://malsup.github.io/jquery.blockUI.js"></script>
<script type="text/javascript" src="pcbclient.js"></script>
There is no CSS file as part of jQuery Validate. This plugin simply toggles two class names and those have always been .valid and .error.
The root of your problem is right here...
<link href="http://jquery.bassistance.de/validate/demo/css/screen.css" rel="stylesheet">
That's not a CDN link, nor is that CSS file part of the plugin. It's the CSS file used solely for the online demo page.
Everything broke for you because that URL no longer points to a CSS file. However, you should not have been hot-linking to another website's CSS file in the first place. (If it's not a URL from a CDN, it could be considered as stealing the other website's bandwidth.)
If you liked how that online demo page looked, you could have easily examined and copied its CSS properties into your own CSS file, provided that the copyright license allows it.
You might want to carefully review the rest of your file includes' URL's to make sure those are all part of an official CDN and not just hosted on these developers' websites.
It appears I was correct in surmising that the problem laid with the CSS at: http://jquery.bassistance.de/validate/demo/css/screen.css.
I still don't know what changed, but I downloaded the source from: http://jqueryvalidation.org/ (as I should have after deciding to use it), added it to my ASP.NET project and the problem has been resolved.
https://friends-with-you.myshopify.com/
I'm trying to develop my first shopify theme. I'm trying to load a stylesheet which is hosted on another server, but the CSS is not loading. If I copy and paste that CSS directly into a file in the shopify theme, it works.
<link type="text/css" rel="stylesheet" href="http://fwy.pagodabox.com/magic/themes/fwy/fwy.css" />
What am I doing wrong at the above URL, and why isn't the css loading?
thanks!
Can you load your CSS file over both http and https? If so, change your tag to look like this:
<link type="text/css" rel="stylesheet" href="//fwy.pagodabox.com/magic/themes/fwy/fwy.css" />
That way whether a user visits using http://yourstore.com or https://yourstore.com, they'll get the stylesheet served using the protocol they're on (and you won't get any mixed content warnings).
A little more background: http://paulirish.com/2010/the-protocol-relative-url/
Under IE7 and IE8, using this in a <link> tag will result in your content being fetched twice.
Change your link tag to use a secure URL:
<link type="text/css" rel="stylesheet" href="https://fwy.pagodabox.com/magic/themes/fwy/fwy.css" />
^
The URL you're using now works fine on its own, but since you're browsing to the Shopify store over SSL, many web browsers are going to be hesitant to load the CSS over an unsecured connection.
I just checked and pagodabox serves the CSS file just fine over SSL.
In normal HTML documents one can load stylesheets from anywhere, as long as they exist and you're able to load them by typing the URL in (which I can).
I see the page as two navigation bars with a logo on the left hand side. There are hover states with transitions to a colour background on each item. Although, when I loaded the page, Chrome warned me not to load supposedly insecure content. Before this is loaded I just see text in Times New Roman. I think this is you problem.
I use themes with WordPress and style-sheets come with them (mostly). I don't see why you couldn't just put the style-sheet in with the rest of the theme.
Overall, the answer is yes (normally) but in this case browsers may regard it as un-safe and therefore not load it.
Yes you can! But it is faster to host the stylesheet on your server/where the other files reside. If you plan to include a stylesheet from elsewhere, you could run into problems of that server being down/busy and hence your theme will not display as required. As #Blieque mentioned, some browsers may question external content causing unnecessary warning popups to a user/user-agent.
In a Wicket 1.4 app, I have some static CSS & JS resources under [project root]/WebContent/css and [project root]/WebContent/js respectively.
My Wicket HTML files are in src/resources/fi/company/product/pages with corresponding Java classes in src/main/fi/company/product/pages. (In the resulting WAR file, the HTML & property files are of course in the same places as Java classes.)
The HTML files contain references to the resources such as:
<head>
<link rel="stylesheet" type="text/css" href="css/main.css"/>
<script type="text/javascript" src="js/calendar.js"></script>
</head>
This works fine everywhere (or so we thought until recently). NB: my Java code does not reference these resources at all.
Looking at the source of a rendered page (whose URL is e.g. http://localhost:8080/report/42.4 or http://localhost:8080/?wicket:interface=:6:::: ), the resource reference appears as:
<link rel="stylesheet" type="text/css" href="../css/main.css"/>
However, we just noticed that when the app is deployed somewhere else than (Tomcat) root, the resources break on non-bookmarkable pages.
In other words, when the URL is e.g.
http://localhost:8080/foobar/?wicket:interface=:2::::
and a page refers to
<link rel="stylesheet" type="text/css" href="../css/main.css"/>
...the browser tries to fetch the resource at the invalid URL
http://localhost:8080/css/main.css
Now, what is the simplest (yet non-hacky) way to get these static resources working, regarless of the deployment path?
I could switch to using bookmarkable pages exclusively (which would require changing the constructors of the pages), but I suppose that shouldn't be necessary...
Edit: Looks like I got CSS resources working (on most places) simply by using <wicket:link>, as advised in this answer:
<head>
<wicket:link>
<link rel="stylesheet" type="text/css" href="css/main.css"/>
</wicket:link>
</head>
However, now the CSS references are broken on a page with an URL like http://localhost:8080/foobar/report/42.9
Wicket is trying to do something strange with the "css/main.css" path:
ERROR org.apache.wicket.RequestCycle - Can't instantiate page using constructor public fi.company.product.pages.ReportPage(org.apache.wicket.PageParameters) and argument 0 = "css" 1 = "main"
org.apache.wicket.WicketRuntimeException: Can't instantiate page using constructor public fi.company.product.pages.ReportPage(org.apache.wicket.PageParameters) and argument 0 = "css" 1 = "main"
at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:89)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:305)
Edit 2: Actually I'm not sure if <wicket:link> is the right solution here, since these resource files are not "class path resources". I guess my question is, can you make this work while still using web context resources (i.e., without making these class path resources)?
Right, I solved it, and the solution turned out to be very surprising.
Earlier I wrote:
A curious thing is that without any changes, it seems I can no longer
reproduce the problem...
That wasn't quite true, as I had made one small change (that I thought was inconsequential): I had deleted a file WebContent/index.jsp which in our project was a remnant that served no purpose.
Once it dawned on me that this could have fixed it, I did some more testing, and indeed:
For static resources to work as expected, you must not have an index.html or index.jsp file in the root web content directory (i.e., the parent of the CSS and JS resource dirs), as that in some cases breaks ../ references.
This probably isn't even Wicket-specific, but perhaps it is Tomcat-specific—if anyone knows more, feel free to chime in. I'm dubious whether this question ever helps anyone else, but still, glad I got it working!
I got "dump" isp that always cached internet pages and its css for at least 1 day.
Although the css / js in the server changed, the presented css are not changed (i have been clear my cache everytime)
how to "tell" my isp not to cache some files like css and js ?
thank you !!
at the moment: i'm using proxy to check a under developed web so that it don't get cached ..
The way Stack Overflow itself solves this problem is to add a version parameter to the CSS and JS URLs, which refer to the version of the referenced files:
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=4542">
Every time the referenced files change, the href attribute of the link tag is updated in the HTML code, thus supporting caching and updated referenced files.
You could try to append some random string to every request of an external file like:
<link href="/css/style.css?cachekiller=1337" media="screen" rel="stylesheet" type="text/css" />
where the 1337 in the above code should be generated randomly for every request e.g.
<?php time() ?>
or something
You can include these documents directly in your HTML files, between <script> or <style> tags. It will obviously make all your HTML files bigger, but that's basically what you're asking.
It's the only way you can be 100% sure that your CSS and JS is not cached at all.