Friday, August 3, 2012

JSF meets Skinning Awesomeness of LESS

A strength of JSF is in how it enables you to quickly write applications, providing you with a plethora of components abstracting complex functions.

Skinning, Styling & CSS



But when it comes to skinning and styling those components, JSF is not very helpful. But let’s not malign JSF here - it's not the fault of JSF.

Rather, we should blame CSS, which lacks the dynamicity that would allow the strong skinning features.


CSS Pre-Processors to the Rescue


That's exactly where technologies like LESS and SASS come in. They are processors which provide an  alternative syntax similar to CSS, that basically allow you to do magic with your style-sheets and how they are are structured - variables, mixins, functions, etc.

As the RichFaces team is currently working on leveraging Twitter Bootstrap, we want to embrace its beauties completely, and thus adopted its ability to style components in a simple and reusable way, while also enabling style extensions.

Now, you can see this magic in the RichFaces Bootstrap showcase.

What is this magic and how you can achieve it? Let's see in this demo:



Incredibly fast styling with JSF and LESS from Lukas Fryc on Vimeo.


You can clone the Bootstrap showcase on GitHub repository:

https://github.com/richfaces/sandbox

How does it work?

When the project is imported to the IDE, you can achieve instant turnaround without need to reload (or even re-deploy) anything - you just turn on the Instant LESS functionality using a bookmark with the following URL and the client-side LESS compiler will take care of the rest:

javascript:less.instant.toggle();


Your browser will now constantly watch for changes in the application resources.

We use JRebel to ensure resources are pushed to the server immediately after we save them in the IDE. This isn't necessary if you use an expanded WAR, but we load LESS resources from JAR projects and that's where servers usually fall short. Luckily JRebel comes to save our butt, making possible the hot-reloading of resources within a JAR that are served using the JSF Resource Handler.

Production Mode

The above method works well while in the Development stage of a project. But with that approach, LESS compiles resources in the browser and thus would slow down your application.

In Production project stage is where built-time compilation comes into play. We use the popular project wro4j - a pre-processor, minifier and optimizer for many alternative syntaxes for web languages.  Specifically we are using the wro4j-maven-plugin and M2E connector for this Maven plugin (written by our fellow Fred Bricon, who wrote a blog about usage of this plugin).

Let's check the Production Mode out, it is also as awesome as the Development Mode and its instant turnaround feature!

4 comments:

  1. In similar fashion, I was trying CoffeeScript, and wro4j proved to be very heavy (check out memory consumption with and without the plugin), and instead switched to coffee-maven-plugin.

    Have you tried any of the other maven LESS plugins? I've found this one but haven't tried it: https://github.com/achingbrain/less-maven-plugin

    ReplyDelete
    Replies
    1. The coffee-maven-plugin uses rhino (just like wro4j does), so it cannot be less heavy. Can you provide more details which proves your statement?

      The same is true for less-maven-plugin. The wro4j itself doesn't have memory consumption issues, rather it depends on performance of underlying dependencies (in this case rhino which is known to be relatively slow)

      Delete
  2. Hey Martin, I have not used any other plugin yet. We use Wro4j plugin just in build-time so I was not worried much about how it performs.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete