Vaadin is a good fit for all the web-applications that fit in the general bucket of “enterprise support tools.” The reasons why are covered after the jump.

What’s special about it?

I think the biggest departure from the frameworks that I’ve been using for web programming is that Vaadin is stateful. The client state is tied in the session with a state on the server. This has some major implications for deployment, such as requiring sticky-sessions in load-balancing and shared caches for failover.

The developers of Vaadin made the framework stateful to facilitate building all the interaction code on server. The browser is only used for display. This means that you can use your ordinary Java toolset to walk through your event handling. You don’t need firebug or any javascript knowledge, unless you are creating a custom widget. The Book of Vaadin provides lots of detail on this model in their chapter on Architecture.

I have no desire to repeat the documentation here, but just provide enough of a glimpse in case you are more interested.

Would I use it?

I think Vaadin fits in nicely within a specific niche. I would not use it for a normal website (nor do they recommend it), nor would I use it for a consumer-facing or heavily trafficked web application. The stateful model just doesn’t scale like that.

However, there’s a whole other class of applications, management consoles, intranet web-apps and other systems that could just live on one server that are a perfect fit for Vaadin. Even more so if you can control which browsers the users run (IE javascript is really slow). These are the things that I really liked about the product:

• Complete documentation. You don’t have to dig through a user-generated wiki. They have the whole book up on the website.
• Friendly forums. A search shows multiple people that had the same problem. Instead of the usual, “use the search function,” that you see on a lot of other forums, there were real replies.
• All java. A developer can build an entire web-application with just Java. That’s really important if web-application programming isn’t a core competency.
• Doing things the Vaadin way is really easy. For instance, the hbncontainer makes building an app around hibernate trivial.
• The widgets really work like their desktop equivalents. The table responds to keystrokes and the split panels work.
• Vaadin hides the complexities of layouts on the web. You just specify your container strategy.

Were there problems?

While Vaadin is pretty easy and built on a language I’m familiar with, there was still a learning curve. Most of my issues came from doing things outside of the Vaadin way.

• Vaadin and Maven don’t seem to get along too well. Trying to install the Visualizations plugin was a nightmare. Eventually I had to install it and its dependent sources into my test project to build the widget set.
• Documentation and examples on how to leverage your existing DAO layers was sparse and incomplete.
• The same goes for Spring integration, esp Spring Security.

Conclusion

If had to build a web app and didn’t have a web team, Vaadin is good way to go. You can build apps that have more than the basic “developer” look and feel without a whole lot of effort. The documentation lapses will surely disappear as the framework gains steam.

The next post I’m going to write is about how to use your existing DAO structure with Vaadin.

One of my tasks was to convert all relative paths in an XHTML document to absolute paths. The server prefix was set as variable in the stylesheet. The transformer would have to determine if the selected path is a relative url, then work to resolve what the absolute path is based on the root passed into the page. It could be done with an advanced XSTL template, but since we already had the resolution function written in Java, it made more sense to write a Java plugin to Saxon. One of the missing features of Saxon HE is the seamless, reflection based integration of plugins. However, one can use the Extension Function API to achieve the same results.

First on the agenda is creating an extension point:

package net.vijedi.saxon.extensions;
 
import net.sf.saxon.expr.StaticProperty;
import net.sf.saxon.expr.XPathContext;
import net.sf.saxon.functions.ExtensionFunctionCall;
import net.sf.saxon.functions.ExtensionFunctionDefinition;
import net.sf.saxon.om.*;
import net.sf.saxon.trans.XPathException;
import net.sf.saxon.value.SequenceType;
import net.sf.saxon.value.StringValue;
 
public class AbsolutizeUrl extends ExtensionFunctionDefinition {
    /**
     * The function will need a name you can call
     */
    private static final StructuredQName qName =
            new StructuredQName("", 
                    "http://vijedi.net/", 
                    "absolutizeUrl");
 
    @Override
    public StructuredQName getFunctionQName() {
        return qName; 
    }
}

