We will not go through explanation of what Droplets are; you can read ATG documentation for that, which is now available online for free after Oracle acquired ATG. We will just say that droplets can be great way to encapsulate most common things you need when rendering output. They can be viewed as custom tags in JSP. But as with JSP custom tags, no business logic or database manipulation should be put in them.
Unfortunately code which we received did not follow this convention. All functionalities you can imagine were put in the droplets. So as much as we wanted to drop them out from our code, we could not do that. There was no way to extract that logic to controller, it will add years to our release time.
So after spending many days deciding what the best way is, we concluded just to leave them. But this meant that we needed to mimic their behavior by implementing our own tag library that will replace the functionality of droplets. It sounded easy, effective with minimum effort on the developer side. But there is no such thing in software development. We learned a lot about JHTML and DSP while trying to port Droplets. The main thing you should remember, if you are crazy enough to go our way, is testing. Without it, don’t even try. We have used ServletUnit for unit tests and just to be sure, TagUnit for additional integration tests. We forgot to mention that as reference we used ATG DSP tag library output, it’s the same as JHTML tag library but only implemented for JSP.
It seems so simple, but it is very hard to implement it right. First you have to decide where to put all those parameters while collecting them. They have to be reachable from Droplet. That’s ok, just put them in our custom droplet tag and pass that droplet tag object to droplet service method. They also have to be reachable from within the JSP page. That means they need to be in the request, so that we can use JSP EL or JSTL to reach them. And that’s not all: parameters that are set inside droplet service method need to have same semantics. Also, all of them have to be scoped, meaning that they are reachable only inside droplet tag. So our decision was to wrap HttpServletRequest before passing it to Droplet and use it as container. ATG Dynamo has DynamoHttpServletRequest that is much more than HttpServletRequest we have, so we had to implement all those methods from DynamoHttpServletRequest. That were some of the problems we had. It’s just part of it, but in the end this decision to mimic droplets was right because our releases were on schedule.
If we don’t drop out Droplets, then why drop anything else?
After the decision to leave droplets as they are, somehow it looks valid to leave all other tags from JHTML (or DSP) tag library. Imagine the benefits, all the pages (thousands of them) would have to be only slightly changed. Even better, this process of migration can be automated. So another decision was made, we have to implement all those <setvalue/>, <valueof/> and other tags from DSP tag library. And this was much easier then droplet migration. Of course unit tests were there to help us on this journey. We made a converter that will, with the power of RegEx, convert tags from DSP to our own JSP tags. For JHTML pages we used JHTML converter shipped with ATG that converted JHTML to DSP. This was all automated, so months of developer work were cut off. With our process of Form Handler porting, it seemed like there will be no manual work at all. But one thing we could not automate, DSP forms porting. This was because DSP forms could not be so easily ported to Spring forms. So this was left for developers to do by themselves.