Blunder Dome Sighting  
privacy 
 
 
 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.



Click for Blog Feed
Blog Feed

Recent Items
 
Republishing before Silence
 
Command Line Utilities: What Would Purr Do?
 
Retiring InfoNuovo.com
 
Confirmable Experience: What a Wideness Gains
 
Confirmable Experience: Consider the Real World
 
Cybersmith: IE 8.0 Mitigation #1: Site-wide Compat...
 
DMware: OK, What's CMIS Exactly?
 
Document Interoperability: The Web Lesson
 
Cybersmith: The IE 8.0 Disruption
 
Cybersmith: The Confirmability of Confirmable Expe...

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2007-02-03

 

Is There an MVC in the House?

I think I need to understand Model-View-Controller.  No, I’m pretty certain that I do.

{tags: Java  }

My MVC ignorance came up because I have to build Java GUI applications to test some features of a middleware package that impact GUI behavior.  This is a consequence of a highly-successful separation of high-level concerns that leads to a little low-level coordination breakiness.

The two ends of the middleware connection don’t have to know anything about each other, but the back end (which runs in the same process as the front) can put up modal dialogs that apply to the window that belongs to the application on the front end.  The modal part means that the main Window is supposed to not accept input until the dialog is dismissed.  The dialog is supposed to stay atop the application Window until that happens.  It’s not working properly right now, and that is a very serious usability matter.

The breakiness comes in because the front end is a Java application and the back end is operating in native Windows.  The middleware functions are delivered to the application by Java components using JNI.  At the back-end connection, it is all native Windows non-GUI code.

I needed a simple GUI application to use as a front end so I could observe the difficulties with this arrangement and also confirm the repair that I have in mind.

I started out fussing with the first real GUI application in the Swing Tutorial.  As far as GUIs go, the little application with one button and one label is enough.  But I have more elaborate things happening under the covers than just updating a counter every time the button is pressed.

I thought I needed to develop a more elaborate GUI too.  Fortunately, I started explaining this in a buddy call with Bill Anderson.  As the words came out of my mouth, I realized that I was making it too complicated.  I could do just fine with one button and one label to provide a test of what happens when the application underneath the Java GUI does something that provokes a dialog from the back end.

I still needed to refactor the Swing Tutorial example so that I could make sense of it for myself and be clear on where it is appropriate to add the application and extend the Controller part.  I often learn an application by refactoring until it makes sense to me and I can explain it to myself and others.  I did that with the single Java file and it is now larger by the amount of annotation I added, along with the logic that my test application requires. 

One problem with the example being in a single Java file is that it obscures the separation among the methods and my (or your) understanding which of them are only used in particular levels of the GUI operation.  A large part of the code is for initialization, and only one method and some instance data are involved in operation of the running application.  Sorting out the roles of the code is exacerbated by the little trick of having a static method of the single-class application fire up an instance of that very class and use it to constitute the view and also provide the Controller (i.e., the ActionListener implementation).   This is an useful device, here, but it further obscures the separation of function and the relevance of individual methods.  (People who see this trick tend to use it everywhere, and that makes for some really stupid Hello World demonstrations where it adds no value to understanding Java whatsoever.)

With the refactoring completed, I think I have a sense for a simple Model-View-Controller situation.  At least my test application works properly and demonstrates the known coordination problem in the middleware. 

My buddy Bill says MVC breaks his brain, and examples seem to fall down somehow.  He’s not the only one that is puzzled when MVC is claimed yet you can’t find one of the pieces (usually the M) nicely separated out.  I think I get it for my simple case.  The sense I make of it also seems to conform to the situations Ayende describes.  Having struggled to separate out the parts of an actual, simple case, even the Smalltalky explanation kinda sorta makes sense, although that is very abstract in contrast with the perhaps-overly-concrete instances that come up in comments to Ayende’s posts.  In contrast, the effort to characterize MVC in Design Patterns leaves me with my eyes crossed and ringing in my ears.

