Archive for the ‘javascript’ Category


Device Detection Problems in AEM5.6 on Windows 8

April 13, 2013

When exploring AEMs default website geometrixx or geometrixx-media with a Windows8 device that has a touch screen (some of the newer laptops on the market for example)  you are either forwarded to a .tablet.html page (geometrixx) or the mobile site (geometrixx-outdoors). This seems to be a problem with the device detection that is part of AEM5.6. A tool called BrowserMap is used to perform a client slide test to determine your type of device and then you are redirected based on your device and a set of settings on the site.

The documentation from Adobe on how to set up your site for device detection can be found here

To see what AEM thinks your device is, you can go to http://localhost:4502/etc/mobile/browsermap/detect.html – with a Windows 8 Laptop with touch screen and Chrome you will get something like this as the output:


As you can see, the detection thinks the browser is running on a tablet.

Looking at the /content/geometrixx/jcr:content/cq:siteVariant node and the /content/geometrixx_mobile/jcr:content/cq:siteVariant node they both have a cq:variantFamily property with the value ‘geometrixx’. For the main website the media property is set to ‘browser, oldBrowser, highResolutionDisplay’, for the _mobile site to ‘smartphone, tablet, highResolutionDisplay’ – for whatever reason, this is not a String Array property but just a comma separated list and the node type is nt:unstructured – cq:siteVariant is the actual name that the browser detection is looking for.

What’s interesting to me is that on geometrixx, a selector called tablet is added and the browser stays on the same page while the setup in geometrixx-outdoors seems to be the same but there the browser is redirected to the mobile version of the site.

You can force AEM to use a specific device and bypass the BrowserMap detection by adding the parameter device=[device group name] to the URL. The supported device groups by default are:

  • smartphone
  • tablet
  • highResolutionDisplay
  • browser
  • oldBrowser (the latest version of Firefox is considered an oldBrowser)

The BrowserMap library is available on github at The testpage that’s available within AEM is also available online at – the library in AEM seems to be a bit more up to date since it can detect IE10 on Windows 8 (although it thinks that it does not have touch capabilities) – the one on github just reports it does not know the browser.

On the bright side, geometrixx-media does not need the browser detection since it’s a responsive design based website. I highly recommend going that route.


Developing the style and templates/components in parallel for Adobe CQ5

April 10, 2012

In order to speed up development of a site within CQ5, it helps adopting the following process:

  •  Devise templates and components for the site based on mockups
  •  Implement a standard HTML for all templates and components
  •  Develop the components necessary
  •  Develop CSS/JS necessary to support the components

Using this approach, the front end team can develop the CSS/JS necessary for the site in parallel with the developers implementing the components and templates for CQ5. Instead of using a waterfall model where the front end team develops the basic HTML structure first and then provides the code to the CQ5 developers, this approach makes sure the CSS/JS works well within Adobe CQ.

To further minimize the risk of browser incompatibilities and to make sure the site will also look good on mobile devices from the start, it helps adopting a basic CSS/JS framework, commonly known as grid systems.

Some grid systems to consider are:

The grid systems have a well known html structure and features such as reflow that help on smaller screens. Developing your components with a grid system in mind will also make sure the developed components can be reused in the future with a different stylesheet and make your CQ5 projects faster to implement and easier to adopt to a new site style and new features provided by the grid system.

The Adobe CQ5.5 version uses 960gs for the default geometrixx site, however, choosing twitter bootstrap will provide you with more out of the box functionality commonly found on today’s website.

update: we released a bootstrap templating integration for Adobe CQ 5.5 today. See the following link for more information


Example Thick Client App with EXTJS and Java

June 1, 2011

Following up my last post I wrote a small sample application using Java, EXTJS, Jetty and the djproject to create a thick client experience based on these components. I chose the djproject instead of mozswing since it is a lighter download and integrates with an existing web browser on your system instead of bundling an additional web browser with the application.I also provided a power point presentation that runs through the project and explains how it is implemented.

download at

As always, please let me know what you think about this post.


Writing a Thick Client Java Application with EXTJS

October 20, 2010

update: example application