The extension point extends ExtensionFunctionDefinition. I went ahead and created a constant that will store the name of the class and the function to return it. You will use this to access the function from inside of your XSLT.

Now it’s time to think about the interface of this function. The function can take up to two string parameters, the absolute url base, and an optional url to process. The url to process is optional since it is not a requirement that an <a> will have an href attribute. The function will return either a string or null if the second parameter does not exist. This is how you define this interface in the code.

private final static SequenceType[] argumentTypes = new SequenceType[] {
        SequenceType.SINGLE_STRING,
        SequenceType.OPTIONAL_STRING
};
 
@Override
public int getMinimumNumberOfArguments() {
    return 1;
}
 
@Override
public int getMaximumNumberOfArguments() {
    return 2;
}
 
@Override
public SequenceType[] getArgumentTypes() {
    return argumentTypes;  
}
 
@Override
public SequenceType getResultType(SequenceType[] suppliedArgumentTypes) {
    return SequenceType.makeSequenceType(
            suppliedArgumentTypes[0].getPrimaryType(), StaticProperty.ALLOWS_ZERO_OR_ONE);
}

Once the interface is defined, it’s time to define the actual work. The actual call is handled by a class that extends ExtensionFunctionCall. I like to define these as inner classes of the ExtensionFunctionDefinition. The pattern for this class is pretty simple. You need to process the arguments to the function. Saxon will give you wrapped arguments that you will need to unwrap. Then you need to call the actual logic (which should be in a separate class for re-usability) and finally wrap and return the value. Just as crucially, you need to override the function that tells the Saxon parser to use your implementation of ExtensionFunctionCall for this definition.

    @Override
    public ExtensionFunctionCall makeCallExpression() {
        return new AbsolutizeUrlCall(); 
    }
 
    private static class AbsolutizeUrlCall extends ExtensionFunctionCall {
 
        @Override
        public SequenceIterator call(SequenceIterator[] arguments, XPathContext xPathContext) throws XPathException {
 
            StringValue pageUrlSV = (StringValue) arguments[0].next();
            if(null == pageUrlSV) {
                return EmptyIterator.getInstance();
            }
 
            StringValue hrefUrlSV = null;
            if(arguments.length > 1) {
                hrefUrlSV = (StringValue) arguments[1].next();
                if(null == hrefUrlSV) {
                    return EmptyIterator.getInstance();
                }
            }
 
            String pageUrl = pageUrlSV.getStringValue();
            String hrefUrl = hrefUrlSV.getStringValue();
 
            // Url transformation magic goes here
 
            Item item = new StringValue(fullUrl);
            return SingletonIterator.makeIterator(item);  
        }
    }

That completes the definition of the function. You can find the full example code on GitHub.

Now that you’ve written an extension, you need to tell Saxon that this function exists. For this, you will need to add the following to wherever you are currently accessing the TransformerFactory.

private TransformerFactory getTransformerFactory() throws net.sf.saxon.trans.XPathException {
    TransformerFactory tFactory = TransformerFactory.newInstance();
    if(tFactory instanceof TransformerFactoryImpl) {
        TransformerFactoryImpl tFactoryImpl = (TransformerFactoryImpl) tFactory;
        net.sf.saxon.Configuration saxonConfig = tFactoryImpl.getConfiguration();
        saxonConfig.registerExtensionFunction(new AbsolutizeUrl());
    }
    return tFactory;
}

This code checks to see whether or not you’re using a Saxon processor, and if so, registers your new function within it.

Finally, it’s time to update the stylesheet to use the new function. You’ll need to add the function to the namespace, using the same parameter found in the second argument of the StructuredQName constructor.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:vn="http://vijedi.net/" version="2.0">
</xsl:stylesheet>

Now you can use it like any other function:

<xsl:attribute name="href">
    <xsl:value -of select="vn:absolutizeUrl('http://www.example.com/absolutepath', @href)" />
</xsl:attribute>

