Security is always important when you need protected or user specific areas in your application. The easiest way for a basic security is the configuration of a security constraint in your web.xml file. If you are using Tomcat all you need is a Realm. This works well for static users in a file or if you are beginning your application with the standard database layout for the Tomcat JDBC Realm. If you have a look at the database layout this won’t fit well for most of the applications. You need more options, but Tomcat is very limited in this point.

If you need more options you should have a look at Spring Security (formerly known as Acegi Security). There are a lot of options in Spring Security, but I will give you an example, not a list of features copied from the documentation.

… more

As promised earlier, i’ll discuss in this post how we load the Javascript modules we have written over the last months. Please note that despite i am mainly talking about portlets in this post, the technique described is also usable in web applications that need to load additional Javascript after page load.

The setting

Let me explain the structure of our project a bit. The main constraint we are facing when developing rich user interfaces for the web platform is that we were up to do so using Java Portlets. Using the portlets standard (JSR-168), we are able to meet our customer’s needs in a way we never could have done when developing traditional, monolithic web applications. But this flexibility comes at a price: we do not know which apps are on a page when it gets loaded; further, we want to be able to add new portlets to each page at any time. From a Javascript perspective, this means that traditional “just put script tags into the header”-style Javascript coding will lead to a very bad user experience, since every page would be bloated with stuff the user will never use and – even more important- the user experience will degrade as we are adding new features to our product, even if our customer does not need or want the new features. As explained before, adding Javascript code to HTML/JSP Parts of the Portlets were no option and would have caused massive double-loading of script code. As our platform grew, we saw the need to put together a Javascript library to support code reuse up front. We clearly needed a mechanism to load our Javascript modules as they are needed. After some experiments (including the use of unholy synchronous XHR calls… shame on me!), we tried the YUI Loader.

Meet the YUI Loader Utility

Its no secret that we are using YUI in our product. As YUI comes with a special module for loading dependencies, the YUI Loader Utility, we explored if we could use YUI for our needs. The Loader’s feature list reads like our wish-list:

• Reliable, sorted loading of dependencies
• Safe, efficient mechanism for adding new components to a page on which YUI may already be present.
• Automatic use of rolled-up files.

So we’ve developed our own solution on top of the YUI loader for our Framework. It consists of two components: A Compile-time dependency analyzer and a configuration file generated by the dependency analyzer that tells YUI how to load our modules.

Analyzing JS dependencies

First of all, every JS module file starts with a set of comments telling the dependency analyzer how the current module is called and what modules are required by the declared module:

// @@module agimatec.topic
// @@requires event, agimatec.datatypes

// Module code goes here
// ...
// ...
// ...
// ...
// ...

// Tell the loader that this module has been loaded
YAHOO.register("agimatec.topic", agimatec.topic, {version:'1.0',build:'000'});

The analyzer (which is current implemented as stand-alone groovy script that is run by maven – we have plans to implement it as maven Mojo) parses the dependency information in the module files and generates a Javascript configuration file for the YUI loader from it:

// ******************************
// Generated Code - DO NOT EDIT
// ******************************
/*
  This script adds all AJF module definitions to the YUI Loader utility as noted by
  '// @@' - style comments inside the *.js files.
  If the global variable 'agimatec_config' is not defined, it is defined by this script.
*/
(function(){
    var arrModules =[

            //...

            {
             name:'agimatec.scaffolding',
             type:'js',
             skinnable:false,
             path: '../../agimatec/scaffolding-2.1.11-SNAPSHOT-min.js',
             requires:["yahoo","event","calendar","tabview","agimatec.topic","agimatec.util","agimatec.util.table","agimatec.util.element","agimatec.util.minibrowser","agimatec.util.datePicker","agimatec.util.hintedText","agimatec.validator","agimatec.metadata"]},

            {
             name:'agimatec.topic',
             type:'js',
             skinnable:false,
             path: '../../agimatec/topic-2.1.11-SNAPSHOT-min.js',
             requires:["event","agimatec.datatypes"]},

            {
             name:'agimatec.util.browser',
             type:'js',
             skinnable:false,
             path: '../../agimatec/util/browser-2.1.11-SNAPSHOT-min.js',
             requires:["yahoo","dom","event","animation","datatable","agimatec.topic","agimatec.util","agimatec.util.yui","agimatec.util.lucene","agimatec.util.element","agimatec.preferences"]},

            {
             name:'agimatec.util.connector',
             type:'js',
             skinnable:false,
             path: '../../agimatec/util/connector-2.1.11-SNAPSHOT-min.js',
             requires:["yahoo","dom","event","container","datatable","agimatec.util","agimatec.metadata","agimatec.util.table","agimatec.portletservice","agimatec.util.minibrowser"]},

            {
             name:'agimatec.util.context',
             type:'js',
             skinnable:false,
             path: '../../agimatec/util/context-2.1.11-SNAPSHOT-min.js',
             requires:["agimatec.metadata","agimatec.util"]},

            {
             name:'agimatec.util.datePicker',
             type:'js',
             skinnable:false,
             path: '../../agimatec/util/datePicker-2.1.11-SNAPSHOT-min.js',
             requires:["yahoo","dom","event","agimatec.util","agimatec.util.hintedText"]},

		 // ...
    ];

    agimatec_config = agimatec_config || {};
    agimatec_config._modules = arrModules;
    agimatec_config.getLoader = function(){
        var modulesLength=agimatec_config._modules.length, i;
        var configObject = {};
        configObject.base = agimatec_config.yuiBasePath;
        if(agimatec_config.moduleFilter){
            configObject.filter=agimatec_config.moduleFilter;
        }
        if(undefined !== agimatec_config.allowRollup){
            configObject.allowRollup = agimatec_config.allowRollup;
        }
        // configure the default skin
        configObject.skin = {
            'defaultSkin':agimatec_config.defaultSkinName,
            'base': 'assets/skins/',
            'path': 'skin.css',
            'rollup': 3
        };
        var loader = new YAHOO.util.YUILoader(configObject);
        for(i=0; i

This file is included inside the header of every portlet page. You see that thanks to the YUI Loader, we can mix YUI modules with our own ones without hassle, making development of a comprehensive Javascript Library much easier. (If your wondering why we add version numbers to the referenced module names, see this article)

Loading a module is as easy as:

// ...

var loader = agimatec_config.getLoader()
loader.require("agimatec.topic");
loader.insert(function(){
	// use agimatec.topic and ALL of its dependencies here !!!!
});

You see that using modules is very easy. All you have to do is to tell the loader what you need and provide a function that should get executed as soon as the dependencies are resolved by adding the noted Javascript files.
This solution served us very well in the last months, in fact our complete webapp development depends on this loading mechanism. It made growing a stable and feature-rich javascript library possible for us without destroying the user experience.

This post just scratches the features of our Javascript module tooling. We have also added support for a module description file format that allows us to describe Javascript modules using XML and generate the loading and dependency management code, along with support for “rollup” JS modules that allow us to reduce the number of requests needed to load portal pages.

If you are interested in this component, just tell us so in the comments and we will see how fast we can get this utility out of the door as Open Source.

This is part two of an article series about Ajax Portlet development. In my next post, i will tell you about how we handle inter-portlet communication in our framework and how our approach makes our application extremely flexible without hardcoding dependencies between portlets.

Eight month ago I posted this entry in german. After a comment that this post is needed in English, I will translate it and rethink if I would confirm my pro and con.

Could you compare Ajax and Flex? Sure! Both are technologies in the web frontend, which cover the same domain.

Should you compare Ajax and Flex? Sure! To learn more about the strengths and weaknesses and pull the right technology for the use case out of the hat.

… more

Im letzten Teil der Blog-Einträge zur JSR-303 möchte ich einige Ideen für Integrationsmöglichkeiten vorstellen, die sich durch die Verwendung von Metadaten ergeben sowie einen Ausblick auf die kommende erste offizielle Referenzimplementierung geben. … more

agimatec-validation framework

Constraints in Annotations oder mit XML-Deskriptoren sind Metadaten, die den Domainklassen zusätzliche Semantik verleihen, die für diverse Verwendungszwecke mit der Constraint-Metadata-API ausgewertet werden kann.

Diese Anforderung bestand auch schon vor Zeiten der JSR-303 und hat die agimatec GmbH dazu veranlasst, das Framework „agimatec-validation“ im Frühjahr 2007 zu entwickeln. Das Framework ist seither als Basis zur Erzeugung dynamischer AJAX Oberflächen für Portlets und zur Validierung in Webservices produktiv im Einsatz.

Durch die konzeptionelle Nähe war es bei Erscheinen der JSR-303 möglich, das agimatec-validation Framework so zu erweitern, dass damit rasch die erste und bislang vollständigste Implementierung des Specification-Draft als OpenSource veröffentlicht wurde. … more

Die Modellschicht ist das Kernstück der meisten Anwendungen und beeinflusst Schnittstellen, Datenbankdesign und Oberflächen. Validierungsregeln und Metadaten, die über die Typinformationen von Java hinausgehen, können mit Hilfe von Annotations oder XML, deklariert werden. Daraus ergeben sich Chancen zur Verbesserung der Konsistenzprüfungen und Verarbeitung der Modellschicht in unterschiedlichen Anwendungslayern.

Neben den seit Jahren bekannten proprietären Validierungsframeworks liegt seit März 2008 mit der JSR-303 ein Spezifikationsvorschlag für eine Java API für JavaBeans vor, der zukünftige Tools und Standards beeinflussen wird.

In den folgenden drei Einträgen stelle ich

a) Grundkonzepte der JSR-303
b) eine erste Implementierung des Standards
und
c) Beispiele für Integrationsmöglichkeiten und die Referenzimplementierung
vor.
… more

Java limits the number of method parameters to 255 (static methods) or 254 (non-static methods) or less if parameters are of type long or double. Fine, but this does not mean that you ever should get even near this limitation. If you ever feel the need of creating a method with more than four or five parameters then you should lean back for a moment and think again about your application design.

Methods that have too many parameters don’t communicate their intention that well which decreases code readability and potentially makes maintenance more difficult. Even worse, if parameters of the same type are used, they can be easily mixed up by accident in a method call.

Having said this, let me give you an example I stumbled upon recently while digesting the code of a webservice API that we are working with:


public User updateUser(
String userId, String password, String emailAddress,
String languageId, String timeZoneId, String greeting,
String resolution, String comments, String firstName,
String middleName, String lastName, String nickName,
String prefixId, String suffixId, boolean male, int birthdayMonth,
int birthdayDay, int birthdayYear, String smsSn, String aimSn,
String icqSn, String jabberSn, String msnSn, String skypeSn,
String ymSn, String jobTitle, String organizationId,
String locationId);


You get my point? So, we are already looking forward for the next API update, which will probably add facebookId, twitterId, flickrId, diggId, deliciousId, stumbleUponId, lastFmId, youTubeId and slideShareId to the list.

Stay tuned and may the source be with you.

Maybe this is a good FAQ entry for Lucene:

Is it possible to run Lucene on an older Sun Fire T2000?

Yes, but don’t call it run.

Some statistics (using Compass + Lucene)

Index creation (5000 objects): 14502ms

Initial search (“*”): 9544ms

Compare this to a 2.2 Ghz MacBookPro:

Index creation (5000 objects): 1071ms

Initial search (“*”): 614ms

Obviously (ok, it wasn’t for me) the single FPU is the bottle neck.

I wanted to integrate our Flex application with tests into our Maven build. A few days ago I moved the app to Flex 3 and changed the Maven Plugin from the Maven2 Flex Plugin to Flex-mojos. Now the artifacts are in the repository and you don’t need to install the Flex SDK to build the application.

We have written the application as a demo in the first place and now wanting to test it in the wild. Because we use Cairngorm the application is well structured and contains as view layer only minimal parts of logic. Yes, we could include unit tests, but integration tests are far more interesting (from my point of view). In a large code base it could happen, that because of refactoring some things are broken. No deal, if you have tests and a CI system. But in the Flex app there are just tiny parts which I could test in a normal unit test.

Okay, so it should be integration test. Sounds good and not too complicated. There should exist a lot of frameworks because a lot of people start to use BlazeDS and other stuff in Java environments. Just something to start the app, run some tests and get the result back in the CI system.

I started to search on google and was surprised. Most of the blog posts I have found on that topic are just two month old. And there are not so many posts about that topic. With the combination of those posts I figured out, how to solve that problem. What problem?

• Integration tests of our Flex app
• Integrated in Maven
• Should work together with Cairngorm (would be more complicated with some unit tests frameworks)
• Could be Selenium (to start the app and run tests)
• Should be integrated in our continuous integration server TeamCity
• Could be written in Java

… more

As mentioned earlier, we are doing some heavily ajaxified portlets over here at agimatec. When we switched to this Javascript-Centric Portlets, we had to solve a problem more people tend to have: The fundamental flaw of Javascript to depend on global variables for linking and the resulting clash of function names we wrote for our portlets. There is a wildly-published way to handle this, which is not suitable when writing more than a few Javascript functions, and the way we handle this problem. But let’s start with a description of the commonly advised way of handling this problem and how that way falls short when doing serious Javascript in portlets.

The easy way

When consulting the portlet books on the market or Sun’s own tips, you’ gonna find one easy solution to the problem: using the portlet namespace for your Javascript. The portlet namespace is a portlet-instance specific string that is suitable to identify assets of a portlet instance. So the easy way out is to use it as prefix or post fix for the functions you write:

<!-- Example: JSP page -->
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>

Wow, that was easy. But there are some drawback when doing this:

• you have to stick to define your Javascript inside the portlets – no external Javascript files!
• being unable to define external Javascript files, there is no easy way of sharing Javascript code between portlets, which is not DRY
• Debugging gets even more painful with function names like “show_<insert some lengthy string here>()”

So, if your are up to make heavy use of Javascript and Ajax-based rich user interfaces, this is a no-go.

Using external Javascript files

So, loading Javascript form external file is the way to go. So here is our approach to the problem:

Use Javascript namespaces

We are putting all our stuff into one global variable, called “agimatec” (at the time we chose the name, we were not aware of Douglas Crockford‘s advice on making globals uppercase – otherwise we would haven named it “AGIMATEC”). This ensures that we’re leaving all third party scripts on the page untouched. Each portlet has its own (sub-)namespace inside this global.

Use a convention to locate the script files

We’re putting our javascript files into a java-like folder structure that reflects our namespace structure, so the portlet “Clientis Edit User” is put into the namespace “agimatec.portlet” and the corresponding file can be found under “agimatec/portlet/clientisEditUser.js”

Use a common initialization method for all portlets

All our portlet scripts must define the function “getPortlet()”, which returns a “raw” version of the portlet script.

Let a library create portlet script objects

Last but definitely not least we have written our own library to create portlet instances. The library contains a function that takes the portlet namespace string, along with the name of the portlet Javascript object, creates a new instance by calling “getPortlet()” on the Portlet object and puts the instance into its own namespace which is created using the portlet namespace:

/**
* Create a portlet namespace instance.
* @param {object} portletObject           A raw portlet namespace
* @param {string} portletNamespace    The Portlet ID as given by the portlet container
*/
agimatec.createPortletInstance(portletObject, portletNamespaceId){
    var rawNamespace = portletObject.getPortlet();
    portletObject[portletNamespaceId] = rawNamespace;
}

Using this technique, we are able to write clean, fully namespace-wrapped portlet scripts that have no problems with colliding function names and can co-exist even in multiple instances on one page without problems. As bonus, two instances of the same portlet on one page only load the external Javascript file once.

One major thing is not mentioned of this post: how to load the portlet scripts. We are using the YUI Loader for loading the portlet scripts, amoung other things. I’ll cover this in another post in the next weeks, so stay tuned.