On 10/27/11 18:07, Derrell Lipman wrote:
> Hi Burak,
>
> I don't recall making any change to that effect. The target parameter
> is not documented as optional, and I don't think it ever was. 
>

Hi Derrell,

This is actually from an older part of our codebase. Once we initialize
the fsm, we send it its initialization event:

            fsm.start();
            fsm.fireImmediateEvent("application_entry");

The relevant excerpt from the initialization code:

            state = new qx.util.fsm.State("entry_point", {
                "onentry" : function(fsm, event) { },
                "onexit" : function(fsm, event) { },
                "events" : {
                    "application_entry" : "to_login_screen"
                }
            });
            fsm.addState(state);

            trans = new qx.util.fsm.Transition("to_login_screen", {
                "predicate" : true,
                "nextState" : "awaiting_login",
                "ontransition": function(fsm_, event) {
                    // stuff
                }
            });
            state.addTransition(trans);

One should not need to pass anything to the fireImmediateEvent. The fsm
object has the potential to either handle the event given its current
state or reject it by either throwing an exception or ignoring it if no
edges depart from the current state with the named event. (which makes
qx.util.fsm.FiniteStateMachne a finite state transducer rather than a
finite state machine but anyway) So i think the documentation should be
fixed as well.

I've fixed the bug, It's a simple, one-line patch:
https://github.com/qooxdoo/qooxdoo/pull/4

Best,
Burak


> I am trying to figure out what you'd expect to happen. Events are
> fired on (target) objects. What does it mean to fire an event on an
> undefined target object? What used to happen when you fired an event
> with no target? 
>
> I suspect something else is going on here other than what you think it
> is. One change that was made, probably between 1.4 and 1.5, was that
> the transitions and states can have a "context" member in their
> configuration map, which specifies the context in which the functions
> such as ontransition, onentry, etc. should be called. It's possible
> that I erroneously altered the the default (no context member) context
> so that it doesn't work like it used to, but I'm not sure how that
> could be affecting the particular issue that you're having...???
>
> Derrell
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
>
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to