I have been writing thick client applications in Java for a while now. You can produce nice applications with Swing if you know how to and have the right tools and libraries at hand. Lately, however, some of our clients made me rethink the approach for thick client development. We were asked to develop a thick client application for Windows, Mac OSX and Linux. The customer also pointed out that in the future they would like the same application to be web based. This made me rethink the Swing strategy and bring back an older concept we developed for a customer back in 2000. The project is still online at It’s an online carpet configurator allowing the customer to color and custom order a carpet. The project was initially delivered over the web but was also distributed to stores on a CD, allowing the store owners to run the application on a local computer without an internet connection. The approach taken was simple: an autostart executable on the CD runs a webserver as well as a web browser without navigation bars, etc, as one application. To the store, the application looks like a thick client, on the web, it’s just another AJAX style web application.

Back to 2010, we know have libraries such as EXTJS that bring an application look and feel to your web application. Out of the box, EXTJS supports more feature rich components than are supported by Java/Swing. Firefox is a great browser and the mozswing project allows you to bundle Firefox into your Java/Swing application. if you combine this with an embedded web server such as Jetty you can write and deliver a thick client application the same way you deliver a web application. The hybrid approach allows you to handle parts of your application such as file dialogs, etc in Swing. Once a user selects a file to load, you can make a javascript call from your Java/Swing application into the MozSwing browser window to communicate back to your local web server to load the file.

Using this technology stack allows us to deliver a rich thick client experience and at the same time reuse most of the code, apart from specific features such as file dialogs.

The following is a screenshot of the current application we’re building:

Please let me know what you think about this approach. If there is enough feedback I’ll follow up this post with an example application for you to play with.

An example implementation can be found here


Google Chrome JavaScript Speed Compared

September 9, 2008

By now everybody knows Google Chrome beta is available and we have all seen the claims about JavaScript speed. It’s one thing to read about it, it’s another to actually see the speed difference. So I figured I’ll write a little test program checking out how much faster Google Chrome and JavaScript in Google Chrome actually is. This test is by no means a complete test – the claim that JavaScript is faster should be across the board – therefore doing one test with some specific features should be faster otherwise the claim is not really true, now is it?

I’m an old Commodore C64/Amiga guy – so one thing I always liked back then were the copper bars. In short, the C64 and Amiga allows you to change the color of the screen background per line or even per a certain amount of pixels. The computers also had some vertical blank interrupt allowing you to run some code every time the monitor beam is at the top of the screen. People then wrote cool color bars floating around, nicely animated at 50Hz per second. I figured I can do a similar effect in the browser by using a div per raster line and altering the colors with an interval timer every 20ms.

The sample html page can be found here:

The image to the right is a screen shot of the copper bars running in Google Chrome.

sample copper bars

sample copper bars

Speed test results running on a Dell Latitude D820 under Vista:

Browser 200 lines
Google Chrome ~97 frames/sec
Firefox 3 ~70 frames/sec
IE7 ~20 frames/sec

Update: the nightly minefield (firefox beta) gets about 80 frames/sec.

Observation: the test is of course not just a JavaScript speed test but also a test on how fast changes that are made to the DOM can be reflected on the screen. If not using DIV’s but an image to perform the same test (using the JavaScript BMP Library [not supported in IE7]) we see a 50% speed increase for Google Chrome vs Firefox3. Update: Minefield actually beats chrome on this test by about 10%

A couple of notes:

  • There is a faster way to do this if the program does not have to run in IE. You can actually create an inline image with JavaScript with the JavaScript BMP Library ( The library allows you to convert an array of color information and a color pallet into an image. Update: bmp creation with minefield seems to be faster than with any other browser.
  • I did not test with IE8 Beta on Vista since trying to run it forced me to apply the whole windows update and that used an awful lot of disk space (2+ GB)
  • When running into limits (two may lines updated, computer getting slow and running the test in multiple browsers) Google Chrome was way more responsive than Firefox3
  • There seemed to be no big difference in speed between Firefox 3 and the current beta with the updated JavaScript Engine (Shiretoko).

As always, would love to hear your comments on this one.