It seems that we have discovered a problem with WebKit, most likely somewhere deep within the import code. However we do not have the experience necessary to track down the problem.

Recreating the problem

Click on each of the above links.
In each series of examples you will be presented with 2 pages. On the first page click on the 'Reports' button. On the second page click on the 'Cancel' button. In 3 of the examples you can safely continue this sequence for as long as you want. In example 2, you will get an error after clicking on the 'Reports' button.
After you have experienced all of this, you can come back here and read more about what is going on and why this is an issue.

Explanation of the various examples

Of the 4 links above, 3 of them work and the other causes an error to be thrown.
However, all of them are using the same code, although the location of the methods being called are slightly different.

  1. Calling a derived method

    In the first example, the method that is causing many of the problems has been moved to the GrandParent class. You should not see any problems with this set of classes. Think of this as the proof of concept series.

  2. callMethodOfServlet on a class in the inheritance tree

    In this series, the exact same piece of code has been called, but we are using callMethodOfServlet and the method is in the Parent class. For some reason this configuration causes the following error to happen;
    args = BParent.BParent.htBodyArgs(self)
    TypeError: unbound method htBodyArgs() must be called with BParent instance as first argument (got BFirstPage instance instead)
    Now, this is extremely confusing since the same code is being called in series 4, but that bit of code works. The only difference between this series and the 4th series is that the code for the 4th is in a subdirectory.
    Also note that due to inheritance class BFirstPage is a BParent.

  3. callMethodOfServlet on a class outside of the inheritance tree

    In this series, we are using the same code, but the class that contains the callMethodOfServlet code is derived from WebKit.Page and is completely disconnected from the code that is being executed.

  4. callMethodOfServlet on a class in the inheritance tree with code located in a subdirectory

    This is part of the confusion. The code in this series is the same as in series 2, with the exception of the location. All of this code is located in a subdirectory of the context and with the exception of the imports, this code is exactly the same.
    It seems very strange that the same code should work in a separate location.

Why not just use the simple solution

It seems that the simple solution to this problem is to simply place all of the code in a subdirectory of the context. While this would make the problem go away, it does not explain why the problem is happening.
Also, doing so smacks of a duct tape solution and seems to defeat the purpose of having separate contexts. And until I understand why this problem is occurring, I will have a lingering suspicion that WebKit is broken in some manner.

Background on the Application

The basic idea is that decisions will be made based on the state of the application using the given input and that the control flow will be forwarded to the proper page. The user will then interact with a given page and the control flow will return to the Controller class, which will make a new decision and then forward the control flow onto a (possibly) different page.
The application was designed to be used in a situation where the user will enter in a piece of data and some information will be retrieved about the data and they will then make decisions about what is to be done with it. The user can use either a keyboard and mouse or a hand held scanner. The scanner will translate a barcode into human readable text. This text will be entered into the text field on the page and the entire form will be submitted. It might be possible that the left frame that would contain the buttons could be a separate frame from the 'work' frame, but since my HTML knowledge doesn't extend that far, everything is a single frame/form. Also, the buttons that would be displayed (and thus the actions that the user can perform) are different based on the current state. Every time the page is displayed, the proper list of buttons is retrieved and displayed.
The controller class solution seemed to be the best solution given the problem and the constraints of the application. We currently have a working version that the clients are in the process of testing, so at this point, massive changes to the structure of the application are most likely out of the question.
Last modified: Fri Apr 2 10:31:26 MST 2004