Now I’m working with ATG for a couple of months I want to share my thoughts on the platform so far. Let me first introduce ATG. ATG is an ecommerce platform. It promises to deliver out of the box functionality to create complex ecommerce websites. That’s all I want to say regarding the bullshit bingo. Today I’ll discus ATG as seen by a developer. There are many other perspectives to see if the software suits your needs.

In April this year I attended an ATG course containing three modules: “Foundations of ATG”, “Extending the ATG platform” and “ATG Personalization and scenario development”. As you can guess these are modules targeting a developer. There are lots of other courses for business users etc. Just as a reminder before working on ATG I used to be working on all kinds of JEE applications. Furthermore I developed some (test) projects in Ruby (on Rails) and used Google app engine to see the advantages of a cloud platform.

At first it was a shock to work with JSP files again. I was used to JSF / ZK and other component based GUI toolkits. JSP files seemed so old to me on certain moments. As a fact the whole platform feels a little bit out-dated. As an object-relational-mapper ATG basically uses a special kind of HashMap to represent the entities. If you are used to Hibernate/JPA or active record like technologies accessing entities properties with Strings feels not ideal. Maybe I just need to get used to it. The repositories are mapped to the actual database through XML.

ATG uses property files for dependency injection. Unlike Spring these are not in a XML format but just key-value pairs. This makes the property files much more compact. One disadvantage is that (just like Spring/hibernate etc.) it can result in a config hell. I’m not sure anymore if configuration over code is a good mantra. But I’ll save that discussion for my review of the pragprog book.

ATG uses Servlet beans (a.k.a. droplets) to couple the JSP files to the other Java Components. Servlet beans normal servlets but there is an ATG tag handler that lets you access them directly in your JSP.

Let me give an example of using a servlet bean:

<dsp:droplet name="dropletName">
    <dsp:param name="someInputParameter" value="${param}"/>
    <dsp:oparam name="someOutputname">
        <p> some ${someOutput}  </p>
    </dsp:oparam>
</dsp:droplet>

A java class handling this droplet extends some base class containing a service method and may look like:

...
public class SomeServletbean extends DynamoServlet {

private SomeComponentType someComponent;

public void service(DynamoHttpServletRequest pRequest
        , DynamoHttpServletResponse pResponse) throws
        IOException, ServletException {
  String input = pRequest.getParameter("someInputParameter")
  String output =  someComponent.process(input);
  pRequest.setParameter("someOutput", output);
  pRequest.serviceLocalParameter(someOutputname, pRequest, pResponse);
}

getter/setter someComponent
...
}

Furthermore we need a config file (named dropletName.properties) to map the servlet bean to a class. This config file is also used for dependency injection (someComponent).

$class=com.mycompany.SomeServletbean
$scope=global
someComponent=/path/to/configfile/of/component

ATG provides several out of the box servlet beans and components for commonly used operations.  For most (java) web developers this pattern is pretty familiar. One possible problem of these droplets is that some people may link up many of them. This results in pretty long JSP files with a lot of logic contained in them. But as Uncle Ben told us:

With great power comes great responsibility

So how do I feel about ATG? It is just another java development platform. It has its quirks and feels outdated sometimes, but any platform has its issues. ATG is just an implementation of ideas also used in JEE.

pro:
– Default functionality available

cons:
– Tends to lead to lots of logic in JSP files.
– Repositories are Hashmaps