Clock change affecting date display
This is a very particular problem which happens only during the summer and not even in all the countries ! 😮
The problem is related to the Daylight Saving Time (DST), also called British Summer Time (BST):
Daylight saving time is the practice of temporarily advancing clocks so that afternoons have more daylight and mornings have less. Typically clocks are adjusted forward one hour near the start of spring and are adjusted backward in autumn.
Okay, so how do we display dates with JSF?
Let’s take this can’t-be-simpler bean:
public class MyBean {
public Date getDate() {
return new Date();
}
}
And let’s insert the following code in a JSF page:
#{myBean.date}
The result is Fri Sep 17 20:03:14 BST 2010 (when I wrote this article).
If I check my clock, the date and time above are correct.
So far so good. 🙂
Let’s now use the h:outputText tag from JSF:
<h:outputText value="#{myBean.date}"/>
The result is Sep 17, 2010.
Alright, the date is correct but the time is not displayed…
Let’s use the f:convertDateTime tag to also display the time:
<h:outputText value="#{myBean.date}">
<f:convertDateTime pattern="E MMM dd HH:mm:ss z yyyy" />
</h:outputText>
The result is Fri Sep 17 19:03:14 GMT 2010.
What can we see here? The time went one hour backward!
Why that? well, simply because the date is now displayed in GMT, instead of BST earlier.
So, this means that the h:outputText tag is displaying the date in GMT by default, which would be fine in winter but not in summer.
In order to fix this behaviour, you need to add the attribute timeZone to the f:convertDateTime tag such as:
<h:outputText value="#{myBean.date}">
<f:convertDateTime pattern="E MMM dd HH:mm:ss z yyyy" timeZone="GB" />
</h:outputText>
Note that if you put BST instead of GB in the timeZone attribute, the time zone is going to be actually set to BDST which stands for Bangladesh Daylight Saving Time! 😀
Validate file size prior upload
If I ask you what is the most complex thing in HTML, what would you reply?
For me, it would be the file upload (or maybe character encoding, but this is not the topic! 😛 ).
One of the problem around the file upload functionality is that there is, no matter what, a file size limit set on the server. The limit could be 100Kb such as 100Mb depending on the configuration of the server.
But what happens if the user tries to upload a file bigger than the limit?
It’s simple, the file is going to be uploaded on the server until the limit is reached. Once it happens, the server returns an error message to the client.
Well, this is not ideal!
Indeed, depending on the connection speed of the user, the error message could be displayed a few minutes later. And you know how impatient users are! 😉
So obviously, the solution would be to validate the file size before the upload starts.
To do that, we can simply use the fileSize Javascript function against the upload field.
But, surprising enough, this function doesn’t work on Internet Explorer! 👿
And the only solution I found to get the file size with IE was using ActiveX:
var oas = new ActiveXObject("Scripting.FileSystemObject");
var e = oas.getFile(document.forms[0].file.value);
var size = e.size;
Finally, here is the whole Javascript function to validate the file size:
function validateFileSize(file, maxSize) {
if (navigator.appName=="Microsoft Internet Explorer") {
if (file.value) {
var oas = new ActiveXObject("Scripting.FileSystemObject");
var e = oas.getFile(file.value);
var size = e.size;
}
} else {
if (file.files[0]!=undefined) {
var size = file.files[0].fileSize;
}
}
if (size!=undefined && size > maxSize)
return false;
return true;
}
with file the file input field to validate and maxSize the maximum size in bits.
For example, you can call this function as follow:
validateImageSize(document.forms[0].file, 500000)
I successfully tested this code on:
- Google Chrome 6;
- Firefox 3.6;
- Internet Explorer 6;
- Internet Explorer 7.
Relation between TortoiseSVN and locale
The other day, I got stuck on a problem with TortoiseSVN for about half a day! 😯
Yes, I know, it is a pretty long time to get a simple subversion client working…
The error I was continuously getting was:
Network connection closed unexpectedly
Nothing else! Nothing in the log files on both the client and the server. 🙁
The funny thing is that it was working perfectly fine using a command line client or even Eclipse Subversive.
After a (too) long time of investigation, I noticed that I was getting the following warnings when I was running the following command line directly on the server:
$ svn list svn+ssh://smoreau@localhost/data/svn/ svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LANG is en_US.UTF-8 svn: warning: please check that your locale name is correct smoreau@localhost's password: svnserve: warning: cannot set LC_CTYPE locale svnserve: warning: environment variable LANG is en_US.UTF-8 svnserve: warning: please check that your locale name is correct branches/ tags/ trunk/
Actually, any svn command was triggering the warning messages:
$ svn info svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LANG is en_US.UTF-8 svn: warning: please check that your locale name is correct
Could it possibly be related with my TortoiseSVN problem?
Because I didn’t have any other idea, I decided to give it a go. 😉
It appears that these warning messages came from a configuration problem around the locale package on the server. Indeed, look what we get if we run the locale command:
$ locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX
After some more investigation, it looks like this problem appeared when I upgraded the version of the locale package via APT. 😕
Once again, I asked my friend Google to help me out. It suggested me the following solutions:
- Run
locale-gen en_US.UTF-8– Didn’t work - Run
update-locale LANG=en_US.UTF-8– Didn’t work - Run
dpkg-reconfigure locales– WORKED 😀
In conclusion, I wasn’t able to use TortoiseSVN because of a configuration problem on the locale package after an upgrade… Does it make sense? 🙄
Use ServerXMLHTTP through a proxy
The other day, I was trying to use the ServerXMLHTTP object. For information, this object was created to allow you to establish server-to-server HTTP connections.
The code I firstly wrote looked like the following:
Dim oXMLHTTP
Set oXMLHTTP = Server.CreateObject("MSXML2.ServerXMLHTTP")
oXMLHTTP.open "POST", sURL, false
oXMLHTTP.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
oXMLHTTP.send sParams
Response.Write oXMLHTTP.responseText
with sURL the URL to call and sParams the parameters to send with the URL.
The problem was that oXMLHTTP.responseText didn’t return anything. Or to be exact, it returned an empty string, which was obviously not the expected response… 🙁
After some investigation, it appeared that the problem was because the server was seating behind a proxy. All this is good and well, but the question now is how to tell the application to use the proxy?
First of all, the ServerXMLHTTP object has a setProxy method:
http://msdn.microsoft.com/en-us/library/ms760236(v=VS.85).aspx
So I tried to add the following line to the previous code:
oXMLHTTP.setProxy 2, "myProxyServer:80", ""
Unfortunately, this didn’t fix the problem. It looks like this line is simply ignored. If somebody knows why, please tell me! 😉
So the solution I finally adopted was to configure the proxy through the proxycfg tool.
There are two ways of using this tool:
- Import the proxy settings from the current user’s Microsoft Internet Explorer manual settings using the command
proxycfg.exe -u - Configure the proxy settings manually using the command
proxycfg -p myProxyServer:80
This last solution works for me and I hope it will help a few people. 🙂
PS: I found the following page when writing this article: http://support.microsoft.com/kb/289481/. It would have been so good to find it during my investigation but anyway.
How to configure JSF to get the browser Back button working
Lately, I had a problem with one of my JSF applications which is using RichFaces.
The problem was happening when the user was hitting the browser Back button. Well, you would say that it is a usual problem in web development. But still, because we cannot disable the browser Back button, the web application needs to work fine if the user decides to click on it!
Anyway, let’s get back on topic. As I said, the problem occurred if the user was clicking on the Back button but the funniest thing is it was happening when he was clicking twice on it! Why did it work fine when clicking once but not twice? 😮
The solution is quite simple actually.
It was coming from one of the options in MyFaces configuration: com.sun.faces.numberOfViewsInSession.
Here is a quick explanation of this option:
com.sun.faces.numberOfViewsInSession
Specifies the number of views that are stored in the session when Server-Side State Saving is used. If set to true while client-side state saving is being used, reduces the number of bytes sent to the client by compressing the state before it is encoded and written as a hidden field. The default for this parameter is 15.
So basically, JSF is storing each page previously viewed by the user in session. And, as you can see from the description above, JSF will stored a maximum of 15 pages by default. However, it was set to 1 in my application, which means only ONE page would be stored…
This was obviously the reason why the application was working fine if the user was clicking only once on the Back button but not twice! 😀
For the same reason, you should also check the option org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION which is default to 20:
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
Defines the number of the latest views that are stored in session. This option is only applicable if the state saving method is set to server. The default for this parameter is 20.
For more information about JSF options, please have a look at the following page:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rweb_jsfengine.html
WWF – Help us
