February 12, 2004

wrapping your head around it

I've almost got my head wrapped all the way around struts. And it hasn't been as painful as it sounds :-)

I've been implementing a webapp in struts for forrestbot (getting paid to work on open source!) and it hasn't always been too straightforward. Learning the big picture of a library or paradigm or pattern can be tough. Everywhere you look there are API references and snippets of code to do specific things, but there's nothing like that for organizing an entire application. Even looking at existing applications doesn't work because few apps are "normal"; they frequently have some oddity which requires a variation from a standard design pattern. And other sample apps (often used in "getting started" articles) are too simplistic. They don't show how you start organizing your files when you have multiple forms and actions, for example.

One way to learn this would be to have a concise but complete overview of the "black box" you are trying to learn. For example we'll continue using struts. It's a library that provides lots of neat stuff beyond the servlet container's capabilites. We'll assume we know how servlet containers work (I don't completely yet, but enough). We have struts-config.xml, tlds, tiles definitions, jsp layouts, resources, classes (actions, forms, models) and jsps using jstl & struts tags. That's a lot. Especially looking at the struts-config it can be confusing to understand what names and references correspond to what other things. There's lots of "connections" that go on behind the scenes (meanging: in the struts library) that are unseen and thus not understood. The overview would literally give you all the different type of inputs and tell you the outputs (how the app works). A simple example (I can't remember the specifics for the rest, like tiles or resources) would be saying that struts-config.xml is specified as the config file in web.xml which is read by the servlet. This is how struts knows how this app is configured. Or another: In struts-config, group several elements that specify what form classes you have. Here you specify various things, like if it is a dynaform or not, and what form fields it will handle. You must specify the form fields or they will not be accessable in your java action and form classes. They're also used for validation (I think).

This is a big form of documentation lacking in current software, libraries, languages, etc.

Posted by Dave at February 12, 2004 02:54 PM | TrackBack
Comments