Sanitize_email is the first solution I tried. It’s configuration is straight forward and it can either be installed as a plugin or gem. Personally, I like gems because they can be shared across multiple projects. Once you’ve installed the gem, you need to configure an initializer with the following (from their README):

    # Settings for sanitize_email gem.  These can be overridden in individual config/%env%/environment.rb files.
 
    require 'sanitize_email'
    ActionMailer::Base.sanitized_recipients = "jtrupiano@gmail.com"
    ActionMailer::Base.sanitized_bcc = nil
    ActionMailer::Base.sanitized_cc = nil
 
    # optionally, you can configure sanitize_email to to include the "real" email address as the 'user name' of the
    # "sanitized" email (e.g. "real@address.com <sanitized @email.com>")
    ActionMailer::Base.use_actual_email_as_sanitized_user_name = true # defaults to false
 
    # These are the environments whose outgoing email BCC, CC and recipients fields will be overridden!
    # All environments not listed will be treated as normal.
    ActionMailer::Base.local_environments = %w( development test staging )
</sanitized>

You can set the configuration to override the recipients, the cc, and the bcc. One could use sanitize_email to automatically set a bcc for all production emails, along with setting all three to prevent emails from going into the wild. Another neat feature is that it provides all Mailers with the force_sanitize method, which programmatically traps emails through a specific path.

Mail_safe is available strictly as a gem. It’s configuration is a little simpler. The following is the basic config from their README:

  if defined?(MailSafe::Config)
    MailSafe::Config.internal_address_definition = /.*@my-domain\.com/i
    MailSafe::Config.replacement_address = 'me@my-domain.com'
  end

It doesn’t allow distinct addresses for bcc, cc, and recipients, preventing it’s use for automatic override addresses. While it lacks that feature, it does allow addresses for white-listed domains to be delivered, as well as allowing users to provide a proc for the options settings. For example:

    MailSafe::Config.internal_address_definition = lambda { |address|
      address =~ /.*@domain1\.com/i ||
      address =~ /.*@domain2\.com/i ||
      address == 'full-address@domain.com'
    }
 
    # Useful if your mail server allows + dynamic email addresses like gmail.
    MailSafe::Config.replacement_address = lambda { |address| "my-address+#{address.gsub(/[\w\-.]/, '_')}@gmail.com" }

Our choice was to use mail_safe since it did allow white-listed domains to be delivered normally. This fit the feature set of giving us a safety net incase our mock data got pushed to a system with a live mail-server, while still enabling our test users to use the application.

echo -n -e "\033]0;TerminalName\007"

This command will set the name of the terminal to “TerminalName.”

Instead of trying to remember this string, I created a little shellscript:

#!/bin/bash
 
echo -n -e "\033]0;$1\007"

I called this script setname and put it in /usr/local/bin. Then you can call it with:

setname TerminalName

Our lexicon looks a little like this:

music
 \
    jazz
    pop
    funk
    blues
    rock
|
article
 \
    blog
    feature
    review
|
video
 \
    music
    interview
    comedy

Creating an enum for the top level is straight-forward:

public enum Scheme {
	music, article, video;
}

So now how do we get Scheme.music to return the valid values for it’s subtypes? First we need to create a marker interface:

public interface SchemeClass {}

You can add abstract methods on an enum, so we can create a method that will return an array of SchemeClasses:

public enum Scheme {
	music, article, video;
 
	abstract public SchemeClass[] getClasses();
}

And while we’re at it, lets create the enums for the sub-categories (consolidated here, but in practice I put them in different files):

public enum MusicClasses implments SchemeClasses {
    jazz, pop, funk, blues, rock;
}
 
public enum ArticlesClasses implements SchemeClasses {
    blog, feature, review;
}
 
public enum VideoClasses implements SchemeClasses {
    music, interview, comedy;
}

The important thing is that all of these enums implement the SchemeClass interface. Now to get the Scheme enums to return the list of valid subtypes.

Now all that’s left is implementing the abstract method for each of the possible values in Scheme.

