I successfully created my first prayer list using Google DataStore (AppEngine).

Now it’s time to dig deep into GWT to understand how best to wire related parts of the view together with each other, the controller, and the model…

It was a dark hour, but we soon found a new shining software implementation to help us. Spring-Webflow rose to the occasion! It was so simple, in fact, that, despite Mr. Chandler being out-of-touch on the Northside for most of today, I still made significant progress in understanding and implementing this new framework. Do not misunderstand, I still didn’t actually get it running, but at the close of the day I believed I was close.

Spring says “flow” instead of “dialog”, and has an even shorter list of simple states. The nifty thing about Webflow (aside from the fact that it works in our app) is its close connection with other Spring features, such as Spring-Faces!

On Friday we encountered some difficulty making sure we had the up-to-date Spring webflow jar file. Our current version, downloaded from the central maven repository, was 1.0.4. Spring Webflow is currently cutting edge at 2.0.2. We eventually located the correct maven repository for milestone releases, and added the dependency to our pom as follows:

<repository>
<id>spring-milestone</id>
<name>Spring Milestone Repository</name>
<url>http://maven.springframework.org/milestone</url>
</repository>

We then added the dependencies recommended by Spring:

<dependency>
<groupId>org.springframework.webflow</groupId>
<artifactId>org.springframework.binding</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>

<dependency>
<groupId>org.springframework.webflow</groupId>
<artifactId>org.springframework.js</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>

<dependency>
<groupId>org.springframework.webflow</groupId>
<artifactId>org.springframework.webflow</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>

<dependency>
<groupId>org.springframework.webflow</groupId>
<artifactId>org.springframework.faces</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>

Strangely enough, the downloaded jar files, when viewed in Eclipse under the lib folder, were under the path name org.springframework. as opposed to the other Spring jars which came in under the path name spring.

Once we got the framework running around midday, we began trying to implement our pages as a simple flow/subflow pattern. It took us to another 10:30 pm quitting time. At least this time it seemed to do what we wanted it to. With a lot more practice, we hope it will be just the ticket for modeling our flows.

Numbers of the Day: windows open: 15. Number of editors open in Eclipse: 54. Number of tabs open between three Firefox windows: 35. Total windows open counting Eclipse editors and Firefox tabs: 100.

The problem was as follows: without RichFaces, creating a new prayer request from the prayer list page required a simple command button pointing to a simple xhtml page, “prayerRequestEditor”, where you could edit a new prayer request, save, and return. However, we intend to have at least one other page in the application link to PrayerRequestEditor. How were we to ensure that, on completing the edit, the user would be returned to the page they recently left? The immediate solution was to copy the entire prayerRequestEditor and define different navigation rules for the two identical files. Surely, we thought, there must be a way to avoid having to maintain two identical files on the server.

Our first solution, which we spent the majority of two days pursuing, was to implement Apache-Shale dialog manager.

A dialog manager such as this one uses a small number of easy-to-understand states to define a “dialog” or “flow” for a webapplication. Navigation from page to page, actions between and inside views, and action reversal should all be gracefully carried out in a properly written and executed dialog. Shale’s logic was very much to my liking.

Not only did Shale promise to rid us of wasteful code copying by modeling multiple subdialogs pointing to the same dialog body, it also offered a way to implement dialog-scoped data. Data stored in web session tends to slow things down, so it is best to keep controller-bean’s properties in request-scope, causing them to be erased from session after each mouse click. Unfortunately, this also forces us to reload them with each mouse-click if they are needed, and that puts an even greater strain on the database. The happy medium is the dialog scope, which, if it existed, would magically mark objects for cleanup when the dialog, and their usefulness, ended, but keep them in session for the duration of the dialog. Shale offered this functionality through a dataClass object in which we could store variables like a currentList and currentPrayerRequest as dialog-scoped.

Unfortunately, it took us more than two full day’s work to get the framework running, and even then, it did not do what it promised.

