After one day of playing with Struts these are my key takeaways:

– Struts is an MVC framework which attempts to separate the view (the HTML page), the control code (“Actions”), and the model or database code. This means it’s rather heavyweight if you’re building a three-page site that presents a calendar–but if you’re writing a complex site, then this separation of responsibility makes things much easier to track what is going on. Of course like all design models, it only helps if you keep things clear–all any design model can do is provide you tools to keep things clean. But like a vaccuum cleaner, it only works if you use the tool religiously and use the tool correctly.

– Setting up Struts2 is fairly simple: once you’ve created a Tomcat project within Eclipse (in my setup, I downloaded Tomcat 5.0.28 into the Eclipse project, then used the Sysdeo Eclipse Tomcat Plugin to get Eclipse to play well with Tomcat), it’s a matter of copying the xwork, ognl, freemarker, commons-logging and struts2-core jar files from the Struts2 distribution into the WEB-INF/lib folder, and telling Eclipse about the jar files located there.

Then create the web.xml file in WEB-INF, creating the struts.xml file in WEB-INF/src (where Eclipse will then automatically copy it into WEB-INF/classes where it belongs), and you should be set.

Of course if you screw something up–such as accidently copying the struts-core rather than the struts2-core jar file–then you will get the dreaded “FilterStart Error” without any explanation. Things to look for: did you mistype the name of the filter-class in the web.xml file? Did you copy the wrong jar file like I did? If you see a lot of struts startup stuff but then it fails–did you mistype the class name or package name for your action in struts.xml?

– Struts uses these things called “Actions”, derived from com.opensymphony.xwork2.ActionSupport, which implements the “execute()” method, which essentially is what happens when your web site processes a form. Actions take you from one place to another. How actions are wired up is defined in struts.xml, and what page we move to after executing an action is defined in struts.xml. Results can route to a .jsp file which uses struts tags to simplify getting state information for presentation from an action or from the current state.

– State between actions is maintained in a Map, which can be obtained through ActionContext.getContext().getSession()–the context is thread safe (it uses thread-local storage for the context), though I suspect the session Map is not, since multiple pages may share the same session.

Once you know how to build pages (Dreamweaver, Struts tags), how to build actions (and ActionSupport seems like a good place to start), and store context, then you should be able to get off the ground.

Now, of course, like any API, about three to four months from now I will read back at this post and say “ohmygod, how naive was I?” But you gotta start somewhere. And this looks to me like as good a place as any to start.