Next up is a talk on Struts. This is being given by Peter Campbell of Java Enterprise Solutions. He's going to explain Struts from a "what is it" standpoint, which is of great interest to me. VisualWorks now has the Web Toolkit, which is equivalent to ASP/JSP/Servlets. Is Struts something of interest?

Struts is a control layer based on Servlets, EJB, Resource Bundles, XML, and Jakarta Commons. Struts is a variant of MVC for web apps. Uses Servlets and JSP. It's an app framework that you build web apps on top of. Struts is basically the Controller - it relies on other things for the Model and the View. More or less, it wraps the Request and Response objects, and handles communication between the back end (Model) and the Request/Response.

For the model, Struts can talk to EJB, JDBC, some O/R layers. For the view, it's typically JSP (Could be XML, etc). From the front (HTML) end, the struts interface appears as a tag. So the HTML guys will be able to work with it fairly easily. The heart of this appears to be the configuration file, which is an xml file specifying the association of page actions to domain model actions. It specifies allowable page transitions. It does not do transactions; that's presumed to all happen at the model layer. The actual controller is some subclass of ActionServlet, which specifies what we are going to do, and via the configuration file, delegates actual actions (Command Pattern) to the model. The biggest hurdle is trying to share the configuration file - the latest version of struts allows for sub-config files. Another possible limitation - one cannot chain actions in the config file - you specify an entry point.

The model is your application. In this world, it's generally a set of one or more Java Beans. This doesn't imply all EJB's (and in fact, this speaker is arning people off of that). Heh. There's an admission that when you do this, you don't want to allocate objects too quickly, because the JVM won't easily keep up.

I'll say this - the tags you put on the page to deal with data transfer from form to application look really nice. I'm sure this simplifies the front end construction of forms a lot for the HTML guys. Not that it's difficult to do that transition in Smalltalk; here's how I typically grab form data in a VW servlet:

model := BlogUser new.
model getInputFrom: request parameters.

getInputFrom: aDictionary

	aDictionary keysAndValuesDo: [[:key :value |
			self setAspectFor: key to: value].

setAspectFor: key to: value

	| selector |
	selector := (key, ':') asSymbol.
	(self respondsTo: selector) ifTrue: [[
		self perform: selector with: value first].

However, having a standard set of tags for the HTML guys is not to be underestimated. Using JSP 1.1 standard tag libraries and these mappings is likely to allow for very quick mock ups and front end implementations. The way this is set up, it looks like the web toolkit should be able to support struts, given the appropriate back end framework - since we already support JSP style tags and servlets. So what we would need is an equivalent to the ActionServlet and the associated library. The hard part looks to be in the creattion of the XML file - you get examples, and have to customize. Presumably, you use some xml editor to do that.

You create

• An ActionForm class to mediate between view and controller
• Action classes for each logical request
• ActionMapping (in XML) for each logical request that needs mapping

In the Action class, you implement an execute method. This is where things flare off from. Hmm. What would be fascinating would be a conversation between someone advocating a Struts type approach versus someone advocating a Seaside based approach. Anyway, Struts is pretty small - about 100 classes. I guess we should have a look at this approach.