Our first problems arose when, upon entering the prayerRequestEditor subdialog of the listManager parent, the supposedly dialog-scoped current-variables were empty. Null pointer exceptions flew; we grumbled quietly and fired up debugger.

Several hours later Mr. Chandler had waded through a morass of code and abstract dialogs, dialogContexts, and dialogContextHelpers and was convinced that there was a bug in Shale’s source. The subdialog did not know it had a parent dataClass.

Several more hours later Mr. Chandler had waded through a quicksand of Shale’s source, trying several changes, non of which were successful. With our new deep knowledge of Shale’s workings, however, he decide to hard-code the parent id onto an instance of the prayerRequestEdit dialog.

It was 10:20 pm when we finished jerry-rigging the prayerRequestEdit sub-dialog and, bleary-eyed, celebrated our success. In fact, we celebrated two successes, as, for the first time outside of junit, we created and committed a new prayer request.

We were too tired to grumble over the fact that we had spent two days trying to avoid duplicating code for navigation purposes, and had failed. Because we entered prayerRequestEdit outside of dialog-config, we could not find a way to cause the listManager dialog to treat it like a subdialog. We had to hardcode the end-event viewId, meaning that we would need to create a duplicate dialog with a separate viewId if we wanted to access prayerRequestEdit from two different pages!

Our experience with Shale has, to say the least, been disappointing. Today’s Note for Dense Summer Interns: if a code framework causes you to work many times longer on a problem than you would have, and still doesn’t solve the problem, consider getting a new framework. As you will see in the next Jobber’s Log, that’s what we did.

Common Acronym Confusion of the Day: JSF, as programmers use the term, stands for Java Server Faces, not Joint Strike Fighter.

Unfortunately, the fact that two weeks have passed since I began work on the core page of the application signals that there are problems. Certainly, some of them are due to my lack of experience, and are to be expected. Others, however, have been caused or aggravated by implementing a4j and RichFaces.

While RichFaces is documented, there seem to be unmentioned complexities to the implementation of almost every component. When used in the environment for which they were designed, each component works excellently, but when we used them in conjunction with other components and other code implementations, time-consuming problems arose.

For instance, components such as rich:modalPanel rendered lightening fast on Internet Explorer but crawled in Firefox, while commandLinks in rich:dataTables worked on Firefox, but not IE!

As a detailed example of our troubles, and as today’s Note for Dense Summer Inters, we spent several hours working with Tamper Data and Eclipse console to determine what exactly was failing in a rich:dataList. The list contained links with a4j:actionparams that assigned the current variable object to the bean, for purposes of reRendering a view of the object’s details. It was only after wasting about a day that we discovered that the actionParam was not sending the object at all. Apparently, a4j:actionParam cannot assign as a value the variable of a rich:dataList, only properties of that variable. We switched to a rich:dataTable, and all was snazzy site design once again.

Today we decided that, until we got farther down the road of functionality, it was only shooting ourselves in the proverbial feet to struggle through a4j implementation and basic site design simultaneously. For now, we plan to drop RichFaces and use simple JSF until such a time as we have a functional site to which we wish to add a4j. At that point we must decide what component library to use. Among our options are first, of course, RichFaces, but also IceFaces and Dojo (which has an extra-impressive showcase!). RichFaces may be difficult to integrate with any portal other than JBoss portal, and Mr. Chandler believes we may in some future release want to implement LifeRay. This would be a vote in favor of IceFaces, which supports LifeRay explicitly.

So we sadly bid a4j farewell, for the time being.

Studying (or should I say geeking out over) various a4j graphic component libraries today, I came across the phrase “Lorem ipsum dolor sit amet consectetuer” etc one several occasions. Mr. Chandler told me it is the standard filler text for graphic artists. Curious, I looked it up, and here it is as the Filler Text of the Day: First, an article article describing the history of the phrase’s usage, giving a full translation of the standard text and the Cicero text it stems from, and offering to generate some random ipsum just for you!

