Testing web mobile pages

In an earlier post, I was telling you how to detect a mobile device on the server side so you will be able to serve the appropriate page. The next step after you implemented those pages will be to actually see your work.

If you have a mobile device everything is fine. Frankly I don’t like to directly use one, because only typing a web address can be a challenge. Just a while ago, I discovered the My Mobiler application, some kind of Remote Desktop or VNC. So you can use your Windows Mobile from the comfort of your own desktop mouse and keyboard.

But this still involves having an actual device.

If not, you can use an emulator. For iPhone a good choice is Safari web browser under Mac or Windows. It uses the same rendering engine (WebKit) and has very similar functionality.
For Android, the Android emulator in Android SDK is a very good choice. It has almost the entire functionality of an actual device.

Another way of testing mobile pages will be to rewrite the User-Agent HTTP header of your own browser. This will ensure that you will get redirected (if the website is properly behaving) to a mobile web page.
How to do this?
In Firefox you type in the address bar about:config and define a new preference (by right clicking and selecting New » String) with the name general.useragent.override and the value of your choice.
In Internet Explorer things are a little bit more complicated and involves some registry editing.
In the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent] key you have to define the (Default), Compatible, Version and Platform. The final user agent string will look like [(Default)] ([Compatible]; [Version]; [Platform]).
If you add some values in the registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform] they will be added in the user agent string.

But the easiest method to do this is with a Firefox add-on: User Agent Switcher.

If you choose an user agent string from the WURFL database and then visit Google, Yahoo, YouTube etc you will see a different version than the one you are used to.

Last update: May 12th, 2010

Web progress bar

Would you like something like this in your web page?

Then I will show you how to do it.
The basic idea is pretty simple: implement it using 3 DIVs – one for the progress bar background, one for the completed part and one for the label (indicating the completed value or percent). They are stacked on top of each other in the specified order, from bottom to top.

We will have a main DIV, the actual progress bar, and inside it a completed one that will take as much space from its parent as the task is completed and a label to indicate that percentage.

On the main DIV we specify a border that will enclose the entire progress bar and a background that will indicate the remaining part. We also specify a different background on the completed DIV to indicate the completed part of the task. As for the label we specify only a font color and the background should remain transparent, so the label just sits on the progress bar.

Both children DIVs of the progress bar are floated to left and the label one has a negative margin to allow to be displayed at the same coordinates as the completed one.

• HTML code
  

  <div id='progressbar' class='progressbar'>
      <div id='completed' class='completed'></div>
      <div id='label' class='label'>0%</div>
  </div>
  

• CSS
  

  .progressbar {
      /* only for better layout :) */
      background-color: white;
      border: solid 1px black;
      width: 100px;
      height: 10px;
      font-family: arial;
      font-size: 10px;
  }
  
  .progressbar .completed {
      /* mandatory */
      width: 0%; 
      height: 100%; 
      z-index: 1; 
      float: left;
  
      /* only for better layout :) */
      background-color: navy;
  }
  
  .label {
      /* mandatory */
      width: 100%;
      height: 100%;
      z-index: 2;
      float: left;
  
      /* only for better layout :) */
      text-align: center;
      vertical-align: middle;
      color: yellow;
  }
  

  As you can see some of the CSS properties are mandatory for the component to render as a progress bar, as some of the properties are used only for a visually appealing layout.

• JavaScript
  

  function setPercent(percent) {
      document.getElementById("label").innerHTML = percent + "%";
      document.getElementById("label").style.marginLeft = "-" + percent + "%";
      document.getElementById("completed").style.width = percent + "%";
  }
  

Next step will be to wrap all these into a nice component (JavaScript class). But this depends only on your architectural skills, as now you have the basic technique.

And in the end you can see a full working example, tested on IE6, FF3 and Safari 3. If you get rid of the hassle of implementing this yourself and you want a ready to use and easy to integrate progress bar component for your web pages you should see the MyUI JavaScript library. A demo is also available.

Just a side note, a throbber (or indeterminate progress bar) is easier to implement, that one being only a simple animated image.

Tips’n’tricks: CSS float in JavaScript

The CSS float property it is often used (if you don’t layout your pages with evil pages). It is pretty easy to setup using CSS code:

float: left;

.

If you want to setup a CSS property from JavaScript it is usually done using the syntax:

element.style.property = value;

and - signs are replaced with camel case (e.g. backgroundColor instead of background-color).
This won’t work for float too. float is a reserved JavaScript word, so you should use cssFloat instead. As usual ;), Internet Explorer is special and you should use styleFloat instead.

That’s it. Short small tip, but very useful if you want to dynamically modify the flow of elements.

Web publishing system with Apache and Subversion – part 3

Authorization

The previous posts were covering setup and authentication. But definitely you would like special rules for different groups and modules in your organization. It is not uncommon that a different group of developers will work on different module(s).

For this you have to use the mod_authz_svn module that comes with the Subversion module and activate it by adding the below line at the beginning of <apache-dir>/conf/extra/wps.conf:


LoadModule authz_svn_module modules/mod_authz_svn.so


Then to configure the access policy you have to add to every <Location> section that defines Subversion repositories:


AuthzSVNAccessFile "/wps/svnaccess.conf"


where /wps/svnaccess.conf is the file holding your access policy.

I will try now to explain the syntax and semantic of this access policy file using a small example:

[groups]
admins = admin1, admin2
web-developers = john, marry
backstage-developers = harry, sally

[/]
* = 
@admins = rw

[web:/]
@web-developers = rw
@backstage-developers = r
editor = rw

[stage:/]
@web-developers = rw
@backstage-developers = rw

You can see that the file is an usual properties files divided in sections, each section beginning with [<section-title>] and ending at the beginning of the next section. The first section defines the groups of users. The users in group are comma separated. It is obvious that john and marry are web developers and there are two administrators (admin1, admin2).

The following sections describes access rules to repositories and directories. The section title has the format repository:path and it specifies a rule for the given path inside the repository. If you don’t specify a repository or a path it will define the rules for all (repositories/paths). Inside these sections every line describing an access rule has the format

username = permissions

or

@groupname = permissions

If the username is *, then it refers to all the users.
The permission can be an empty string for granting no permission, r for reading, w for writing and rw for reading/writing.

Taking into account all this you can see that by default nobody has access to the repositories and administrators have read/write access to everything. Further on, the backstage developers have read access to the website and read/write access to the backstage environment.

More information on these you can find on the SVN book in the section Per-Directory Access Control.

Backstage environment

You already saw that I used the term backstage. This refers to a website with access only for the internal users that it is used for reviewing purposes. Before putting something on your website you may want to be reviewed by certain groups and modified accordingly. Of course we will also have a corresponding Subversion repository as for the main website.

So we will do the same creation of the Subversion repository, create the directory for the web folder, checkout the repository, add the hook and configure Apache. I will only explain here how to write the configuration for Apache, as this is a little bit different because it should be only accessible for internal users. Practically you will add the same authentication configuration as for the Subversion repositories.

<Directory "/wps/backstage">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
    
    AuthName "Backstage Authentication"
    Require valid-user
    # for basic authentication
    AuthType basic
    AuthUserFile /wps/passwd
</Directory>

Alias /backstage /wps/backstage
ScriptAlias /backstage/cgi-bin/ 
        "/wps/backstage/cgi-bin/"

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80

<VirtualHost *:80>
    ServerAdmin administrator@domain.com
    DocumentRoot "/wps/backstage"
    ServerName backstage.domain.com
    ServerAlias www.backstage.domain.com
    ErrorLog "logs/backstage.log"
    
    ScriptAlias /cgi-bin/ "/wps/backstage/cgi-bin/"
</VirtualHost>

Conclusions

If we go back to the first post from this series then you can see that we met all the requirements for the desired web publishing system. It is free, OS independent and can be easily installed and setup (a few hours even for the very junior administrators).
The authentication and authorization mechanism can be customized to a very high degree to meet your needs.
Web developers can easily access the Subversion repository using TortoiseSVN. Or even from Dreamweaver (although this extension isn’t free and I haven’t tested it).
If you also install websvn, you will RSS feeds for all the changes made to your website.
And, most importantly, you have all the versioning system advantages brought to your website.

Part 1 – Part 2

Download configuration files.

Web publishing system with Apache and Subversion – part 2