public enum Scheme {
    music {
        public SchemeClass[] getClasses() {
            return MusicClasses.values();
        }
    },
    article {
        public SchemeClass[] getClasses() {
            return ArticleClasses.values();
        }
    },
    video {
        public SchemeClass[] getClasses() {
            return VideoClasses.values();
        }
    }
    ;
    abstract public SchemeClass[] getClasses();
}

If you don’t want to use Eclipse, you can replicate this behavior with Maven and run the app out of your working directory.

The first step is to navigate to the location of your code (hereon referred to as $CODE_DIR) and execute the maven task:

$ mvn war:inplace

This will create the entire war structure in $CODE_DIR/src/main/webapp. Take a look. You’ll see a classes and lib directory under WEB-INF.

This is probably a good time to exclude these directories from version control. I use Git, so I added the following lines to .gitignore at the top level of the project:

src/main/resources/webapp/WEB-INF/classes
src/main/resources/webapp/WEB-INF/lib

Now that you have a complete war you can have it deployed in jboss by creating a symlink. Assuming that $JBOSS_HOME is set, you need the following command:

ln -s $CODE_DIR/src/main/webapp $JBOSS_HOME/server/default/deploy/web.war

Startup JBoss and you can now edit your non-compiled resources, like Javascript, JSPs and CSS at will, without a compile/deploy cycle.

If you want similar behavior for changes to code or libraries, there’s just one more step. Running:

mvn compile war:inplace

on its own won’t redeploy the classes. For that, you’ll need to touch the web.xml file. You can do this with the maven exec plugin. This part is Linux/Mac OSX only. If you’re on Windows, well you have bigger problems beyond hot-deploy.

Open up $CODE_DIR/pom.xml and add the following lines:

<plugin>
    <groupid>org.codehaus.mojo</groupid>
    <artifactid>exec-maven-plugin</artifactid>
    <version>1.1</version>
    <executions>
        <execution>
            <goals>
                <goal>exec</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <executable>touch</executable>
        <arguments>
            <argument>src/main/webapp/WEB-INF/web.xml</argument>
        </arguments>
    </configuration>
</plugin>

Now running mvn compile war:inplace exec:exec will redeploy the project right from your working directory. I have this configuration mapped to a keystroke in Intellij to make the process seamless.

The benefits of this approach is that it will work with any IDE or development environment. It also works with JBoss 4.2 and 5.0 (JBoss tools has had some issues with 5.0 because of the VFS changes). It also works every time. JBoss tools would occasionally not update static files.

The downside is that it’s not as seamless nor as fast. It will redeploy the webapp, just as if you had pushed a new war.

The time savings are still substantial and I would give this approach a try if you use an environment other than eclipse for your java development.

So from today on, ViJedi.net will be about software, technology, the software development process and other startup-y topics. All my personal posts, like pictures, random thoughts and the rest will be at a new blog tejus.tumblr.com. Thanks for reading.

I still remember when I first gave you a shot. I had tried other IDE’s, but all they seemed to offer where headaches. Vim and Ant simply worked better.

But then you came along, with compile as you type and amazing CVS integration. Suddenly, my collection of a half dozen command line utilities were reduced to one. I was so taken with SWT and it’s ability to look native on each platform, that I even wrote an entire application in it.

My love only grew when I took a professional development job. I had to use Windows, you made it possible to get something done. But looking back, that’s also when our relationship started to crack. We switched from CVS to SVN, negating one of the greatest advantages you had.

I switched jobs again and this time I was introduced to Intellij IDEA. Sure it was nice, but it didn’t compare to you. It’s version control integration was confusing. It didn’t support all features and languages you did, and it’s auto-compile just didn’t work as nicely. I stuck with you.

But the cracks that appeared earlier started growing. Each new feature you supported and every new plugin written for you never seemed to work right. Everything had rough edges, caveats, and felt distinct from everything else in the system.

You just didn’t take care of yourself. As computers got faster, you got slower. Every editor seems slow to respond to keyboard input. The XML editor is the single worst editor I have ever used. Typing in your IDE shouldn’t feel like telneting over a dial-up connection. You started bloating up to the size of a beached whale in a sad attempt to be everything to everyone. While you allowed everyone to attach to you, you forgot about what made you great in the first place, Java development.