Before half an hour passed, I knew I needed to study RichFaces. We hope to use a lot of rich components in the application, enabling the user to make changes large or small without refreshing the entire page, and to facilitate easy searches and selections. so I looked up the RedHat team’s RichFaces Live Demo, and spent the better part of the morning “geeking out” over all the exciting components they offer. It was so much fun that it is the Website of the Day!

Then it was time for a simple test; I decided I would add rich validation to the account creation page, telling the user on screen if his or her field entries were too short or too long, saving the trouble of waiting through an entire refresh to find out.

This test was successfully completed approximately six hours later. Lack of RichFaces knowledge led me on a merry chase for the correct functionality. With Mr. Chandler’s help, I made several useful discoveries.

First, in order to implement a4j and RichFaces, certain filters and context parameters are required in the web.xml, and they can be order-sensitive.

Second, in order to work properly, RichFaces must be allowed to access a file in the server path.
Our filter was intercepting this call. We fixed it by making the filtered path one step more specific, excluding the one called by RichFaces.

Finally, I discovered that a functional RichFaces validation on a simple field can be accomplished using the following simple process.

In our xhtml page, we first added the following line inside our input box tags:

<a4j:support event=”onkeyup” reRender=”passwordMsg” requestDelay=”1000″ />

This instructs a4j to wait 1000 milliseconds after the first keystroke in the input box is released, and then to reRender the component with the id ‘passwordMsg’. The requestDelay is included to prevent the server from processing requests generated by every keystroke.

Second, we added the following code after the closing tag for the input box.

<a4j:outputPanel id=”passwordMsg”>

<h:message for=”password” showDetail=”true” style=”color:red;” />

</a4j:outputPanel>

This is the panel reRendered by the support component. The h:message simply begins a normal validation process.

In conclusion, I am happy to say that today was tidy, encapsulated by the accomplishment of a single goal.

Today’s Note for Dense Summer Interns: The solution to your RichFaces problem is probably just one webpage away. Don’t keep experimenting with complicated solutions when you could be exploring more rich components!

Our conversation in Dunkin’ Donuts yesterday pertained to what structure our database should take to efficiently and effectively back the core of the project; today’s work flowed out of this discussion, as we created a class for each table we envisioned yesterday.

I learned a lot today about the @OneToMany relationship today, inescapable in a project that uses lists.

We also plan on using a lot of middle-man tables that include items that each include a pair of ids — that of two other “real” objects. This allows two different objects that each can point to many instances of the other object type — for instance, a prayer list can be referenced by many groups, but each group can reference many prayer lists. Each of these items has a one-to-many relationship to the ‘list-permissions’ table. Each item in the latter table has two many-to-one references back to group and list items.

Cool gadget combination of the day: remote desktop and voice recognition. I still jump a little each time Mr. Chandler says “wake up!” at his desk across the room. It’s only when he goes on to say things like “mouse grid…” and “press F8″ that I realize he is using his voice recognition software, and was not, after all, under the impression I was snoozing. If it’s cool to be able to talk to your computer, just think how cool it is to talk to someone else’s computer! Mr. Chandler and I make use of VNC almost everyday, allowing him to see and control my box without having to walk across the room and trade chairs with me. today we tried out the voice recognition in conjunction with VNC, with success.

Wednesday I worked from home, and after digging through a few errors thrown when I clicked on a registration link, I ran into one I couldn’t fix. It was a simple java.lang null-pointer exception thrown when the code was supposed to parse arguments passed in on the link. Email communication with Mr. Chandler led to liberal use of Eclipse’s debugger. I set a break point in the code where it was supposed to use a method of FacesContext.getCurrentInstance().getExternalContext() to find the url arguments. The hash maps that getRequestMap() produced were monstrous tree diagrams, full of circular calls and null entries.

It was Thursday before Mr. Chandler did the research to dig up a solution, which makes for an excellent Note for Dense Summer Interns: to parse an argument from a url, call FacesContext.getCurrentInstance().getExternalContext().getRequestParametersMap().get("key")