If you read the first part of this post, you probably know by now how to install and configure a web publishing system using only Apache and Subversion. But your system will miss one of the most important thing: authentication. So let’s get started and tackle this.

Authentication

We kept all the Apache configuration settings related to Subversion and the website in the file <apache-dir>/conf/extra/wps.conf and further on we will modify this file.
Remember the below section located either in the main server or in a virtual one section?

<Location /svn >

    DAV svn
    SVNParentPath /wps/svnrepo
    SVNListParentPath On

</Location>

We will modify this one to add authentication and authorization.

<Location /svn >

    DAV svn
    SVNParentPath /wps/svnrepo
    SVNListParentPath On

    AuthType basic
    AuthName "SVN repository"
    AuthUserFile /wps/passwd
    Require valid-user

</Location>

The user database will be kept in the plain text file /wps/passwd. To add or modify users you can use the htpasswd utility. So let’s add a developer account:


htpasswd -c /wps/passwd developer


You will be prompted for the password. Later on you can change it with:


htpasswd /wps/passwd developer


.

There are also some other ways to authenticate users, by keeping the users in a database file or using LDAP. You have to specify the authentication provider and use the specific module settings: mod_authn_file, mod_authn_dbm,
mod_authn_dbd,
and mod_authnz_ldap.

Windows authentication

You can also use Windows domain authentication, but this will require just a little bit more work from your side. Anyway this may come in handy in some big organizations, where you don’t want to create special accounts only for this and enable users to use their usual Windows logon credentials.

First of all you have to download the SSPI authentication module and copy it to <apache-dir>/modules. Then add the following line at the beginning of <apache-dir>/conf/extra/wps.conf:

LoadModule sspi_auth_module modules/mod_auth_sspi.so

and the below lines to the Location section corresponding to the SVN repository:

    AuthName "Windows Authentication"
    AuthType SSPI
    SSPIAuth On
    SSPIAuthoritative On
    # set the domain to authorize against
    SSPIDomain your.windows.domain
    # keep domain name in userid string
    SSPIOmitDomain On 
    SSPIUsernameCase lower
    SSPIOfferBasic On 
    # basic authentication shouldn't 
    # have higher priority
    SSPIBasicPreferred Off 

    Require valid-user

Now lets’ discuss in a little bit more in detail the above configuration settings:

• SSPIAuth – this will turn on/off the Windows authentication module
• SSPIAuthoritative – this will turn on/off if the the Windows authentication is mandatory or if other modules can be used as a fallback
• SSPIDomain – the IP address or name of your windows domain controller against which the authentication is run
• SSPIOmitDomain – if it is On then the domain name is omitted from the user name; so if the user is DOMAIN\user, the user name for Apache and Subversion will actually be user and not DOMAIN\user.
• SSPIUsernameCase – tells how the user name letter cases are converted. The possible values are lower and upper. If this is not specify then no conversion is made. If you specify lower (recommended) then the user name DOMAIN\User will be transformed to domain\user (if you also specify SSPIOmitDomain On, then the name will become user)
• SSPIOfferBasic – SSPI by default uses NTLM, a Microsoft proprietary protocol which only IE (and other Windows components/application) understand, so they are able to authenticate you automatically. If you set SSPIOfferBasic On means that it is still authenticating against your Windows domain on the backend, but when it asks the client for a password, it does so using standard HTTP Basic authentication. So if you plan to use other clients to your Subversion repository than IE you must set this on and the client then will prompt you for the domain name and password. This is definately needed if you use TortoiseSVN.
• SSPIBasicPreferred – if it is On then basic authentication will have higher priority

The authentication possibilities are endless and are depending only on your imagination and needs. I was focusing on these two types as they will probably appear more often: basic in a low or mid-size company and Windows authentication can be smoothly integrated in a big company infrastructure with Windows desktops for the big part of users.

Authorization, setting up a second repository and conclusions will follow soon.

Part 1 – Part 3

Download configuration files.

Web publishing system with Apache and Subversion – part 1

Introduction

What does a versioning system have to do with the web and more specifically with a publishing system?

When developing small websites (mainly presentation ones) you usually don’t need a versioning system. This post will come very handy to you if you work on a bigger team developing an enterprise (not necessarily, presentation) website. There a versioning system is clearly needed: user concurrency, history backup, a central repository, basically the main features of such a system.

