Where is the error log located, probs with Mail sample

[JPS]

Hello,

I just started evaluating the designer. I attempted to open in design view the Mail sample that Google provides. A portion of the app (the mail list on the right) gave the message:

Exception during the creation of MailList
See "Error log" for details.

Could someone tell me where this error log is located? I can't find it so I can't investigate further! (Also if anyone happens to know what this problem is, that would be helpful too!)

I can view the MailList.java individually in design view - it's when I try to view the entire app (in which the MailList is just the righthand portion) that I get this error.

I am using GWT 1.5.1 Designer 5.1.0 with JRE 1.6.0.

Thanks!

[Eric Clayberg]

I just started evaluating the designer. I attempted to open in design view the Mail sample that Google provides. A portion of the app (the mail list on the right) gave the message:
Exception during the creation of MailList
See "Error log" for details.

The Mail example has a bug and is poorly designed from an OO point of view to begin with. It throws an NPE at design time (it's not very carefully written), so you need to fix the following NPE (which you should see in your log)...

Code: Select all

java.lang.NullPointerException
   at com.google.gwt.sample.mail.client.MailList.selectRow(MailList.java:145)
   at com.google.gwt.sample.mail.client.MailList.update(MailList.java:196)
   at com.google.gwt.sample.mail.client.MailList.<init>(MailList.java:69)

The MailList class sends a get() call to the Mail class to access its singleton without testing that it is non null or ensuring that the singleton is actually created. The get() method itself returns the singleton field without ensuring that it is populated. The example relies on runtime-specific behavior to populate the singleton instance (the call to the Mail.onLoadModule() method). When editing the Mail class at design time, there is no instance of the Mail class created. The Mail class is parsed; it is not instantiated. Any code that tries to actually access the instance of the class being edited will not work because there is no such instance.

If you comment out the line Mail.get().displayItem(item); in the MailList class (or add an null check for Mail.get() prior to that line), the Mail class should open in Designer.

From a purely OO point of view, the Mail example is poorly designed. The classes are tightly coupled (when they don't need to be) and the MailList class unnecessarily breaks encapsulation by talking directly back to the Mail class via its singleton.

If you want to evaluate GWT Designer, I would recomment just starting with the Quick Start guide.

Could someone tell me where this error log is located?

The Eclipse ".log" file is always in your workspace .metadata directory.

[JPS]

Thanks for the quick and helpful response Eric!

The Mail example has a bug and is poorly designed from an OO point of view to begin with. It throws an NPE at design time (it's not very carefully written), so you need to fix the following NPE (which you should see in your log)...
[...]
If you comment out the line Mail.get().displayItem(item); in the MailList class (or add an null check for Mail.get() prior to that line), the Mail class should open in Designer.

I'm glad I'm not the only one who thought that it wasn't a very well written program.

Your explanation makes perfect sense, and now that you told me where the log is, I indeed see the NPE and can comment out the offending line to see the whole form.

If you want to evaluate GWT Designer, I would recomment just starting with the Quick Start guide.

I did this as well, and did some "hello world" type stuff. Since I'm also evaluating GWT (not just your designer) it seemed useful to poke around Google's sample code to get an idea how flexible GWT is and what's possible with it. Also another thing I was trying to do here was to see how well GWT designer could interrogate existing forms designed in another fashion.

Anyway I do realize that in this case, Designer was clearly doing the best it could with code written without any design time considerations in mind. I'm new to GWT but not java or form designers so everything you stated seemed very reasonable.

[JPS]

As a follow-up for the mods, I also just tried using the Showcase example with Designer and ran into even worse nonsense. Luckily this time I knew where to look for logs and got through it! I'd be happy to post about that experience, since I might not be the only person who decides to use the Google sample code as a test drive for Designer, but I don't want to clutter your boards either (since all the nonsense seemed related more to either Eclipse or Showcase idiosyncracies). In short, I had to add "gwt-dev-windows.jar" to the classpath, but even after doing that, Eclipse didn't seem to communicate the new classpath info to the Designer plug in until after I completed removed and then reimported the project to my workbench (restarting eclipse wasn't sufficient).

The showcase code doesn't seem any better than the Mail code, and the Designer doesn't seem to be able to interrogate much of it in a useful fashion due to its (Showcase's) design. Ugh.

[Eric Clayberg]

another thing I was trying to do here was to see how well GWT designer could interrogate existing forms designed in another fashion.

GWT Designer can generally reverse enginner 80-90% of hand writted GUI code (which is 80-90% better than any other GUI builder).

[JPS]

GWT Designer can generally reverse enginner 80-90% of hand writted GUI code (which is 80-90% better than any other GUI builder).

What I'm finding is given the manner in which the Google samples are written, so much of the behavior is dependent on run-time only information that it's not really giving much useful feedback during design time. (For instance, tree structures, icons, etc are often populated in manners inaccessible to the designer). A lot of forms show up completely blank... I wish Google had created simple and clear examples rather than trying to cram all the features in - they would probably be more illuminating and play better with your tool. C'est la vie. It's not all that important really, since in the end I'm interested in how well I can use the Designer, not how well the Google samples can! Thanks for the replies.

[Eric Clayberg]

so much of the behavior is dependent on run-time only information that it's not really giving much useful feedback during design time

Designer is only going to render the stuff that is statically defined.

Anything runtime-specific behavior or dynamic behavior (within conditionals, loops, etc.) is ignored.