What are the advantages of using <h:graphiImage> over normal <img> (in terms of performance e.g. parse/render time, possible http caching if any?, etc.) for JSF2?
You don't get server-side attributes on <img> elements.
There is no safe and easy way to set an absolute path for the src attribute. This is important because you may well be referencing the same image from multiple pages that reside in different directories. Would you want the hassle of maintaining their relative location? Sure, you can use <img src="#{resource['images:myImage.png']}"/> to get a safe absolute path. Wouldn't it just be easier to use <h:graphicImage name="myImage.png" library="images"/>?
What's this about a "safe" absolute path?
You could leave your images outside the usual resources folder and specify them in an absolute path like this, for example: <img src="/myApp-web/faces/images/myImage.png"/> and that would work. But then what happens when you want to deploy your app? Do you want your URLs to be like http://www.mysite.com/faces/myPage.xhtml? Of course not. You want to set the context root to the server root. But you don't want the hassle of changing all your img tags for a production deployment, nor do you want some hack that involves getting the base URL from an application-scoped bean and hoping you remember to change a property for production deployment. So you're better off, at the very least, using <img src="#{resource['images:myImage.png']}"/> or the much easier to remember <h:graphicImage name="myImage.png" library="images"/>.
Related
I am developing a Clojure/ClojureScript SPA based on http-kit, compojure and tiny bits of hiccup on backend and mainly reagent on frontend. Project is done with leiningen, based on hand-wrecked chestnut template.
When I tried to make more complex URLs than just "/" the following setup created a mess for me:
When producing the initial hiccup to serve HTML and adding includes for CSS and JS files I followed the examples and added them as relative urls like
(include-css "css/style.css")
;and
(include-js "js/compiled/out/goog/base.js")
(include-js "js/compiled/myproject.js")
(note absence of slash in the beginning)
In the chestnut template I got default :asset-path option for cljsbuild set to "js/compiled/out"
Of course, when I tried to add a route to the same page with the http://my-domain/something URL in addition to root http://my-domain/ and load it, the thing failed to get any of my assets (trying to fetch them under e.g. /something/js/compiled/myproject.js).
I was able to fix this issue for explicitly included assets by making those urls relative to root (prepending a slash to each of them). It left me with the same problem with the script tag with src="js/compiled/out/cljs_deps.js" injected by cljsbuild, but this one I fixed by making :asset-path relative to root as well.
It all seems to work properly now, but the fact that I had to make some head-scratching and a surprisingly large amount of googling to finally resolve this makes me feel this is not the default approach. Hence the questions:
Did I do the right thing by converting all asset urls to relative-to-root ones? (Keeping in mind that I'm working on an SPA)
If yes, why isn't this a default approach and why I keep seeing relative-to-current location URLs everywhere (including all the examples on the web as well as lein templates)?
Update:
The relevant part of my app's compojure routes looks like this:
(defroutes home-routes
(resources "/")
(GET "/" _
(friend/authenticated
(html-response
(app-page))))
(GET "/something*" _
(friend/authenticated
(html-response
(app-page)))))
I'm developing a website based on drupal on my localhost. I have a problem with urls.
for a url like this :
http://localhost:81/my_website/library
I must output image src this way :
<img src="<?php print $directory; ?>/image/header/headerR.png"/>
but when the above url is changed to this
http://localhost:81/my_website/library/
I must output image src this way :
<img src="../<?php print $directory; ?>/image/header/headerR.png"/>
I mean it must refer to the parent. my website has contextual filter which can be inserted
after library/ .is there any general solution for handling such thing?
If you are printing an image directly to html you must use a non relative path to move to other dirs. You must always start the image path with /, so the image is relative to the domain, in this case, localhost. Example
<img src="/<?=$whatever; ?>" />
Also try building the image in the Drupal way. See these functions:
theme_image
theme_image_style
image_style_url
Use any of them, as you need.
Hope that helps.
use only relative path and put theme related images into your theme folder
lets say that your theme is named YOURTHEME
when you do <img src="/image/header/headerR.png"/>
it should load image from http://localhost:81/sites/all/themes/YOURTHEME/iamge/header/headerR.png
but if you need to load images from different than theme directory you will need to use CDN module https://drupal.org/project/CDN
you will be also able to load images easily from other server, its usefull when working on local DEV and getting images from production server
I have a web application that can be accessed either directly as http://host.foo.loc:8080/foo/ or via a secure reverse proxy as http://www.company.com/apps/foo/
By default, Grails will generate relative URLs with relative paths, for example:
<g:form action="bar">
will produce:
<form action="/foo/bar" method="post" >
This will be OK locally but the reverse proxy will not accept http://www.company.com/foo/bar (it's missing /apps/)
If I do:
<g:form action="bar" base=".">
it's fine. But I don't really want to specify it on each and every tag that generates a link.
The best way to deal with this would be to get Grails to generate relative paths in its relative URLs. Alternatively, I could live with setting a global "baseUrl" to "." but I don't know how to do that either.
Any idea ?
[edit] In fact, setting the "base" to "." doesn't work. The first page "/foo/controller/action" will generate the link as "./controller/nextaction" which the browser will translate as "/foo/controller/controller/action" => 404. I guess this is why they're using absolute paths: they're not paths.
I've never been able to make this kind of scenario work, so I always keep the proxied and unproxied context paths the same, i.e. I would put the app at http://host.foo.loc:8080/apps/foo. You can have a multi-level context path like this in Tomcat by naming the WAR file apps#foo.war.
Add grails.app.context = "/foo/bar" to your Config.groovy.
Intro:
I'm trying out LESS in an asp.net mvc environment.
I use dotless for server side processing (and I wouldn't want to use client side processing especially afer publishing the complete project).
I have to apply a design where there are different color schemes depending on different things (e.g. time of the day).
Less felt very powerful in this case as designing a parameterized css and only changing like 10 variables at the beginning of the file for every theme was really uplifting.
Problem:
But I would need to somehow change the color themes from an outside parameter.
Ideas:
First I thought that an URL parameter like style.less?theme=fuschia would be good, but I found no way to parse something like this.
Then I thought that making a very short blue.less, green.less, orange.less consisting only declared color variables, and including the main.less in every one of them would be a solid solution.
I had no chance to try out the second solution, but I thought this would be a good time to ask for advice on the most robust way of doing this.
The problem again is: I want to control some things in my less file from the outside.
Yes you can (because I implemented that feature for exactly that reason).
Dotless supports parameters from the outside via the querystring parameter.
<link rel="stylesheet" href="style.less?foo=bar" />
Will let you use the following less:
#foo = bar;
The parameter injection code is very simple. it just prepends the variable declarations to your normal less file, so anything that comes as a querystring parameter will follow the above syntax.
The code in question is very simple: https://github.com/dotless/dotless/blob/master/src/dotless.Core/Engine/ParameterDecorator.cs
AFAIK, you cannot pass parameters for dotnetless to use to do the compile.
As a suggestion, why not just call different less files? This would be fairly easy to do by using a Viewbag property.
To make the different less ones, You first create a less file with each set of colors in them. Then you import your base css file. dotnetless will merge the color definations in the parent file with the usages in the base file. So you have something like -
#baseGray: #ddd;
#baseGrayDark: darken(#baseGray, 15%);
#baseGrayLight: lighten(#baseGray, 10%);
#import "baseCss.less";
I just tested this on and MVC3 project and it works.
There are some image assets on my site that will always remain static, and therefore do not need the timestamp that gets appended to the images. Is there a way to not append the timestamps for certain assets?
Why not just use the regular HTML <img> element for those images? It'll be marginally faster than going through the Rails' helper too.
From the Rails docs "You can enable or disable the asset tag timestamps cache. With the cache enabled, the asset tag helper methods will make fewer expense file system calls. However this prevents you from modifying any asset files while the server is running."
ActionView::Helpers::AssetTagHelper.cache_asset_timestamps = true
Solution 1 would work, except I still need it to use the asset host, and I don't want to hardcode it. Solution 2 does not work since that would affect all asset paths. I think what I should be doing is to combine using the img tag, but use rails to compute the asset host for me.
So in the end it would look something like this
<img src=\"#{#template.image_path("image.jpg}}\"/>
thanks for the idea!