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…

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.

WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'source' to org.eclipse.jst.j2ee.server:RememberOneAnother' did not find a matching property.

When we tried to run the webapp on a local browser, Tomcat could not find any of the pages.

What solved the problem for us was to delete an extraneous WEB-ROOT directory that had appeared near the top of our project directory after an Eclipse crash.

That is today’s Note for Dense Summer Interns.

We spent all day trying to find the solution recorded above. There wasn’t much help online — not too many people seemed to have had this problem.

Notice that Tomcat did not throw an error on startup, just the warning, yet was completely out of touch with the views of the webapp it was running.

In desperation, we re-created out Tomcat instance, deleted and re-imported the ROA project in Eclipse, and, finally, deleted and reinstalled Eclipse itself. However, every time we added JSF capabilities in order to deploy our webapp to Tomcat, Eclipse suggested a path to the web.xml file for us — through a WEB-ROOT directory. This was not a path that we ever selected, so we were curious why (and how!) it was suggesting it. Eclipse even retained this path after a complete reinstallation.

Finally, comparing the ROA project with an older version (checked out of our Subversion repository) in a diff tool, we noticed that there was a WEB-ROOT directory near the top of our folder tree for the current project, but not the old one. We had no idea how it got there, except that this whole problem had begun shortly after an Eclipse crash. After we deleted the folder, the web.xml location was wiped, and Tomcat ran normally. We had spent all day working on what could have been a thirty-second fix, had we simply known where it was.

Worse still, we had vaguely recalled having a similar problem before, and solving it without too much chagrin, and as soon as we deleted the WEB-ROOT folder, we knew that was how we had quickly solved the problem before. That’s one reason for this post — we want to document how to fix the problem if it ever arises again, and we want to make the solution available online for anyone else who experiences the same problem.