You didn’t keep up with the best practices. You don’t work well with maven projects. Refactoring doesn’t work across the entire workspace. You should never ask me for the location of the source for a class when it is in your workspace. It’s 2010, these are things you should do right by now.

One of your great features was the ability to use external editors for resources managed by the IDE. Unfortunately, whether or not that file was refreshed in the workspace seemed like a decision that rested in God’s hands.

Lets not even talk about version control. The subclipse/subversive split was a disaster and your git support is a joke. You once replaced my entire stack of tools. Now to get anything done, I now have to open a bunch of terminals, gitx, textmate, and you.

Remember that other IDE I played around with? It’s kept itself in shape. It looks better than it ever has. It never promised to do everything, and that’s left it with few wrinkles and sharp edges. It works with a Maven project structure, has real support for Git, and does a fantastic job of editing Java. And now it’s open source too, just like you.

That’s why it’s over. It’s always sad to see something with so much promise ruined by neglect and bloat. But it is what it is and it’s time to move on.

I just had such a project, but the one feature I could not live without was CSS3 selectors. Walking the DOM manually would have taken hours to implement correctly, especially since each page needed to be treated differently. My first thought was to rip out the JQuery selector functions. That’s when I discovered Sizzle.

Sizzle is the CSS3 selector engine written by John Resig that was originally written for JQuery and is now also used in Dojo. Since it’s a standalone library, you can also use it directly for your projects.

The first step is simple, you need to include the Sizzle js file in your page. Once you do that, you can call Sizzle just as you would call $ in normal JQuery.

Examples:

// get all divs
Sizzle("div")

// Get all links in the paragraphs in the sidebar
Sizzle("#sidebar p a")

// Get all li elements under a ul
Sizzle("ul > li")

Just like JQuery, right? Well no. Unlike JQuery, which returns a JQuery object that can be accessed with JQuery’s easy and cross browser API’s. Sizzle returns a list of elements.

If you wanted to set the text of the first link element to “Go To This Page,” then what you’d have to do is the following:

var elements = Sizzle("#sidebar p a");
a[0].innerHTML = "Go To This Page";

If the necessary manipulations are simple, using Sizzle standalone is the way to go. It’s much smaller than a full blown JS library and it gives you what’s normally the most painful part.

It was definitely one of the busiest years of my life. The year started normally enough, with both Sonali and I working for a large public company. Unfortunately, it didn’t take long before the economic meltdown affected them as well and the downsizing started in our division. This overarching storyline probably made the year seem more stressful than it really was, due to the multiple rounds and the general sense that something wasn’t quite right as far back as March. That all ended in September 30th, coincidentally my birthday, when both Sonali and I were let go. On the upside, I had an interview scheduled for later that afternoon. On the downside there was a going away lunch, complete with tequila. More on that later.

While this was all going on, I still needed something to do while building my rails chops and started putting some hours in Journalistics on the nights and weekends. We’ve launched one product, and are coming really close to launching the first preview of our main offering.

Perhaps the biggest work difference in 2009 was some first hand experience on the management and organizational side of product development. The challenges and solutions are significantly different than development. The biggest lesson learned is to not come up with a product plan without also coming up with a sales plan. It doesn’t matter what you build if you can’t convince people to use it.

While much of this post focuses on the negative, it was overall a very positive year. We did some very good work in my time at Premiere and it’s unfortunate we never got our product out the door. While the economic conditions resulted in a lay-off on my birthday, it had a happy ending. The interview was at Vertical Acuity, an Atlanta startup building a new syndication model for publishers. It was a great fit for both parties and I accepted their offer.

2010 finds me back where I want to be, in an small startup working on interesting problems. Being part of a small team with a lot on the line is very appealing to me. Also, since I apparently don’t like to sleep much there’s aforementioned Journalistics beta and the launch of Scoutmob. It’s going to be another busy year, but one that should be as enjoyable as 2009.