I am happy for now, although I think I will have to know far more when I write the guidance for use of my middleware fixture by Java applications. 

I already see where I am going to have a serious challenge in raising my understanding to a level where I can provide realistic examples that others can grok.  Because operations of the capital-M Model can lead to dialogs and user interaction at the back end, calls into the Model from event-loop entries of the Controller (although nicely thread safe) can take an indefinite time before returning control to the event loop.  This will also block the Java event-handler thread while a back-end dialog is up, and that means no front-end windows will be refreshed.  So I might have to provide guidance on having Model operations carried out on a separate thread from the Controller procedures. 

In that event I’ll get to worry about providing guidance on the thread-death oblivion chasm and how to avoid falling into it while also preserving dialog modality.

Aieeeeeeee.


You might surmise that I am not a GUI kinda guy.  You’d be right.  Web pages, yes.  GUI, no.

All of my work on this project has been tested and demonstrated using console applications, whether Java-based or for native Windows.  I have used command-line compiles and utility operations for the entire project.  My one concession to the modern era is to use jEdit for my Java, C++, and batch scripts.  I’m using the Visual C++ 2005 Express Edition command-line compiler and running naked through the Windows Platform SDK.  I could have used the VC++ IDE, but I was using jEdit for the Java bits anyhow and it was simpler to stay in one editor. I also use Visual Source Safe and the VS 2005 Express Editions don’t integrate with VSS so there is not much gain to using VC++ projects (although my file organization is compatible with someone doing that).  When I put the software up on SourceForge, I will add Subversion to the mix.

I always wanted to do GUI work, and I will be doing some more-serious forms of it.  I just didn’t want that learning curve in the middle of this project.  I am thankful that, for my testing requirements, the modified one-button tutorial example is the least that actually works.  I shall now dive into my hand-rolled custom-factory COM code where I am completely at home.  Different strokes for different folks, as they say.

[update: 2007-02-04T17:57Z the last paragraph needed some tweaking and I couldn’t stand to leave it alone.]

 

Nano-ISV Are I, Are I

I’m a nano-ISV.  I don’t have a better way to define it.   My ISV-ness is smaller than what a micro-ISV endeavors to become.  I’m uncertain that I have the moxie or the ambition to move to the micro-ISV level at this stage of my vocation.

I have an open mind about it, although I have to be careful to keep my eye on what is important to me.  That is being a scholar, writer, and software contributor, not necessarily a rip-snorting product-selling micro-ISV operation.  But having a self-sustaining operation (and more) is important, and that means having customers of some fashion.

{tags: }

Thanks to a tip-off from Joel Spolsky, I learned that podcaster and Microsoft developer evangelist Michael Lehman specializes in micro-ISVs and is co-hosting the MicroISV show on Channel 9.  How come I have to read a blog to find out the neat things my acquaintances are up to? 

The great thing about the MicroISV show is that their 10th show (who knew?) launches a new format and the interviewee is none other than Mister Spolsky. 

About the format: There are published transcripts as well as downloadable versions of the podcasts.  That is very great because I can scan text a lot faster.

About Joel’s advice to micro-ISVs at the very end:

  1. There needs to be at least two of you.  I get that.  As a solitary developer, even at the nano– level, it is very difficult to stay on top of important matters that required different kinds of attention.  Writing code for that next beta drop versus paying the monthly bills and moving a domain registration, for example.  Or managing the project rather than doing the project.  I need to do something about that.  It might not be with an additional person in the business, but maybe through some sort of associate arrangement: buddying up as a kind of mutual assistance arrangement.  I have a critical need for a sounding board and for someone to help me balance my attention.  I’d be willing to share some revenue to make that happen, once there’s any of that worth mentioning.  
      
  2. Find a niche.  I’m fortunate in that I have a couple of those.  But it is reassuring that this is an appropriate way to maintain focus.  I also notice that it provides a way to stay concrete and not get lost in the conceptual clouds that I am easily prone to (and that I owe Joel for too).
 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $