Research and Destroy

Really… after all that architecture nonsense and fruitless “platform” development (like in “fill the svn with a crapload of thingies which are ignored and reimplemented anyway”), the old question: “Yeah! But is it ART???”. How could web application development possibly benefit froum our efforts?

Today, I came across my first new component that did, for a change, require no big deal of “platform” implementation. In the unyielding hope, that this at one far day might become the rule and not the exception, I’d like to shed some light on the details.

• I started with the query. That is a good way to start, one gets a good hold on what to expect and what to pay for. Since we are doing a rewrite of existing software, I held my breath and dove deep into the existing PHP. To find a previous implementation in the action code that pretty much resembled a query along with some decision code and a “routine” (Piece of code set apart with blank lines and actually sporting a comment) to determine bar width for some kind of bar diagram – fine.
• The query wasn’t too complicated, basically a PageableListQuery, for which a base implementation exists. In my concrete query, I put in interfaces for Cacheability and the data provider datasource where it should be executed.
• Once the query was there and I had determined the query parameters needed, I realized that the return type of that query actually missed in our Object model. Since our BOs do not have any Dependencies, I unscroupulously added a new class asking questions later.
• The class stayed small, the table actually looks full of data but in reality it only has a few colums plus it is sortable.
• Suppressing the urge to do something entirely different first, I introduced a pretty stark junit test case that asserts at least the query string that goes to our data provider and checks if it is possible to get a result at all. Of course, the result list had zero elements and some Exception hit the wall next to my head.
• There was a new BO Type, so I had to write a Mapping for it. Since I am the first and only person to request this BO type, my Mapping goes to the class annotation as default mapping, go me! And since it is an unspectacular list mapping, I even get to retain the GenericListMapping for the iteration part and only have to implement the single object part, which is nice because this is very unlikely to produce strange errors. Mappings could be far more generic and self-contained, but our data provider has a rather odd object design and it is better understandeable to have some repeated code than some cryptic extension code to a generic mapping where no one knows how it works.
• With the generic list mapping annotated to the query class and the item mapping to the BOM class, the platform knows enough to get me datah! One day soon I’ll make GenericListMapping default for all ListQueries, but that’s not so easy.
• Tried the test case again. Yay! One field was not mapped correctly, but the result graph was o.k. It is good to know that a query executes correctly without having to deploy the application to JBoss to find out.
• Added some meat to the test case, but it is not wise to make the data content tests too sharp, it is not our Job to ensure data quality of our data provider which more often than enough irritates our tests. A result list with more than one entry and the first entry object with some correctly mapped fields in all graph objects was enough.
• Started Struts action implementation. Since the table does not have any complicated decision code and no data rearrangement voodoo either, I didn’t have to add much to the class. There is a default implementation for actions that display a List of BOs called PageableListAction which I could extend, all I had to do is add the action parameters, a method that creates the query and passes the action parameters to it (if that does not come from the configuration) and a little method to calculate the bar width. Since this one does not produce an array of widths but only one result per BO, it shrank down to one line.
• When looking into the navigation.xml config I saw that The Ralph of God had already left His traces. Normally, I would have to add a menu point in the main Navigation and four tab navigation entries there, pwith the possibility to configure default parameters or query implementation.
• in the struts.xml, someone had done similar, but I still had to add result entries since the JSP (can’t blame them, the pages don’t exist yet, not everyone is adept at precognitive software engineering) since we do no magick in the struts config, I can forget about that file from now on. Actually, I do so from time to time, the PostIt at my monitor labeled “Remember that there is a struts.xml” surely helps.
• Speaking of JSPs, they were the worst part that time. Usually, there is a premade file from the HTML Ubergurus which dwell on the surface that I can cut and paste, put some <xx:iterator> and <xx:text> here and there and be done with it, but these were a little strained with other, more important stuff so we had to extract from the old system. Which is what I did, the templates of the old system are well separated from the “action” code (that is a good thing) and it looked easy enough.
• There are 2 JSPs now, one for the page and one for the component. It is the first and presumably only usage of that component, but concrete implementations of entire pages always attract later changes that fry the recyclability. The component jsp is called from the page JSP by <xx:action> and that’s it, since I do not require any additional parameters yet that I would otherwise put in here.
• Added standard component JSPs for taglib include, header and footer to the page and and tab navigation along with a page count/progression control to the component JSP, whatever crash should occur on that page, it will at least look nice from now on.
• There should be a test case for that one-line bar-width calc method, I know. I promise, there will be some time in the future.
• Smoke test. Bäm. Some THING emerged. From now on, bugfixing.