People who know me also know I’ve interest in the GUI: that means I’ve sometimes to get my hands dirty and dig deep into stylesheets (even though I’ve no graphical skill whatsoever). When it happens, I’ve always questions regarding how to best factorize styles. In this regard, the different CSS versions are lacking, because they were not meant to be managed by engineers. A recent trend is to generate CSS from a source, which brings some interesting properties such as nesting, variables, mixins, inheritance and others. Two examples of this trend are LESS and SASS.
A not-so-quick example can be found just below.
Given that I’m an engineer, the only requirement I have regarding those technologies is that I can generate the final CSS during my build in an automated and reproductible way. After a quick search, I became convinced to use wro4j. Here are the reasons why, in a simple use-case.
Maven plugin
Wro4j includes a Maven plugin. In order to call it in the build, just add it to your POM:
<plugin>
<groupId>ro.isdc.wro4j</groupId>
<artifactId>wro4j-maven-plugin</artifactId>
<version>1.4.6</version>
<executions>
<execution>
<goals>
<goal>run</goal>
</goals>
<phase>generate-resources</phase>
</execution>
</executions>
</plugin>
You’re allergic to Maven? No problem, a command-line tool is also provided, free of charge.
Build time generation
For evident performance reasons, I favor build time generation instead of runtime. But if you prefer the latter, there’s a JavaEE filter ready just for that.
Configurability
Since wro4j original strategy is runtime generation, default configuration files are meant to be inside the archive. However, this can easily tweaked by setting some tags in the POM:
<configuration>
<wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory>
<wroFile>${basedir}/src/main/config/wro.xml</wroFile>
<extraConfigFile>${basedir}/src/main/config/wro.properties</extraConfigFile>
</configuration>
The final blow
The real reason to praise wro4j is that LESS generation is only a small part of its features: for wro4j, it’s only a processor among others. You’ve only to look at the long list of processors (pre- and post-) available to want to use them ASAP. For example, wro4j also wraps a JAWR processor (a bundling and minifying product I’ve blogged about some time ago).
Once you get there, however, a whole new universe opens before your eyes, since you get processors for:
- Decreasing JavaScript files size by minifying them with Google, YUI, JAWR, etc.
- Decreasing CSS files size by minifying them
- Minimizing the number of requests by merging your JavaSscript files into a single file
- Minimizing the number of requests by merging your CSS files into a single file
- Processing LESS CSS
- Processing SASS CSS
- Analyzing your JavaScript with LINT
The list is virtually endless, you should really have a look. Besides, you can bridge your favorite by writing your own processor if the need be.
Quick how-to
In order to set up wro4j real quick, here are some ready to use snippets:
- The Maven POM, as seen above
<plugin> <groupId>ro.isdc.wro4j</groupId> <artifactId>wro4j-maven-plugin</artifactId> <version>1.4.6</version> <configuration> <wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory> <wroFile>${basedir}/src/main/config/wro.xml</wroFile> <extraConfigFile>${basedir}/src/main/config/wro.properties</extraConfigFile> <targetGroups>all</targetGroups> <cssDestinationFolder>${project.build.directory}/${project.build.finalName}/style/</cssDestinationFolder> <jsDestinationFolder>${project.build.directory}/${project.build.finalName}/script/</jsDestinationFolder> <contextFolder>${basedir}/src/main/webapp/</contextFolder> <ignoreMissingResources>false</ignoreMissingResources> </configuration> <executions> <execution> <goals> <goal>run</goal> </goals> <phase>generate-resources</phase> </execution> </executions> </plugin>
Note the use of the
ConfigurableWroManagerFactory
. It makes adding and removing processors a breeze by updating the following file. - The
wro.properties
processors file, that list processings that should be executed on the source files. Here, we generate CSS from LESS, resolve imports to have a single file and minify both CSS (with JAWR) and JavaScript:preProcessors=lessCss,cssImport postProcessors=cssMinJawr,jsMin
- The
wro.xml
configuration file, to tell wro4j how to merge CSS and JS files. In our case,styles.css
will be merged intoall.css
andglobal.js
intoall.js
.<?xml version="1.0" encoding="UTF-8"?> <groups xmlns="http://www.isdc.ro/wro"> <group name="all"> <css>/style/styles.css</css> <js>/script/global.js</js> </group> </groups>
- Finally, a LESS example can be found just below.
Conclusion
There are some paths to optimization for webapps readily available. Some provide alternative ways to define your CSS, some minify your CSS, some your JS, other merge those files together, etc. It would be a shame to ignore them because they can be a real asset in heavy-load scenarii. wro4j provides an easy way to wrap all those operations into a reproductible build.
LESS |
---|
|
Generated CSS |
|