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

[Don Brown]

Cool!  Good to hear you integrated it so quickly.  Actually, I don't use
Netbeans at all, as those artifacts were left over from Dave's code.  In
fact, I've already spent some time cutting out the generated GUI code in
favor of that GriddedPanel class.  Personally, I use vim and jEdit, although
I'm trying Eclipse out for the first time with this project.  I've always
actively avoided IDEs but the way this project works so well with them, I'm
giving them another chance.

Sure, all those changes sound fine.  I'll send you the blogapps zip and look
over the changes tomorrow.  The blogapps code isn't forked, just not
released since Dave's book hasn't hit production yet.  Finally, I have been
using the svn repo since you switched (thank you!) so we should be on the
same page.

Don

On 1/19/06, DM Smith <dmsmith555 at yahoo.com> wrote:
>
> 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
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20060119/5ae34e7a/attachment.html