--- title: Technology Synergy url: https://www.grahambrooks.com/post/2010-10-20-technology-synergy/ date: 2010-10-20T00:00:00+00:00 author: Graham Brooks tags: - Agile --- # Technology Synergy I started writing this post quite some time ago but never got around to wrapping up the loose ends. The article is really a summary of what I learnt during a pretty intense media web site development project. Since pictures equate to 1000s of words here is my effort to express how technologies can work symbiotically to delivery value that is more than the sum of their parts. ![Technology Synergy]({{ site.url }}/images/technology-synergy.jpg) But since systems are built from parts: here are the parts that we used. [Extended SiteMesh](http://www.opensymphony.com/sitemesh/) SiteMesh is a pretty amazing technology for creating web sites mashups – or combining HTML documents on the server. We found that by partitioning the content and the parts of the server that delivered that content before combining the individual HTML documents together using SiteMesh to be extremely effective. The server code for each HTML document need only handle the a well defined area but the site could be easily reconfigured to aggregate the content for new purposes. ## In memory tests Think super fast builds, no deployment (in fact no need for a web server), pure Java acceptance tests (i.e. refactorable) and the 80/20 rule on what is good enough to give you confidence that the system works. [Post/Redirect/Get pattern](http://en.wikipedia.org/wiki/Post/Redirect/Get) We built into the application framework that enforced the PRG pattern. POST request handlers could only return a redirect. Any database access performed during a GET request worked with a read only connection or a connection with an transaction rollback making GET requests idempotent. ## Simple transaction boundaries Transaction boundaries have been enforced so that developers do not need to worry about them at all in production code. GET requests run in a transaction that will always be rolled back, POST requests will always commit if successful and always roll back if an exception is thrown. Some serious work went into taming Hibernate so that it did not auto commit, had no mutable static state and was completely encapsulated. [AHAH (Asynchronous HTML and HTTP)](http://microformats.org/wiki/rest/ahah) This enables much simpler JavaScript to be written (think JavaScript that never needs to replicate the domain model or business rules on the client) and allows for complete reuse of server side logic. This combined with behaviour CSS bindings ( http://www.bennolan.com/behaviour/ ) leads to NO in-line JavaScript nastiness and more semantic html. ## No Session State just persistent documents The application servers had NO session state, all state changes to documents are persisted which leads to a number of advantages: Users never loose data they have filled in, marketing can see exactly how far a user got before bailing out of a work flow. Users can return to incomplete work and complete the tasks. Users can fill in data in any order they want and only when they are ready do we action their request. Domain objects are only updated once the document has been validated. [Progressive Enhancement and Accessibility](http://en.wikipedia.org/wiki/Progressive_Enhancement) All stories are played vanilla html version first and a second story for JavaScript enhancements. This leads to cleaner simpler semantic html and also allows feedback from the first story to be tacked onto the second story. [NO Logic in the View](http://www.stringtemplate.org/) We are using StringTemplate to enforce that NO logic can be written in the view, plus it's super fast, has no "or loops" (think ruby each blocks). On my current project we are using a number of complementary technologies and techniques. The overall effect is (IMHO) greater than the sum benefits of each design component and I thought I would try and capture this idea in a diagram. ![Technology Synergy]({{ site.url }}/images/technology-synergy.jpg) ## RESTful Unique URLs for each resource is a simple technique but is a liberating experience. Combine this with persistent documents that maintain workflow state and Post/Redirect/Get and you have a pattern that handles situations very cleanly, making many design decisions for you. ## [Post/Redirect/Get pattern](http://en.wikipedia.org/wiki/Post/Redirect/Get) We have built a simple interface contract that enforces that all POSTs return a redirect so that the Back button will always work. This combined with the transaction boundaries ensures that all GET requests are idempotent. ## Simple transaction boundaries ## [Extended SiteMesh](http://www.opensymphony.com/sitemesh/) ## [AHAH (Asynchronous HTML and HTTP)](http://microformats.org/wiki/rest/ahah) This enables much simpler JavaScript to be written (think JavaScript that never needs to replicate the domain model or business rules on the client) and allows for complete reuse of server side logic. This combined with behaviour CSS bindings () leads to NO in-line JavaScript nastiness and more semantic html. ## No Session State just persistent documents We have NO session state maintained within the application. All application state is maintained in the database. Partially completed workflow steps are persisted to the database as documents representing the partially complete workflow. On completion these documents are validated and converted into domain objects. ## In memory tests Think super fast builds, no deployment (in fact no need for a web server), pure Java acceptance tests (i.e. refactorable) and the 80/20 rule on what is good enough to give you confidence that the system works. ## [Progressive Enhancement and Accessibility](http://en.wikipedia.org/wiki/Progressive_Enhancement) All stories are played vanilla html version first and a second story for JavaScript enhancements. This leads to cleaner simpler semantic html and also allows feedback from the first story to be tacked onto the second story. ## [NO Logic in the View](http://www.stringtemplate.org/) We are using StringTemplate to enforce that NO logic can be written in the view, plus it’s super fast, has no “for loops” (think ruby each blocks).