We also wanted to pull out the host server and path from the url, so that we wouldn’t have to create several different hardcoded versions of the link to send from different test and production servers.

Having finished getting acquainted with the mail system, and setting up our registration service, we went to Dunkin’ Donuts to celebrate and talk about database design for the core of the project. Details of that discussion, what came of it, are due tomorrow.

Number of the Day: 32: the number of files open in Eclipse at the same time Thursday afternoon.

Mr. Chandler took a look at the code I wrote on my day at home last week, and suggested a number of refactorings. For those who don’t know, ‘refactoring’ is a coding term meaning redesign of the code to make it easier to run. read, and reuse. He also suggested I remove several errors.

This done, we found that the link produced by our code and sent to the new user still did not behave properly. Instead of accessing an almost-empty view page and triggering a registration process, it did nothing at all before sending the user onto the login page.

We quickly realized this was due to a filter active in the project that prevents any unauthorized user from navigating to a restricted page. Since all pages are default restricted, and the filter redirects to the login page, it was intercepting the browser en-route to the registration page.

So Mr. Chandler fixed it. I am ignorant on matters of String splitting and regular expressions, but somehow Mr. Chandler modified our filter class to exclude a list of paths from the filter process, allowing the link access to the registration page.

Yesterday and today’s problems demonstrated how we often have to work through issues that, while preventing us from moving any farther in our envisioned site design, force us to prepare now for what would otherwise become major hindrances in the future. We are tempted to be discouraged, but a bit of reflection reminds us that we still got a lot of important things done — they just may not be what we planned to get done. Hopefully we will deal with problems while they are still in seedling form, before they have a chance to crash servers.

After today’s work was done, Mr. Chandler and I drove up to the North Side of Atlanta, grabbed a bite to eat, and attended a meeting of the Atlanta Java User’s Group, affectionately referred to as “AJUG.” I have fond memories of this group. The first time I attended the monthly Tuesday evening session, they gave away free T-shirts, allowing me to proudly announce myself to the world as a new Java User.

Today’s Note for Dense Summer Interns: Do not try to test code that requires web access while driving through downtown Atlanta with a wireless box. All the wireless enabled coffee shops in the world won’t help you get online when they are whizzing by at 75 miles per hour.

Clothing Tip of the Day: Be a computer programmer and you can wear whatever you like. At the Java User’s Group, there were in attendance a wide range of accouterments, from t-shirts, shorts, and sandals to ties, pants, and dress shoes. The only requirement in a programmer’s the dress code is a cell phone, blackberry, i-phone, or laptop that the owner of which must frequently glance at, type on, or cause to make loud beeps. Thank goodness I brought my Linux-boasting laptop!

While I manned the laptop on which we viewed the images, Mr R and Mr. Chandler discussed the ups and downs of well-known symbols and various shapes and abstracts. After discussing both the look and the message we desired in the logo, they finally narrowing the field to a few of the designs, which Mr. R plans to refine for us.

We spent most of our office time today refactoring our properties files. Before today, the ROA project used separate test and server (“web”) versions of application.properties, each containing a simple list of properties to be accessed by applicationContext. These properties defined our databases for the project. Separate test properties were used so we would not interfere with our server DB, and could use, for instance, a DB set to re-create itself every test, instead of updating.

Because we edit the project on a local computer, but deploy it to a webserver, we had pulled the webapplication.properties out of versioning and Eclipse, and created two different versions, on similar filepaths, one on the webserver, one on my local machine.

Today, to get these configuration files back into source control, and to simplify our code, we made two major changes.

First, we reinstated a generic applicationContext file, which extends truncated webapp… and testapp… files. These latter files now contain very little other than pointers to their respective properties files, as well as the generic context file.

Second, we created a new project under subversion called ’siteconfig’, and committed the test and webapplication.properties files for both the local machine and the webserver. We are now free to add more machines as we wish, and can edit only the appropriate files, but still maintain them in source control.

