[jsword-devel] Building on Bible Desktop: BibleBlogs.Net

[DM Smith]

Don,

I've checked in your code. The code that you have is most excellent and 
I am looking forward to putting it in front of users! Thanks so much for 
your contribution! Once we have it ready for release, we'll announce it 
for people to look at it from the nightly and respond to their comments. 
Then we'll release!

I have made some simple changes to quite CheckStyle. We have it set up 
that if you run ant against build.xml in jsword-web that it will build 
all the projects related to BibleDesktop and also the web. And then run 
a series of QA checks. You can do this from the command line in the root 
of jsword-web. The pertinent commands are:
ant all (does a clean, build, install, check)
ant incremental (does a clean, build, install, check)
ant checkstyle (runs only checkstyle, but it only works after a build.)

And I made two other changes. I already mentioned that I moved code from 
StatusBar into Desktop. The other change was that I used a "Type safe 
enumeration" pattern for the type of Blog, called appropriately BlogType.

I hope that my changes and the huge refactoring job that I did, did not 
get in your way.

Below are some more things that probably should be done to make it 
similar to the rest of the code.

Don Brown wrote:
> Cool, yeah, I've started doing the same, going through and cleaning 
> things up.  The GUI code has tons of errors for two main reasons:
>  * Still not 100% sure how you solve localization, so there are a lot 
> of labels and error messages still in the code
As noted before, we use the Msg class for localization of messages. I 
took care of that for you. I also marked strings that didn't need to be 
localized.
As to error messages, we use the o.c.c.util.Reporter static informUser 
methods. Listeners for ReporterEvents will then handle the message 
appropriately. So we never print exceptions to std err. See 
o.c.b.desktop.DesktopActions for examples. We let listeners figure out 
the best way to communicate to the user. So we don't create and manage 
dialog boxes on the fly.
>  * Most of that code was forked from the Blogapps code, where it was a 
> standalone Swing app.
In doing the connection, it appears that you are doing it in the main 
thread. We have a Job class and a Progress meter that we use for long 
running background processes. See 
o.c.j.book.install.sword.AbstractSwordInstaller's install method for a 
good example. Also see the documentation for JobManager.

I would appreciate it if you could provide blogapps-1.0-src.zip. 
Especially, if it is forked. In that case we may want to manage the 
forked source.
> Furthermore, a lot of it was autogenerated by Netbeans.
In localizing buttons, and other actionable things, we use 
o.c.c.swing.CWActions and o.c.c.swing.ActionFactory and an action 
property file. An example of this is DesktopActions.java and 
Desktop.properties. This is also a good example of splitting the 
responsibility of a complex screen into two classes. One for the GUI and 
the other for handling the events generated by that GUI.

The basic idea is that an ActionFactory will read the property file and 
construct CWAction objects. The ActionFactory will then dispense of 
CWActions by name. Also the ActionFactory and the CWAction work together 
to use reflection against a "bean" to call a "do" method constructed 
using the name of the action.

The reason that I mention this is that I don't think it fits well with 
Netbeans auto generated code. I left it alone so you could see if you 
could integrate it using NetBeans.

In His Service,
    DM