I have chosen Subversion as the concurrent versioning system, not only as being the latest in style ;), but also for some features which makes it perfect, easy to use and easy to setup. In a few words we want a web publishing system that:

• mandatory: is free
• mandatory: is easy to setup for administrators
• mandatory: is very easy to use for (web) developers
• mandatory: features versions for the web pages, so you will be able to see changes in time and revert to previous versions
• mandatory: provides an authentication and authorization system
• nice to have: the authorization system can be configured per module, meaning that different groups of developers can have read/write access to different sections of the website
• nice to have: able to send notifications every time a web page is modified
• nice to have: is customizable and able to perform specific tasks whenever a change is made (add/edit/delete web pages)
• nice to have: running on multiple OSes

Taking all this into account, what is the solution? I will continue by describing the steps how to setup and use such a system.

Installation

First of all, download and install Apache 2.2 and Subversion. The installation is very easy and I will not enter here in any details (there are even binary packages, aka installers, for all the main operating systems:) ).

Configuration

Now let’s get to the server configuration. For the sake of the example, let’s suppose that we will use the /wps or c:\wps (for Windows) folder for the entire thing. We will create the svnrepo subfolder as a parent for all Subversion repositories and then create a Subversion repository for the website using the svnadmin command:

svnadmin create /wps/svnrepo/web

or in Windows

svnadmin create c:\wps\svnrepo\web

Let’s go now and configure Apache so that you can access Subversion repository through it. We don’t use the lightweight svnserve standalone server because we already have Apache installed as a web server. The configuration steps are:

1. Copy the files mod_dav_svn.so and mod_authz_svn.so from <svn-dir>/bin to <apache-dir>/modules, where <svn-dir> is the Subversion installation directory and <apache-dir> is the Apache installation directory (usually C:\Program Files\Apache Software Foundation\Apache2.2 in Windows).
2. Add the following line to the Apache configuration file <apache-dir>conf/httpd.conf:
   

   Include conf/extra/wps.conf

3. Create and edit with your favorite text editor the file <apache-dir>conf/extra/wps.conf.Paste the below content into:
   

   LoadModule dav_svn_module 
     modules/mod_dav_svn.so
   LoadModule authz_svn_module 
     modules/mod_authz_svn.so
   
   <IfModule dav_svn_module>
   # if the module was loaded succesfully
   
   # to exclude SVN files from web published folders
   <Directory ~ "/.svn">
       Order allow,deny
       Deny from all
   </Directory>
   
   # if you want a virtual host for Subversion
   <VirtualHost *:80>
       ServerAdmin administrator@domain.com
       ServerName svn.domain.com
       
       <Location / >
           DAV svn
           SVNParentPath /wps/svnrepo
           SVNListParentPath On
       </Location>
       
       ErrorLog "logs/wps.log"
   </VirtualHost>
   
   # the Subversion folder
   <Location /svn >
   
       DAV svn
       SVNParentPath /wps/svnrepo
       SVNListParentPath On
   
   </Location>
   

If you restart your Apache web server you will be able to access the SVN repository at http://domain.com/svn/web or at http://svn.domain.com/web.

Now we will create a web folder to host the website files and then checkout the web repository into it. Note that if you’re going to use a trunk/tags/branches directory organization (which I definately recommend) in the repository then you should checkout in the web folder only the trunk:

svn checkout http://domain.com/svn/web/trunk /wps/web

As you noticed by now the /wps/web is a working copy of the repository. But checking out the repository is not enough, you have to set up a commit hook to automatically update the working copy every time a change is made. Create a file post-commit in Unix (don’t forget to change the x mode – chmod 775 post-commit) and post-commit.bat in Windows with the following content:

svn update /wps/web

Every time a change is commited into the Subversion repository that change gets into the web directory too. Of course a .svn directory is created under each directory. You don’t have to delete them, the Directory ~ "\.svn" Apache section in wps.conf will deny access to these directories.

Now you have only to add a few lines to wps.conf to enable access to the web folder:

DocumentRoot "/wps/web"
ServerAlias www.domain.com

<Directory "/wps/web">
    Options Indexes FollowSymLinks
    AllowOverride None
    Allow from all
</Directory>

Note: Please don’t forget to restart Apache every time you change the configuration files.

Now everything should be up and ready. But everyone can commit to your web repository and you definately don’t want this.

In the next parts I will explain how to setup an authentication and authorization system and how to create a second web repository accessible only within your organization.

Part 2 – Part 3

Download configuration files.

Web transparency

If a few years back, transparency was the cool kid in user interfaces, nowadays it’s a must if you want to have a user interface that is not dull and lives in the present.
And I’m talking here not only about desktop graphical interfaces, but also about web interfaces. With all the comotion about Web2.0 and web applications, transparency is something that you should definately see 😉 in your web site.

But how to do it? The browsers wars will definately be a battle to take and win here. But to keep it simple, I’ll tell that there are three ways to do it: W3C, Internet Explorer and Mozilla.

• W3C. If we will go to their site http://www.w3.org/TR/css3-color/#opacity we will see that the CSS property handling this is called opacity. The possible values are floats between 0 and 1, with 0 totally transparent and 1 totally opaque. The intermediate values represent different levels of transparency.
  
  But you probably noticed that this is a CSS version 3 property and unfortunately very few browsers supports it currently. Latest versions of Firefox do support this (I tested it with version 2.0.0.8).
• Mozilla. In Mozilla the things are the same, but the name of the CSS property is different: -moz-opacity. As this is an obsolete way, you should prefer the CSS3 property and use this only for backward compatibility.
• Internet Explorer. Here things are a little bit more complicated. You should use the filter property and the Alpha. As I said, a little bit more complicated, that’s why here’s below a code sample:
  

  filter: progid:DXImageTransform.Microsoft.Alpha(opacity=50);

  The opacity argument can have integer values between 0 and 100, with 0 totally transparent and 100 totally opaque.

And this is for CSS. But what if you want, e. g. to create a fade in/fade out effect and to dinamically modify the transparency? Then you should simply use JavaScript and I think the best way to explain how it is through code samples.

• W3C method:
  

  element.style.opacity = opacity;

• Mozilla method:
  

  element.style.MozOpacity = opacity;

• Internet Explorer method:
  

  element.style.filter = 'alpha(opacity=' + (opacity * 100) + ')';

In these samples, the opacity parameter value has the same semantic as in the CSS3 case. Please note that in the IE code sample this value is multiplied by 100.
And now if we put all these together we have cross browser methods for getting and setting the transparency of an HTML element:

function getOpacity(element) {
    var v = element.style.opacity;
    return ((v == null || isNaN(v)) 
            ? 1 : element.style.opacity);
}

function setOpacity(element, opacity) {
    if (opacity < 0)
        opacity = 0;
    if (opacity > 1)
        opacity = 1;
    element.style.opacity = opacity;
    
    if (document.getElementById("ie").checked 
            && (element.style.filter != undefined))
        element.style.filter = 'alpha(opacity=' 
                + (opacity * 100) + ')';

    if (document.getElementById("moz").checked 
            && (element.style.filter == undefined))
        element.style.MozOpacity = opacity;
}

You can see these samples working here.

AJAX vs DHTML

AJAX is gaining a lot of adopters these days and it seems to be like the new cool kid in town. If you’re in the web development area, you must use AJAX, otherwise you’re not cool at all.

But more than this, AJAX became a buzzword. And I definitely don’t like buzzwords. Because amateurs would try to use that word for everything that is related to that area.

We have to clearly see the difference between AJAX and DHTML. AJAX stands for Asynchronous JavaScript and XML and it is simply a way to communicate with a web server without making a new request in the browser. And this will happen more likely without user really feeling it. DHTML stands for Dynamic HTML and it is a set of technologies used for dynamically modifying a web page, usually incorporating JavaScript and CSS.

AJAX and DHTML are not excluding each other, but working together. With DHTML you can dynamically modify a site using client-side code. But sometimes you cannot simply have everything on the client side (or it could be too expensive to have it) and you should interact in some way with the server-side code. And then AJAX comes into stage, just to simply create a connection between some JavaScript client-side code (on an DHTML site) and a web server. Before this, you could have used signed Java applets or Flash, but this offers the opportunity of a pure JavaScript solution.

Actually you could even say that AJAX is a small part from DHTML, but people are using it the other way around. I have to admit that even the name was chosen to fit a new upcoming buzzword. With AJAX (Asynchronous JavaScript and XML) you can even do synchronous requests and handle HTML or plain text, even tough the initial intent and good practice is not to do it.
I know that it is cool to use all these new buzzwords, but it will be much more correct to use the right term.

For a good AJAX reference you can use Wikipedia. Read also the articles referenced at the end, I would especially recommend the ones from IBM developerWorks.

Passing POST parameters with AJAX

AJAX can be used not only with webservices but with HTTP applications as well. So instead invoking a webservice, you’ll make an HTTP request. This comes veryhandy when using legacy application or when your usage of AJAX is very limited and webservices are simply too much.

What I wanted to share is a small trick on how to pass POST parameters with AJAX. The entire exercise will consist of defining a function called doPost that will receive as parameters the url and a two-dimensional array of parameters

function doPost(url, parameters) { 
  // create the AJAX object 
  var xmlHttp = undefined; 
  if (window.ActiveXObject){ 
    try { 
      xmlHttp = new ActiveXObject("MSXML2.XMLHTTP"); 
    } catch (othermicrosoft){ 
      try { 
        xmlHttp = new ActiveXObject(
            "Microsoft.XMLHTTP"); 
      } catch (failed) {} 
    } 
  }    

  if (xmlHttp == undefined && window.XMLHttpRequest) { 
    // If IE7, Mozilla, Safari, etc: Use native object 
    xmlHttp = new XMLHttpRequest(); 
  }  

  if (xmlHttp != undefined) { 
    // open the connections 
    xmlHttp.open("POST", url, true); 
    // callback handler 
    xmlHttp.onreadystatechange = function() { 
      // test if the response was totally sent 
      if (xmlHttp.readyState == 4 
            && xmlHttp.status == 200) { 
        // so far so good 
        // do something useful with the response 
      } 
    }  

    // create the parameter string 
    // iterate the parameters array 
    var parameterString;  

    for (var i = 0; i < n; i++) { 
      parameterString += (i > 0 ? "&" : "") 
          + parameters[i][0] + "=" 
          + encodeURI(parameters[i][1]); 
    }  

    // set the necessary request headers 
    xmlHttp.setRequestHeader("Content-type", 
        "application/x-www-form-urlencoded"); 
    xmlHttp.setRequestHeader("Content-length", 
        parameterString.length); 
    xmlHttp.setRequestHeader("Connection", "close");  

    // send request 
    xmlHttp.send(parameterString); 
  } 
}

The parameters string can be constructed in a different way or even the parameters can be passed to the method in a different format. In the above case the parameters are passed as a two-dimensional array, everyline representing a parameter, again an array containing name (first element) and value (second element).

A call to the above function would look like this:

doPost("doIt.jsp", new Array(new Array("action", "action1"), new Array("id", "123")));

Centering a DIV using CSS

Using DIVs instead of TABLEs and CSS formatting should be a good practice for any web developer/designer. But how would you center a DIV? If you’ll do a page and you’ll want to optimize the contents for a specific resolution and center (this should be default and desired way) the contents then this will be one of your first CSS questions.

The answer is very easy. Supposing you have the following HTML fragment

<body> 
    <div id="content">My page</div> 
</body>

Then centering the content DIV will be made using the following CSS code:

BODY { 
    text-align: center; 
    min-width: 800px; 
} 

DIV#content { 
    margin-left: auto; 
    margin-right: auto; 
    width: 800px; 
    text-align: left; 
}

Now let’s see what exactly the code is doing. Centering the div horizontally is pretty easy. Simply specify a width (this is mandatory, otherwise it won’t work – usually it will be the resolution for which you want to optimize) and then set the right and left margin widths to auto.

Unfortunately only this won’t do the trick in IE (big surprise :D) and it will require another small hack. You have to set the text-align property for the BODY to center and then redo it for the DIV.

One last thing: in Mozilla, when resizing the window, a part of the DIV will fall on the left of the page, making the page unusable. Simply specify a min-width for the BODY.

If you take into account that you can replace BODY with any other DIV, then you have a general DIV centering method in just a few lines of CSS code.