In article <40758C97.6070906 / path.berkeley.edu>,
Joel VanderWerf  <vjoel / PATH.Berkeley.EDU> wrote:
>Its Me wrote:
>
>I've been following the discussion with interest, but probably won't 
>really digest it until the weekend.
>
>The "specification language" style of GUI programming is very tempting, 
>but OTOH the Fox API is pretty good already, so that's one reason why 
>it's still on my to-do list :)
>
>Maybe the possibility of abstracting from the particulars of the GUI 
>toolkit is the point that will tip the scales towards this specification 
>approach.

Toolkit-neutral GUI code would be cool.

>
>I'm also interested in the explicit state machine idea that came up 
>elsewhere in the this thread, and the possibility of integrating it into 
>FoxTails. Observable attrs can already be thought of as synchronization 
>of state machines, but the state is just a bunch of variables. Sometimes 
>it is useful to have an explicit notion of state in the sense of 
>"discrete mode" and explicit transition rules, entry/exit actions, etc. 
>Expressing state in this way, if possible, may be clearer than just 
>using some related variables and observer code.
>

I define a class for each state in the machine (and I 'include 
Singleton' in their superclass, State ).  The 
transitions/actions/etc are contained in the state classes.  Each state 
class has a 'do_action(event)' method, that looks something like:

class LoginState < State
  def do_action(event_class)
    if event_class == NextEvent #Next button or 'return' key in console
      
      begin
        status = do_login(@@ui_obj.email,@@ui_obj.serial_number)
      rescue Errno::ECONNREFUSED
        @next_state = ConnectionErrorState
        @@ui_obj.display_message("Could not connect to site")
        return
      end
      #figure out which state to goto next
      case status
      when NewUser
        @next_state = VerifyEmailState
      when DuplicateSN
        @@ui_obj.display_message("Duplicate Serial Number; please 
re-enter")
        @next_state = LoginState
      when...
        ...
      end
    end
end

NOTE: @@ui_obj points to a proxy class that acts as a 'translator' between 
the state machine and the actual GUI code.  It should make 
it easier to use different toolkits. 

The StateMachine class itself is Observable, not the states themselves in 
this implementation.  Sounds kind of like what you're describing. 

Phil