All I found were WordPress plugins which are not allowed if you are a user of WordPress.com.

Fortunately, I found this page: Posting Source Code

Such a relief! All your need to do is to:

• wrap your code with a wordpress element “sourcecode”
• provide some options such as the language (supports most popular programming languages: XML. HTML, JavaScript, C#, Ruby, Python, Java and many more!) and some formatting option

Thank you again WordPress!

Sitemesh

Sitemesh is a layout engine that will help developers to implement a consistent look and feel for their web applications. It will also facilitate the maintenance of the layout code. There are other frameworks that serve the same purpose and take a different approach. Among them, the most popular would be Tiles framework. Tiles framework follows the composite pattern: in a very simplified explanation, each page will specifies which UI components (the top navigation, a left column or the footer) it needs in addition to the content of the page. Sitemesh has a different approach and uses the decorator pattern. Each page is only concerned about what is specific to it. Before the page is sent back to the client, the framework applies a decorator that contains the UI components (top nav, left nav … ) common to your pages. There are pros and cons of using either framework. What made me decide for Sitemesh is that if you need to change your layout, you’ll only have to make the change in your decorator while if you use Tiles, you’ll have to touch every pages. Also, something else that I like about Sitemesh is that you can have several decorators for the same application, meaning, you can apply a decorator for printing pages, or have 2 decorators, one implementing a newer layout and one keeping the current layout so users can choose which layout/style they like better.

Installing Sitemesh

• dependency: Add the framework’s jar in your lib folder or via your pom.xml if you are using maven.
• Create a decorator folder and drop there your decorator.xml
• Update your web.xml file as follow:

1. Right before the Struts2Dispatch filter, drop the following:

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter>
    <filter-name>struts-cleanup</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ActionContextCleanUp</filter-class>
</filter>
<filter>
    <filter-name>sitemesh</filter-name>
    <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
</filter>
<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter>
    <filter-name>struts-cleanup</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ActionContextCleanUp</filter-class>
</filter>
<filter>
    <filter-name>sitemesh</filter-name>
    <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class>
</filter>

Then, in your servlet section, drop the following:

<servlet>
    <servlet-name>sitemesh-velocity</servlet-name>
    <servlet-class>com.opensymphony.module.sitemesh.velocity.VelocityDecoratorServlet</servlet-class>
    <init-param>
        <param-name>org.apache.velocity.toolbox</param-name>
        <param-value>/WEB-INF/toolbox.xml</param-value>
    </init-param>
    <init-param>
        <param-name>org.apache.velocity.properties</param-name>
        <param-value>/WEB-INF/config/base/velocitybase.properties</param-value>
    </init-param>
</servlet>

There are a few things to understand from this configuration:

1. The order of the filter matters.Sitemesh processing happen on top of Struts’s FileDispatcher. This implies you won’t have access to Struts objects in your decorators and files parsed in the decorators.
2. In the servlet section, if you are using Velocity, you need to specify 2 things: where your toolbox.xml is and where your velocity macros are. You use for that the <init-param> element

Pitfalls

• Sitemesh is layout engine, so use it for what it is for. Let’s say you created a decorator and need to access an object exposed by your controller, well, you don’t have access to this object anymore since Sitemesh processing is happening after Struts2′s in the response. You can extend the Sitemesh filter and put your objects in the context but I found that it’s best to stay away from deep changes and keep your design as simple as possible. Simple is good, it makes it easy to maintain code and often, engineers tend to over engineer a solution.
• AJAX responses will get decorated so exclude the AJAX URLs in the decorators.xml file using the exclude element.
• the Sitemesh version you need depends on the version of Struts2 you are using

I recently blogged about a JavaScript testing framework called JsTestDriver. But it would be useless if I cannot write JavaScript code that is unit testable to leverage my testing framework. A benefit of writing unit testable code is that it will also help you to write maintainable code.

Before going any further, I would like to briefly set a common ground on those 2 notions.

Unit testing

There are several kind of testing that can be performed to ensure a product’s quality:

• Unit testing: test the smallest unit of your code. The goal is to ensure that all methods of your objects works correctly, independently from other objects. There are many unit test framework available such as QUnit, JsTestDriver that I highly recommand.
• Integration testing: test the interaction/integration between your objects. Selenium is a popular integration testing tool.
• Functional testing: test your use cases which could be a serie of steps executed by the user.

Writing unit testing will:

• allow you to verify if a code change breaks or not you code.
• improve the quality of your code. A good practice is to write your code first. It can be strange at first but it will force you to break your implementation into small, independent chunks of code that serve 1 goal. Because your code is broken down, it is easier to see duplicate code, clearer to understand the purpose of each method.
• because you broke down your code in small pieces, the method should be as simple as it gets and therefore be self documenting

As you can see, I did not say that your application will be bug free. Why not? First of all, software specifications can be incomplete or incorrect. You could be missing certain use cases. Secondly, unit testing ensures that your objects work correctly but outside of the application context, independently from other objects. For more on unit testing in JavaScript, please refer to Nicholas C. Zakas’s video on test driven development.

As a note, it is important when writing unit tests to keep in mind the goals to be achieved, i.e writing tests against unit of your code. Writing bad unit tests can be costly to maintain because you’ll end writing and maintaining unit tests with low value. See the very interesting post Writing Unit Test: Best and Worse Practices for more information on that topic.

Maintainable code

What is maintainable code? Maintainable code is code that is:

• Understandable
• Intuitive
• Adaptable
• Extendable
• Debuggable/Testable

If you would like to learn more information on writing maintainable JavaScript code, please refer to this excellent video from Nicholas Zakas – Maintainable JavaScript.

In his video, N. Zakas lists several elements that will help you to write maintainable code such as code convention, separation of concerns, coding practices … In today’s post, I just want to briefly talk about writing testable code.

Let’s get started

For the context, we will imagine we want to implement a calculator with 2 input fields and 2 buttons to perform basic operations (+ and -) and a label to display the result. How would you write testable JavaScript code for such as feature? It can seem strange since it is bound to the UI. In other programming languages such as Java, C#, PHP, Ruby … you are dealing with objects and testing their methods. Well, let’s do the same!

There are many ways to achieve today’s goal but they all converge towards the same idea. You first need to visualize this feature as a module. This module has a state (values of the inputs), operations and event handlers bound to the buttons.

I am going to write the code first and explain afterwards:

var calculator = {
	value_1:0,
	value_2:0,
	config: {
		labelSelector:"#resultLabel"
	},
	/* Add event handlers to the buttons */
	init:function(){
		$("#add_button").bind("click", function(){
			this.value_1 = $("#input1").val();
			this.value_2 = $("#input2").val();
			this.add();
		});
		$("#substract_button").bind("click", function(){
			this.value_1 = $("#input1").val();
			this.value_2 = $("#input2").val();
			this.substract();
		});
	},

	/* Some comments for the add function */
	add:function(){
		var result = this.value_1 + this.value_2;
		this.displayResult(result);
	},

	/* Some comments for the substract function */
	substract(){
		var result = this.value_1 - this.value_2;
		this.displayResult(result);
	},

	/* Some comments for the display function */
	displayResult:function(value){
		$(this.config.labelSelector).text(value);
	}
};

Explanations

1. I created an object (in this case, an object literal) that encapsulates my properties and my methods.
2. When the DOM is ready, we will initialize the object as follow: calcultator.init();. The init() method attaches the event handlers to the buttons. It is a nice approach because by reading the init() method, I know what the module is going to do without having to look at the implementation details.
3. We implement the functions called in the event handlers. This is a good approach because we do not mix event handlers and business logic. Say we want to change the event on which we perform an ‘add’, we just need to change the trigger event but we can leave the add method untouched.
4. Even if this is a simple example, I kept in mind the idea of keeping the method to serve 1 testable purpose. When writing unit tests, I can easily call my add method and test it against an expected value.
5. I created a displayResult that is being called in both my add and substract mehotds so I can test it and I do not repeat the display logic in the add nor the substract method.

Thoughts

Did we write maintainable code?

• Understandable: the logic is separated in small units of code making it easy understand and we commented each functions.
• Intuitive: the init method explains quickly what the module does
• Adaptable: if needed, we can easily change the triggering events of the add or the substract method actions
• Extendable: if is easy to add a new feature such as multiply or divide by adding a new event handler and a new function
• Debuggable/Testable: code is splitted in unit testable code

Of course, it is a very simplistic example and I do not drill down into details. For example, to improve the code above, you will still have to write:

1. exception handling
2. comment (unintuitive) code
3. write your unit tests

The list of possible improvement is far beyond the scope of this post. What I wanted to share is the pattern to use when writing modular JavaScript:

• encapsulating you module’s behavior in a object
• using an init() method
• separating event handling from business logic
• I am obviously using jQuery library. My recommendation is to avoid as much as possible to refer to CSS selectors in your functions. You can put them in a config object property like I did for the label selector. It is up to you. The advantage is that is you decide to change your markup, your changes in your JS code will be minimal.

Last but not least, run your tests on all browsers. Even if you use a library that is cross browser libraries such as jQuery to implement events … there are still differences in the behavior of browsers when it comes to run JS code (and differences of performance as well!).

I hope you enjoyed this post and that it gave you some ideas on how to write testable and maintainable code!

Thanks for reading.

I am currently reworking the JavaScript layer of an application at work. Among several initiatives to improve the maintainability of the app, I suggested to adopt JavaScript unit testing. There are several JavaScript unit testing framework out there. The one that I used before was QUnit, a simple unit test framework developed by the jQuery team and I intended to use it again.

The final goal was to have our tests ran within our continuous integration process, meaning the JS tests would run when a build was scheduled.

My initial approach was to write:

1. QUnit tests and called the script from a single file.
2. Generate an automated test with Selenium to read the result section of the QUnit result page
3. Depending on what was read, fail or pass the test like any other JUnit tests.

Simple enough until a coworker briefly mentioned to me JsTestDriver.

What is JsTestDriver?

JsTestDriver is a JavaScript testing framework supported by Google. It is more complete than a JavaScript Unit Testing library and can provide you with the following benefits:

• provides JavaScript Testing API similar to JUnit. You can also write tests against the DOM very easily.
• can be run via the command line: this means it can be integrated to your Continuous Integration process.
• can output test results in the same XML format as JUnit results tests: this will allow you to produce reports on the last build and run of tests suites.
• can provide code coverage.
• has an eclipse plug-in to run the tests. The plugin is very enjoyable to use because you can run your tests against any browser you specify without leaving leaving Eclipse. With QUnit, you would have to open each browser and refresh the page every time you make a code change for each browser you test against.
• last but not least, it exists adapters for other JS testing framework so that you can run your tests using JsTestDriver even if you used another testing library such as QUnit.

As you can see, JsTestDriver and its plugins offer a much more complete set of tools to write and automate JS testing.

I was somewhat reluctant at switching from QUnit (which I thought was good enough) to JsTestDriver. However I realized QUnit was only a part (but essential nonetheless) of the whole JS testing process.

Where to I get started?

I will not write today a tutorial on using JsTestDriver, maybe later. I will just point out the resources to get a better feel for it.

1. A presentation video: http://www.youtube.com/watch?v=aDKGGZv-T4M

2. The google code website: http://code.google.com/p/js-test-driver/

To break down the jsTestDriver site and I am linking each of the above points (in the what is JsTestDriver section) to its corresponding page for more info.

• JavaScript Testing API (API and how to write a test) – To add HTML to your tests
• How to run from the command line and the list of options
• Using the proper options will allow you to output an XML that can be used for build reports (see what has failed and where)
• How to obtain test coverage
• Eclipse plugin
• QUnit adapter

There are a few other topics such as how to debug (which is the same as you would debug a JS script with Firebug) and the config file (very simple).

I hope this gave you an idea of JsTestDriver. Hopefully I will post an example soon.

• as a block
• inline
• not being displayed

Note: for the list of block and inline elements, refer to my short post here.

Block Elements Behavior

Block elements (for example: div, p, table, address) will span over the whole width that is available to them and the next element will display in the following line.

Inline Elements Behavior

Inline elements will just take the space they need for their content. Example of inline elements are span, a, cite, em, strong.

So what now?

Well, first of all, if you know whether your element is a block or an inline elements, you know how wide it is going to be.

Second, you should control the width of block elements, not inline elements.

Third, you can alter the behavior via CSS displaying block elements as inline (display: inline-block) or vice versa, display inline elements as block (display: block).

Note: watch out for browser support.

Writting semantic HTML is definitively a Web Development best practice. Writting semantic HTML means using meaningful HTML elements in order to better describe and organize the content of the page.

This practice has several major benefits:

1. Improve the Search Engine Optimization of your pages: By using meaningful HTML elements, web crawlers better understand your pages’ content and therefore, index it appropriately according to your site’s subject.
2. Accessibility: Your content will be accessed mainly via a web browser but chances are that it will also be accessed via other devices like mobile devices.
3. Maintenance of the pages: Using semantic markup makes the code easier to read for machines (crawlers) and humans. Web Developers will better understand a page using meaningful HTML elements (if they know those elements) and will avoid to use unnecessary, meaningless div elements making the page harder to style (CSS) or interact with JavaScript.

Document structure elements

html, head, body

Document Head Elements

link, meta, object, script, style and title

Document Body Elements

Block Elements (text): p, h1, h2, h3, h4, h5, h6
Block Elements (list): dl, dt, dd, ol, ul, li
Block Elements (other): address, blockquote, del, div, hr, ins, pre, noscript, script

Inline Elements
Note: Inline elements must be nested in a block element
a, abbr, acronym, dfn, em, strong, code, sample, span, br, cite, del, ins, q, sub

Form Elements: form, button, input, label, legend, fieldset, option, optgroup. textarea, select

Tables: table, thead, tbody, tfoot, tr, th, td, colgroup, col, caption

I think a web developer should know at least 90% of those tags, their meaning and how to use them.

Reference: http://en.wikipedia.org/wiki/HTML || http://en.wikipedia.org/wiki/HTML#Semantic_HTML