width="200" height="20"
hasText="true"
progressValue="7"
maxProgressValue="10" id="testBar" showOnlyIntegers="true" />

Now, you want to animate it so that it progressively reaches its progressValue. Something like the following will be needed :

function animateProgressBar(progressBarName, targetValue anim) {
dojo.event.connect(
anim,
“onAnimate”,
function(e) {
var bar = dojo.widget.byId(progressBarName);
bar.setProgressValue(targetValue * e.x / 100);
}
);
}

dojo.addOnLoad(
function() {

var anim = new dojo.animation.Animation(
new dojo.math.curves.Line([0], [100])
, 2000);

animateProgressBar(
“stressLevelProgressBar”,
7 ,
anim
)

anim.play();
}
);

And it should be working…

Something important for the web development community in this release is the  support for scripting languages. In fact, the trend, that has been started with Java Hotswap, is to create tools that allow Web Frameworks to be more productive for developers.

Indeed, developers are tired of the develop / build / deploy cycle, and would prefer to work with the PHP-like develop / reload in browser development cycle. Well, scripting is a step in that direction, and would allow to :

• Keep the domain layer as strongly-typed POJOs, that are unit-tested and constantly refactored to keep a good design.
• Write the Web Controllers (the C in MVC) in any scripting language (the view being written in any already-existing templating language, such as JSP or Freemarker). This allows rapid development and since the view is hardly reusable anyways, it’s better to throw it away and recreate something from scratch when needed.

Efforts toward that direction have already been started, as relayed by these few blog entries and articles :

• Christian groovin’ with webwork 2
• Groovin’ with Webwork 2
• Groovin’ with Webwork 2 : using Groovy as actions

So, now the next step is to have universal support for that kind of development, and have better IDE support that will allow refactoring both in the scripted controllers and the view (JSP, Freemarker..). In fact, there is currently no way to make sure nothing is broken besides writing functional (Selenium, Canoo Webtest, HttpUnit…) tests.

The problem

As an Internet user, you need to keep track of one account/password pair for each website you use. It is then necessary to choose between having the same password everywhere (the weakest part of the security chain is thus the weakest website…), or maintaining a potentially long document with all the website/password pairs…

As a Software developer, you need to keep track of all the system passwords (.htaccess passwords, database URL/passwords, accounts on the companies’ computers, and so on..).

Finally, as a System Administrator, you need to keep track of all the system’s passwords, which include each application’s password (MySQL root password, SYMPA password, LDAP Manager entry’s password, root passwords on each machine, Apache SSL certificates keys’s protection passwords….). Additionally each administrated (web) application has its own “admin” account with an associated password, and these applications’ configuration files often include passwords for other components of the system (database accounts/passwords, LDAP password, …). Even efforts such as using centralized LDAP authentication result in having some LDAP’s binding account in the configuration files…

Not only it is a mess to administrate, but it is also a very nice way to forget/mess up with permissions and this can result in weak systems that are easily hackable, because of the complexity.

The solutions

The solution to improve the end users experience would require the whole internet to switch to Single Sign On Solutions. Some vendors are pushing centralized SSO solutions, like Microsoft Passport, which is a pretty criticized solution, both technically and ideologically. Others are pushing open, distributed SSO solutions, like OpenID and LID.

Now that everybody is talking about the “Web 2.0″, it is time to think about improving the user’s experience and security, and this implies adopting one of these technologies in a large scale.

Concerning the Software developer’s and System Administrator’s problem, the problem is way more complex. Sure, the total number of accounts and passwords can be limited by using centralized authentication schemes for applications that support it – all should in a perfect world – (You can find more information about using a centralized LDAP repository for Linux/PAM on this page. If you go this way, you will have to find a good, secure distributed/network file system to share /home directories), but the way applications are currently designed does not open the door to an easy solution. Each application/server has a special “admin” mode that gives the user more permissions, and it is common practice to protect that account using a user-defined password.

So, I’d like to know if anyone has ever thought of something nice that could potentially change the world for system administrators and software developers ? One thing I can potentially think of would be a solution where specific roles would be defined and standardized (system administrator, database administrator, ….), and each application would work with the system to validate a set of credentials (and check that the given user has the required role) supplied by the user before giving the permissions. In other terms, this would be some kind of PAM with the addition that system groups would be standardized. And frankly, with the number of applications and needs, I do not really see this as a possible solution.

Another option would be to switch to certificates to authenticate the users. Coupled with well-defined discovery+ storage solutions, there could be some /etc/certificates folder (+ some mechanism to associate certificates with applications roles) containing public keys that applications would lookup in order to validate user credentials. This would imply that each application could somehow challenge the user who would have previously stored his private key on a system that would act as a mediator between each application and him. Humm.. well.. this doesn’t really sound as an easy solution to me…

So, the real solution to all these problems would be to leverage UTF-8 as the default encoding for every application. If communication is necessary with a legacy system that does not support UTF-8, then whatever ISOxxx encoding is acceptable in a small wrapper that translates the stream to a UTF-8 one. In order to accomplish this :

1. Make sure the default locale on all your systems are UTF-8. Recent linux distributions like Ubuntu luckily default to that.
2. When writing or reading anything to a stream, Java (and I believe other languages too) defaults to the default encoding on the system. Do NOT trust this value, and make sure to only use the Reader/Writer constructors (example: OutputStreamWriter provides a few constructors that take the Charset. Use these constructors at ANY COST, and possibly write Jalopy rules that prevent the use of the default ones).

From a more general point of view, it would be desirable to have UTF-8 everywhere : Domain Name System (which stil uses ASCII), SMTP (which reverts to ugly hacks to allow people to write non-ASCII characters), etc…

The internet is an international place, and as such, should not be ASCII-centric. This means that if the standardization organisms (IETF, ..) do not realize this, we are going to see more and more forking such as China’s reform to its DNS, which is obviously a bad thing for the community since it creates more interoperability issues.

DWR is basically a Remote Method Invocation framework that allows to “export” server-side Java Objects to the javascript-enabled web client thanks to a transparent communication layer that dynamically (at runtime) generates the client stubs. So, in other terms, You have server side Java methods that you want to run from the client. DWR takes these classes/methods and provides you with a javascript file (generated on-the-fly) that provides javascript classes/methods that once called, will handle all the method calls, marshalling/unmarshalling, etc..

DWR does not provide any UI-abstraction layer. In order to create nifty graphics, you have to complement it with another framework like Dojo toolkit, or Script.aculo.us
Since the official documentation isn’t particularly clear on how to get DWR to work with Spring-managed beans and Java5 Annotations, here is a mini-HOWTO that completes it. (Anyone is free to use this HOWTO under any OSI-approved Open Source license). Nothing is easier to understand than a simple example, so we are going to create a Client Side Logger API that logs the events on the server-side thanks to Log4j. (A real-world example should use some abstraction layer like Commons-Logging , and should result in the creation of a backend to some of the popular Javascript logging frameworks, like Log4Javascript, instead of reinventing yet another logging API).

As a sidenote, DWR is part of the typical Bleeding Edge Web-Framework Stack that I wrote about in a previous post. Surely, not everybody uses this Stack, but it gives an idea of what the current trend in the Java world is. The current java world is full of innovation. Every 2 days, a new framework arrives on the scene, and beginners are more and more afraid of the overall complexity of the platform (if we can call this a platform, because it more looks like a set of unrelated  tools that people struggle to use together, in opposition to Microsoft .Net’s stack that we can safely call a “solution” because of the tight integration between the components). Innovation is doublessly a very good thing, and nothing should prevent innovation from happening. However, I believe it is also very important to document the best practices and tools and try to gather the community around a limited set of paradigms and frameworks. It doesn’t make sense to have a different framework for each programmer in this world. And in my humble opinion, using such an RMI-like system for communicating between Java classes and Javascript is definitely one of the best and efficient (from the developers viewpoint) practices around.
Java class

The first step is to create the annotated Java5 class that will be exported to the Javascript client. All exported methods must be annotated thanks to the @RemoteMethod annotation, and the @Create annotation is used at the class level to tell DWR that the class is instantiated using the Spring Framework. The beanName parameter must reflect the name of the bean in Spring’s application context file.

@Create(creator = SpringCreator.class, creatorParams = { @Param(name = “beanName”, value = “clientSideLogger”) })
public class ClientSideLogger {

public static Logger logger = Logger.getLogger(ClientSideLogger.class);

/**
* @param arg0
* @see org.apache.log4j.Category#debug(java.lang.Object)
*/
@RemoteMethod
public void debug(String arg0) {
logger.debug(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#error(java.lang.Object)
*/
@RemoteMethod
public void error(String arg0) {
logger.error(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#fatal(java.lang.Object)
*/
@RemoteMethod
public void fatal(String arg0) {
logger.fatal(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#info(java.lang.Object)
*/
@RemoteMethod
public void info(String arg0) {
logger.info(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#warn(java.lang.Object)
*/
@RemoteMethod
public void warn(String arg0) {
logger.warn(arg0);
}

Spring Configuration

In order to instantiate the ClientSideLogger class with Spring, we can create the following dwr.xml file, that is going to create a “clientSideLogger” singleton :

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop” xmlns:tx=”http://www.springframework.org/schema/tx”
xsi:schemaLocation=”http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx.xsd”>

<bean id=”clientSideLogger” class=”fr.cvf.vodoo.ihm.portal.dwr.ClientSideLogger” />

</beans>

Web.xml glue

The next step is to write the usual glue (setup the DWR/Spring servlet, etc…).

In your web.xml, you can add :

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:spring/dwr.xml</param-value>
</context-param>

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!– DWR servlet , that should list all annotated classes–>
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>classes</param-name>
<param-value>
package.ClientSideLogger
</param-value>
</init-param>
</servlet>

<servlet-mapping>
<servlet-name>dwr-invoker</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

Javascript Code
The final step is to use the logging using the automagically generated javascript API.

First, make sure the following javascript files are included :

<script type=’text/javascript’ xsrc=’/dwr/interface/ClientSideLogger.js’>
</script>
<script type=’text/javascript’ xsrc=’/dwr/engine.js’></script>
<script type=’text/javascript’ xsrc=’/dwr/util.js’></script>

And you can use the API :

ClientSideLogger.error(“error message”);

That’s all you have to do !

Not all frameworks are presented (reasons explained), but it’s a good start. Keep up the good work !