A frequent question people ask on AgileSites is: why you did it?
Well, it was not really a matter of choice. It was a matter of necessity. If you want to know, I will tell the story.
Once upon a time, it was something between 2007 and 2009, we were contracted to implement a web site using Fatwire (the precursor of WebCenter Sites), then hand it over to the customer for maintenance.
The customer provided the HTML mockup,we had just to code the jsp based on that mockup.
So we did our work, using just plain JSP as it was the standard at the time, and we built the content model, mostly working in a JSK that then we published in customer Development server.
Once finished, it was supposed to be all.
I was wrong. After the delivery to the customer, they first started to change the code, then they kept calling us back for a long list of different tasks to help them to add a lot of other features they decided to implement.
The problem is that our suppor work doing those changes became an unbelievable pain because of the limitations of the enviroment.
The first annoynace came from the HTML. The original mockup was changed. Actually the customer changed the mockup multiple times then he gave it back to us for implementing it back in the JSP.
So the first problem was: were the change happened? Once you have implemented the JSP, the mockup has been split in many difference pieces and lot of code has been added.
So we had to use a version control system, diffing the html, the patiently trying to locate the JSP where the change happened. Very often the html was changed structurally so the changes were spread in many different templates and we ended up, multiple times to have to rewrite many templates. The logic and the html were mixed up and that is totally wrong.
After this experience I understood that HTML must stay HTML in the original form, and Java must stay Java with no markup. Mixing html and code is the biggest mistake in the history of internet development and it is acceptable only in those rare cases (today almost disappeared) when the HTML and the Java coders are the same person.
Part of the work was to support the development done by other people. I cannot believe to what I saw. Even if our code was done properly, with all the correct tags used according best practices, maintainer did not even care to understand.
They did a quick look to the tags, and they found one tag they undesrtood: ics:sql. After this, all they did it to throw SQL queries everywhere, using then a lot of embeded java code to render queries.
When I asked why they did it, they simply said they did not understand the complicated API so they had no choice. Actually I have to admit that ics:setasset or assetset:getaatributevalues are definitely complex, but I never realized they are a real stopper for some people.
There are people simply they cannot use a system where there are many conventions and calls with multiple parameters. So I realized what they really needed an api very simple and immediate.
Something like:
Asset a = e.getAsset();
a.getString(“Title”)
So I started to wonder how to make a library simple as this.
JSP are supposed to be a sort of “extended html”, and you are supposed to perform your tasks using mostly only the tags. In practice, you always need to write complicated logic, and using tags for this is simply not an option. So you end up opening a scriptlet… and your entire JSP became a large snippet of embedded Java code.
Except, you soon realize that the embedded Java within a JSP is NOT full Java. You cannot create a class and share it. So you cannot even have a method used in 2 different templates, you need to duplicate the code. The biggest advantage of Java (code reuse) is simply not available.
Indeed this is what many Sites implementations are: a giant copy and paste of the same code repeated with modifications spread everywhere. A real maintenance nightmare.
Take a team of untrained developers, working without a good knowledge of the system, using a shared enviroment, working with copy and paste programming, and having to apply a mockup that is changing all the time. What you get? Answer: a giant number of issues. What is worse at every change you can break something so you may end up having to retest the entire site.
The customer kept asking me again and again: is it possible to automate tests? I wished all the time I could have answered something better than “yeah, you can use selenium”….
The customer kept changing the content model. Basically with no planning: every time they needed someting they added an attribute somewhere, with a lot of duplication of content too. Then they hacked the code to use it.
Since we were forbidden to use their development server, we kept wasting time exporting their model in a copy (a Jump Start) were we could do the development. The process was more time expensive than doing everything else. I think we spent 2/3 of the time moving content model back and forth. The problem was also that the customer refused to acknowledge that time as “coding time” so the process made us to actually lose money.
Here I realized in no way you have to do this. A reference enviroment where people changes things and then copy back is basically conceptually wrong. You need a development enviroment in local machines for every developer, then use some build script for deployment.
But never apply change in a shared enviroment. Sooner or later that enviroment will became unaccessible leaving you in the dust.
It is actually a bit more that just moving the content model. The entire system is comprised of many different pieces: extension code, imported elements, xml configuration files and so on. Putting all of this manually is really like having to compose a puzzle every day.
We also had a lot of deployment problems because the many different pieces. Assembling the whole reading a document is awkward and really dangerous. You need a build script and a setup script. You need some code that will take care of automatically deploying all the pieces. Without it, you will end up forgetting pieces and then spending hours to figure out what is missing.
After this nightmare, I was determined to create something we can use for ourselves to save our life from all the problems that plain Fatwire (and Sites) poses. So I created something that:
1. really separates HTML from Java
2. allows to use full Java, without any limitation
3. it has a simple api for starters and common tasks
4. it has an installer for automated build
5. it has support for automated tests
AgileSites was born! How it was applied to real world project is another story, I will tell in another post.