Difficult aspects of these two changes included getting the new Subversion project created properly, and making sure that the project knew on which box — local or web — it was running.

The Subversion software can be rather picky at times. There are some processes that can only be accomplished by a particular sequence of user actions and others that do not appear to be allowed at all (we are still learning!). This strictness is part of why the software is useful — it defines a certain way of handling files so that multiple users are prevented from accidentally overwriting or duplicating each others’ work. A bit of trial-and-error soon solved our naming and file placement problems, and we were able to commit our files to version control.

The problem of letting the project know which location it was running in was a bit more difficult, and, while Mr. Chandler did all the work on this one, it is, for lack of better subject matter, today’s Note for Dense Summer Interns:

In applicationContext, we parameterized the path to the new siteconfig files, calling ‘${tm.site}’ rather than hard coding the path and forcing ourselves to use two more applicationContext files. Now all we had to do was to configure the project to recognize the variable, and, more importantly, its value…

After much terminal and vi work, Mr. Chandler discovered that the correct place for a variable on our webserver was in the Java options for the ‘/etc/profile.d/java.sh’ directory. In order for the ROA project to pick up the values, we could either log back into the webserver, or start up another terminal window to trigger it.

For our local machine, Mr. Chandler put the variables into /etc/profile.

For running tests on Eclipse on the local box, Mr. Chandler used the following process. In Eclipse, he selected ‘window’, ‘preferences’, ‘installed JREs’, and ‘edit’, and added the new ‘tm.site’ variable to the default VM arguments.

Coding Axiom of the Day: The best way to fix a coding problem is often to delete things. Mr. Chandler and I have found this to be true in numerous situations, from last week’s headsmack to a problem with today’s new Subversion project, the latter of which was solved by deleting everything out of the filepath for the new project, allowing Subversion to recreate it.

First, I needed a test that would automatically populate a database, saving me the trouble of a lot of data entry.

Second, we needed tests that worked with MySql, not just hypersonicSQL, which we have been using for our tests.

Once I accomplished these goals, I could proceed to change a property type in my local database, and begin experimenting with database diff tools to see what types of good scripts they could generate between the local and web databases.

This was all in the interest of facilitating database versioning and implementing significant table and property changes on live databases.

Mr. Chandler made an interesting find today. He had previously VI-ed into the my.cnf file of /etc/mysql/ on my laptop. the MySql config file, to try to allow his computer access to the databases running on my local machine. The property ‘bind-address’ in this file was currently bound to 127.0.0.1 (which is localhost). He edited it to his computer’s IP, but we figured out today that now my machine couldn’t log in! This was, of course, because localhost was no longer the bind address.

It seems that MySql allows either one or all address in the bind address. Our fix was to enter the address ‘0.0.0.0′, representative of all addresses.

Today’s Note for Dense Summer Interns:

“…at runtime, each test case executes as an instance of your subclass of TestCase.”

This sentence in the office copy of J.B. Rainsberger’s book, JUnit Recipes is now highlighted bright orange. Mr. Chandler and I spent about three hours today trying to get one of our tests running properly because we did not recall this fact. Each test method in a JUnit Test (annotated @Test) will create new instances of class fields; therefore, changes to a variable inside of a TestCase instance will not affect other TestCase instances! We learned this the hard way.

(While learning this lesson the hard way we were forced to learn many other valuable lessons about Spring @Transactional, Spring rollback, and Hibernate persistence. One could argue that JUnit is still doing its job by forcing us to understand what we are doing.)

So, what if you want to change a variable in one test block and have it influence another block? We met with some success declaring our class fields static.

Today’s Linux keyboard shortcut: cntrl-alt-d. Minimizes all windows. Handy for those times when you’ve just sorted through ten windows and realize that the file you are looking for is now underneath all of them on the desktop. I will have to try this out on Windows, but I am afraid it may be a Linux exclusive.
Update: Mr. Chandler let me know that this shortcut is indeed available to Windows users, in the form of the windows key+d.