A gorgeous login form concept

13 Replies

These days I am working on a couple of semi-stealth hobby Web apps in my spare time and, well, I want them to look gorgeous. Yesterday I was thinking about styling the login form for one of the apps and make it somewhat different to all those boring login forms we see everyday and everywhere on the web.

Sometime ago I read an article about this idea of showing labels behind fields rather than next to them and fade them out as soon as the user types in some text and I liked it. The login form that I have designed is based on the same idea but it’s even more gorgeous!

They say a demo is worth a thousand words so without further ado here’s the demo page. Go ahead and type in some text in the fields to see the effect.

As you can see rather than fading out the label, we move it to sit on top of the field. But the devil is in the details. In other words, the login form renders well even under the following conditions:

  • In browsers that do not support stylesheets (e.g. in Lynx)
  • With JavaScript disabled
  • In IE 6 (IE 6 is still sooo popular in archaic environments). Well, no, just kidding. I don’t care about that creepy wombat anymore.

HTML Page

CSS

JavaScript

Update 1 – 3 July 2011:

I found a bug in the initial implementation given above a couple of days ago. Suppose that the login field contains one character and then the user quickly presses backspace and writes another character. This leads to the label staying behind the field while it’s not empty. Changing installAnimation like below fixes this bug:

Fixed installAnimation

This alternative implementation stops all the currently queued animations for the label element before starting a new animation.

Introducing the Robot Attack theme for WordPress

Leave a reply

Robot Attack is a weblog theme originally developed by Opera for their My Opera service. I used to blog on Opera before switching to WordPress and I really liked their themes. After the switch I searched and searched but didn’t find a WP theme that I liked enough. Most beautiful WP themes out there are not suitable for programming blogs. So I finally reverse engineered the Robot Attack theme and converted it to a WP theme with some minor tweaks here and there. An initial version of Robot Attack for Opera is available at Github. However right now it’s far from perfect. For one, currently it doesn’t support widgets. And then, the profile photo should be changed manually.

So, if you are a PHP guru, like this theme, and want to make it even better, you are more than welcome to contribute to the project by forking it and submitting your patches.

One thing that surprised me quite a bit was how easy PHP is to read and how quickly you can become productive writing PHP code. The learning curve is so gentle that you can hardly notice it. Another surprising thing I found in WP’s codebase is that rather than passing multiple parameters to a given method, they encode all the parameters for that method in a string and then pass that in. Weird.

Introducting Trimify

Leave a reply

Quite often users accidentally add redundant white spaces before or after text they enter in web forms. This can lead to an inconsistent database and also complicate, or even worse, break model validation. As such it’s necessary to intercept all textual data and remove these extraneous white spaces before models are validated and form data are persisted. Trimify is a Ruby gem that automates this process.

For example, let’s pretend that we have a Post model that has a title and a body. In order to trim content of title and body before validation, all we have to do is:

By default, trimify converts blank strings to nil. This can be overridden by setting the :nilify option to false:

The current version of Trimify is only compatible with Rails 2.3 but I am planning to release a Rails 3 compatible version soon. To use Trimify simply install it by running gem install trimify. The project is hosted at Github.

Acknowledgments

Trimify is inspired by the nilify plugin written by Tobias Schmidt.

Closures for Java open a new door for logging: Logosure

1 Reply

For a long time we Java programmers have relied on conditional blocks to guard against unneeded string concatenations and other expensive computations that occur when we want to create complex log messages. In other words, we want those concatenations to occur only when the logger will actually log them.

While SL4J’s use of vararg parameters eliminates a huge chunk of these conditional blocks, there still are (possibly rare) cases that creating a log message involves more than just string concatenations and as such it is still necessary to guard the block of logging logic inside a conditional block.

Thanks to Java closures this is not true anymore. In what follows I present a basic implementation of a prototype proof-of-concept logger called Logosure that relies on BGGA closures and skips execution of chunks of logging logic when their corresponding levels are turned off.

The Logger

Our logger is very simple. It only contains two different logging levels: INFO and WARNING. For the sake of simplicity, the levels do not have parent-child relationship. In other words, if the logger’s level is set to INFO, it only emits INFO level logging messages and when it’s set to WARNING it only emits WARNING level log messages.

Again, for the sake of simplicity, our logger only prints to the standard output.

And Level is an enum:

The only interesting part of this logger class is the first log method: it receives a function type as its second parameter that returns a String object. It invokes the logging block passed to it only if the current logging level is equal to the level passed in as the argument. Using this Logger is very simple:

In the example above the code inside the third logging block won’t be executed at all. This happens all without littering our source code with conditional blocks.

As Java closures are still work in progress and the syntax is still a matter of debate it is too soon to implement a full-fledged closure based logger, but I believe that once Java closures become finalized we will see logging frameworks adopt closures in similar ways.

You can fork the current version of Logosure from Github.

Java and XSLT: A bug story

2 Replies

A few days ago I was busy removing our project’s dependency on Apache Xalan and Xerces (we wanted to use Java’s built-in implementation of XML and XSL APIs). In some of our XSL files, we use Xalan-Java Extensions to call Java methods from the stylesheet file. After removing the Xalan and Xerces JAR files from the class-path and deleting all the references to Xalan specific namespaces and tags from the stylesheet files, all stylesheet parsing and compilation errors disappeared, but the output generated by Java’s built-in version of XSL [cci lang="java"]TransformerFactory[/cci] was different to what used to be generated by Xalan.

After some investigation it turned out that some calls to Java code from the XSLT files are being ignored by the transformer. Debugging the code and stepping through all the method calls down to XSLTC and other internal classes did not uncover the reason for the mysterious skipping of these Java calls.

Suddenly something came to my attention: in some of the XSLT files, we are not interested in the value returned by the Java call; we only call a method to modify the state of the Java class. To do so, we declare a variable in the form of:

To call [cci lang="java"]aUtilityMethod()[/cci] and then never use [cci lang="XML"]$ununsedVariable[/cci] anywhere in the XSLT file again. I decided to use one of these variables in the XSLT file to see if that forces the XSL transformer to call the method, so I added a harmless comment right after the variable declaration in the form of:

Voila! Now the transformer is calling [cci lang="java"]aUtilityMethod()[/cci]. It turned out that Java’s default built-in version of [cci lang="Java"]TransformerFactory[/cci] is either skipping running the select expression for unused variables or is doing it lazily. Considering that XPath expressions are side-effect free and that they only return a set of nodes, it makes sense to implement suchlike optimizations, but the optimizer should check the select expression and omit the optimization if it is a Java call.

But is it a bug? Well, yes and no. The truth is that it’s not working correctly. But on the other hand, as this feature is an undocumented and internal feature of the default XSLT implementation of the JDK, it is an unsupported feature and it is better to avoid its use.

Layer vs Tier

Leave a reply

Some architects use the term “layer” when they to refer to logical grouping of components and “tier” to refer to their physical grouping. However Mark Cede and Humphrey Sheil, in their book on the SCEA exam, define layer and tier somewhat differently. They define tier as … logical or physical organization of components into an ordered chain of service providers and consumers. They refer to client, web/presentation, business, integration, and resource as traditional tiers in architecture. Makes sense.

Then they define a layer as a piece of the hardware and software stack that hoses services within a given tier. This definition of layer is different to other definitions I’ve seen so far. They list virtual platform, application, infrastructure, enterprise services, compute and storage, and networking structure as typical layers of an architecture.

While this definition is somehow different, it makes total sense to consider all these aspects when designing an architecture: Are we going to deploy to Weblogic or JBoss? Are we deploying to Windows or Linux? Will we deploy the application on one or more many-core servers or cheaper multi-core systems? Will we use a high performance PCI-e based solid state storage as our storage system or are we going to use traditional rack-based NAS storages? What DBMS are we going to choose and why?

Decomposition, coupling and cohesion, and volatility

Leave a reply

Decomposition by “coupling and cohesion” and “volatility” are two architectural decomposition methods that are unlikely to be used together in the same project. However it’s possible to first decompose by CoC and identify the parts of the system that should be kept together, and then use decomposition by volatility to isolate the parts that are likely to change in the future. This means that we might need to reduce the cohesion of the system to some extent, but it should make changing or replacing the volatile parts of the system less of a hassle.