As i understand it, the needs for JSF 2 resources is to help organizing resources directories, and add some versioning and localization.
But is it possible to combine this feature with a CDN ? I've never used CDN before, but it looks good, and would like to hear your ideas about it and possible combinations with JSF 2 resources, although i dont think it's likely.
This is not possible with <h:outputScript> and <h:outputStylesheet> yet, as they can only point to webapp's own resources, not to an external URL. This feature has already been requested to the JSF guys. See also JSF spec issue 598. Right now it's scheduled for 2.2, but I don't expect it to be already implemented then as it's currently at 0 votes.
Until then, you'd need to specify them yourself using plain HTML <link> and <script> in <h:head>. You could make it a template definition if necessary, surely when you'd like to define them on a per-view basis.
<h:head>
...
<ui:insert name="resources" />
</h:head>
and
<ui:define name="resources">
<link rel="stylesheet" type="text/css" src="http://.../foo.css" />
<script type="text/javascript" src="http://.../foo.js"></script>
</ui:define>
Update the JSF utility library OmniFaces has since version 1.2 a CDNResourceHandler available which could be used to automatically replace JSF resources by CDN resources when running in production stage. See also the CDNResourceHandler showcase page.
Related
How to get favicon website with Chromium Embedded Framework? I could look at the source code and get the url of the icon, but some sites, like Facebook, do not use a standard procedure to add a favicon, then, how do I get the favicon? Thanks.
The rules for the favicon are all explained on the Wikipedia page.
The standards use a link element with a rel attribute in the <head> section of the document to specify the file format, file name and a location can be specified for any Web site directory.
You need to look, inside the <head> element, for link elements of this form:
<link rel="shortcut icon" href="http://example.com/myicon.ico" />
or
<link rel="icon" type="image/vnd.microsoft.icon"
href="http://example.com/image.ico" />
If you don't find such links, then use the fall back of looking for favicon.ico at the root directory.
I'm not certain why you think that Facebook don't follow the standard. I just looked at an FB page which contained this:
<link rel="shortcut icon"
href="http://static.ak.fbcdn.net/rsrc.php/yP/r/Ivn-CVe5TGK.ico" />
It's not possible for websites to use some other mechanism to get favicons to browsers. The browsers follow the well-defined rules for getting favicons. If a website did something different, the browser would not find the favicon.
From this blog entry, the best practice for cross-browser supported favicons is to include
<link rel="icon" type="image/vnd.microsoft.icon" href="http://www.example.com/image.ico"> <!-- For good browsers. -->
<link rel="SHORTCUT ICON" href="http://www.example.com/image.ico"/> <!-- For Internet Explorer-->
The first link is for real browsers and the second is for ie rubbish. On some websites you will see type="image/x-icon" in the link tag. There was a time when this was the correct implementation, but image/x-icon has now been superceded by image/vnd.microsoft.icon which is now part of the IANA standard for MIME types.
By the way, older versions of ie just looked for a file name /favicon.ico which was hard-coded. If you wanted to be ultra safe, you should name your favicon as favicon.ico. Of course that does not help you if your domain hosts multiple web-sites for different purposes.
Note: If you don't need to support favicons for IE, then you are then free to use png, gif and jpg formats for your favicon, as indicated below...
<link rel="icon" type="image/png" href="http://www.example.com/image.png">
<link rel="icon" type="image/gif" href="http://www.example.com/image.gif">
<link rel="icon" type="image/jpeg" href="http://www.example.com/image.jpg">
CEF1 has a callback named OnFaviconURLChange that's called whenever the favicon URL for a page changes. CEF3 doesn't support this callback yet, according to this bug in the CEF issue tracker.
You need to implement a client handler and at least CefDisplayHandler. This class have the OnFaviconURLChange (not sure in what version did appear, but for sure is present in branch 2357 and later).
C++ prototype is:
void OnFaviconURLChange(CefRefPtr<CefBrowser> browser,
const std::vector<CefString>& icon_urls);
icon_urls usually contains a single entry (if any), which is the URL of the favicon.
Consider also checking the favicon URL for its security, I passed the URL to a HTMLayout application only to discover that was on a self-signed https:// resource and all sorts of wininet security error (InternetErrorDlg for example) started throwing all the place.
I'm developing a new webapp based on the orbeon samples. I'm using orbeon 3.9 CE. I got VERY ERRATIC behavior when I use custom ressources. They are placed in following folders :
/orbeon/WEB-INF/resources/config/theme/*.css
/orbeon/WEB-INF/resources/config/theme/*.js
/orbeon/WEB-INF/resources/config/theme/images/*.jpg
In my custom theme file (/orbeon/WEB-INF/resources/config/theme-xnotes.xsl), they are linked like this (a few examples) :
<xhtml:link rel="stylesheet" href="/config/theme/bootstrap.css" type="text/css" media="all"/>
<xhtml:script src="/config/theme/bootstrap.js"/>
<xhtml:link rel="icon" href="/config/theme/images/icone_grue.png" type="image/png"/>
When I point my browser at the application (http://localhost:8080/orbeon), it SOMETIMES work, SOMETIMES doesn't (css are ignored, page transitions are wrong) and SOMETIMES it works partially (css are ok, js not, a few images are ok, others are not and so on)
When I look at the page source code, the links seems to be ok, to take the sames examples as above :
<link rel="stylesheet" href="/orbeon/config/theme/bootstrap.css" type="text/css" media="all">
<script src="/orbeon/config/theme/bootstrap.js">
<link rel="icon" href="/orbeon/config/theme/images/icone_grue.png" type="image/png">
But some links are not valid and point to the root of the application. The main problem is that I just can't make this behavior consistent to isolate the issue(s).
Help really appreciated ! It's driving me crazy...
I don't think there can be more than one GET or POST per request, but per open connection certainly.
However, this might be related to authentication since you mention j_security_check. Can you try to make sure that the CSS and other resources are not protected by form authentication?
I am currently trying to add basic JSF (2.0) support to Backbase Portal 5.2.1.2 to use in my custom widgets.
It seems to be working when I access my widget in a static way (e.g. ".../portal/static/portal_name/widgets/widget_name/index.xhtml"), but when I view my widget in the context of a portal (.../portal/portals/portal_name/pages/index) my JSF tags are shown in the HTML source as instead of the parsed output. The same happens to EL variables like #{msg.title}.
If I use the same JSF setup in a 'normal' webapp project, it works just fine as well, so in my eyes, there must be something Backbase specific that is causing this issue.
I would like to know what is causing this to happen, if it could be solved or circumvented or if anyone has successfully managed to implement JSF in this specific version of Backbase. I know implementing JSF worked in Backbase 5.1, but for me it's not an option to revert to that version.
Edit - Added the widget's index.xhtml by request (My actual index.xhtml is slightly bigger, but this fails as well):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xml:lang="en">
<h:head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
<title>Help ribbon widget</title>
<link rel="stylesheet" type="text/css" href="css/style.css" />
</h:head>
<h:body>
<span class="left title">#{msg.help_title}</span>
<h:outputText value="TEST"/>
</h:body>
</html>
Additionally I am using a Border_Layout for my container template if that is of any help.
When I go to Google Chrome inspector's network tab, and look at the request for the widget's index.xhtml file, I can see the correct output, but for some reason this is not the same as what is shown in the combined html.
The problem with this approach is that widget definitions are not currently expected to contain dynamic content.
I'd guess that in your scenario, the *Border_Layout* container is server sider rendering (SSR) the widget. When this happens, if your widget's src URL is relative, the portal will simply read the file from disk and the faces servlet will never be invoked. This is normal, the definition is expected to be static. But there are two immediate solutions:
Firstly, you can switch to client side rendering (CSR). This will result in the client making a http request for the widget definition and it being accessed via the faces servlet. Easiest way to achieve this is to use a custom page template which does not contain a <b:include> tag. This solution does mean it will not work with JS disabled though.
If, however, you wish to keep using SSR, you can use an absolute url for your widget's src property. This means the server needs to make an http request for the widget, thus running it through the faces servlet. There is one more problem here; As the Portal Server expects widget definitions to be static, it will aggessivley cache it, so you'll need to switch off widget caching.
I wouldn't really recommend both of these solutions though in the longer term. I'd recommend you run your JSF app independently in a separate context and then find a way to include it in a widget. You could try to setup something with Backbase Mashup Services, but I'd recommened a simple iframe approach. If you require, I can provide you with a more advanced iframe Backbase widget for creating seamless iframes (no scrollbars etc).
If you need any more support, I'd encourage you to sign up at https://my.backbase.com. Backbase's new support site where you should receive more dedicated help, docs and code samples.
I have three solutions; all share one thing in common which is the stylesheets. I would like to have only one version of the stylesheets.
I thought to put this and maybe other things like common scripts in one project and then have all three solutions reference this same project.
But how can I link in the stylesheets to my layout pages. Currently I use:
<link href="#Url.Content("~/Content/Stylesheets/Package3.css")"
rel="stylesheet" type="text/css" />
Any advice would be appreciated.
You might be able to do this with your source control? But the better solution might ultimately be to make a 4th project of your static shared files (ex. css, javascript, images) and deploy them to a URL that you will only use to serve this content.
So you can reference in your project like:
<link href="http://mydomain.com/content/stylesheets/package3.css" rel=stylesheet" type="text/css" />
Where mydomain.com is actually your 4th project that only hosts the static content.
You can use the 'Add as link' option.
When running my web app on my local machine i can ref css/scripts/images using:
<link href="/Content/Site.css" rel="stylesheet" type="text/css" />
But when I deployed to my Development server, it wasn't able to find any of my content. After researching the issue everyone suggests using the below method:
<link href="<%=Url.Content("~/Content/Site.css")%>" rel="stylesheet" type="text/css" />
<img src="<%=Url.Content("~/Content/3.png")%>" />
At least now all my content is loaded and works when I push to the development server. However now that I have the server script in there, the "Design" view in Visual Studio doesn't load any styling/etc. I'm wondering if there is an alternative or something I'm missing that perhaps would fix this? Or maybe I'm going about it all wrong? Any input is greatly appreciated.
The suggestion you found is a great way to reference content.
As far as Design View goes, don't sacrifice the elegance of your code just to get Design View. Learn to love Code View. Preview in a browser. In my experience, that workflow really has no major downsides (once you get used to it).
(As an aside, I think most of the developers who like ASP.NET MVC do not use "Design View" in Visual Studio. One of the reasons I love MVC is that it allows me to be picky about the markup. Any kind of designer lies outside that kind of thinking.)
You can always cheat the designer with an atrocity similar to this:
<% if (false) { %>
<link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
<% } %>
<link href="<%=Url.Content("~/Content/Site.css")%>" rel="stylesheet" type="text/css" />
but hey, quite honestly hitting F5 in the browser will give you faster results than waiting for the designer to load (even if your application is hosted on the other end of the world).
Design view is broken? Thats not a bug in your code, thats just the way it is. This is true for ASP.NET MVC and regular ASP.NET