When I first developed AgileSites, I tried to address a common issue: the endless loop of fix-the-html-when-the-agency-updates it. I solved the problem but I was unaware of the scale such a problem can impact real-word projects.
In the ideal world in the mind of people who designed JSP, HTML designer are so smart to be able to directly edit the JSP when they design the HTML. Better: HTML designer should be so smart to figure out exactly which template they should edit (knowing the content model perfectly) and change it directly in the CMS, then publish it and the site is updates
In the real world, HTML designers have no clue how the CMS work, and no idea of the underlying content model. Better: they don't even want to know: their job is complete once they delivered the mockup of the HTML. It is the JSP coders job to implement it in the CMS
Also in the ideal world of Web Agencies, the HTML is done only once, and it is perfect. It completely satisfies the requirements, it works with all the browsers and the mobile devices in the world, so it can be handed over only once to JSP developers for implementation in the CMS.
In the real world, the HTML is a never finished work. It is first delivered incomplete, then it is updated more or less one thousand of times before it is complete. In the meanwhile the customer changes his mind on the average 2 times a day, and the HTML designers keep updating the HTML mockup.
In the middle, JSP developers go crazy cutting and pasting and diffing the changes made to the HTML, they struggle fixing the JSP to keep up with HTML changes, also because there is a lot of rendering logic embedded in the HTML.
Because I had a first-hand experience of this nightmare, I designed AgileSites in order to keep the HTML totally separated from the Java code, allowing for totally independent editing of Java and HTML.
The basic idea is pretty simple: you keep the HTML in its original form. You only ask HTML designers to clearly mark where the content should go using normal HTML conventions (usually ids and classes).
When the HTML is delivered, Java coders simply write Java code that will load the HTML in its original form, cut it in smaller pieces (and this cut work is done in code, not manually) then replace the HTML with the content taken from the HTML. That is all. This is what AgileSites allows you to do. This reason alone is enough to use it.
The great benefit is that now HTML editors can change the HTML at their hearth content. As long as they keep the ids they defined in the first place (and usually this is something they do because an id is a convenient placeholder for something they need to keep track of) the HTML can be completely restructured, the look can change completely.
All of this without impacting the Java code that is already written. Java code must be changed only when new content is needed, not when the look of old content changes.
When I first designed this system, I was unaware of the scale this method can impact the development process of a large site. In a large project, done with just Sites and JSP, the HTML was changing all the time. I would say that is normal
In that project, there were just 3 HTML developers, but for implementing that in the CMS 5 JSP coders were needed, busy all the time changing the JSP and writing tons of code to keep up with the pace of the HTML developers. The time to implement a change was one week at the minimum for simple changes, to became 2 to 3 weeks when the HTML changes were more complex.
I am now working in a much larger project, very rich in HTML and Javascript coding. Luckily for them, they adopted AgileSites. Numbers here are very different: there are at least 50 HTML/Javascript developer producing HTML changes at a very high rate. Applying the numbers I saw in the preceding project for keeping the JSP updated you would need maybe 70 JSP coders!
But thanks the AgileSites approach, only TWO Java developer (yes TWO) are required to do some occasional change, that is usually done in a matter of minutes!
