[PEAK] Connecting the Trellis to non-trellis systems

[Phillip J. Eby]

At 05:52 PM 3/11/2008 +0200, Sergey Schetinin wrote:
>Event binding:
>
>onevent(ok, CLICK, lambda: ....)
>
>or
>
>@on(ok, CLICK)
>def ...

The way these would work in the framework I envision, is that you'd 
simply do e.g.:

    if clicked(self.ok):
        ...

in a rule body to detect clickedness -- which means that more than 
one rule can depend on it.  You don't need to choose a specific 
method to handle it.  This can be especially useful when subclassing 
or doing dynamic extension, or even just handling multiple things 
when the button is clicked.  That way, you can write the code you 
need, instead of having to twist it all around to suit the way the 
events come in.


>The event handlers can decide to accept additional info from event 
>dispatcher (sometimes some info is only present in the event object 
>while the event is being processed). There also needs to be a way to 
>stop event propagation, so this works as expected:
>
>@on(frame, CLOSE)
>def onclose(stop):
>     if not may_close():
>         stop()

I expect this would be handled with something like this in the body of a rule:

    if close_requested(self):
        if not may_close():
            cancel_event()

The cancel_event() would simply cancel the "current event".  This can 
easily be done by having the event connector callbacks stash the 
"current event" somewhere, if the GUI doesn't already have a way to 
get it.  Since close_requested() can only be true during a 
recalculation spawned by the reception of the event in question, 
there's no way for cancel_event() to be called when there isn't a 
current event.

The same thing is essentially true for any other API that would want 
to get data about the current/last event of a particular 
type.  Indeed, the cells connecting to those events could perhaps 
keep a reference to the last seen event, as well as an indicator of 
whether it's still current.  (i.e., both a "discrete" cell and a 
"continuous" cell for the same event type).

Obviously, details are still a long way away at this point; there's a 
bunch of intervening stuff to do, like getting a Trellis 0.6a2 
release together that contains the Sensor, Effector, Connector, etc. 
classes, and docs, tests, high-level API, etc.  (Plus the new Pipe 
type I'm using in my FreeSwytch project.)

And, officially I'm supposed to be working on SQLAlchemy integration 
right now, not the GUI part of all this.  The Effector type is needed 
for that, but there will probably be other needs as well.

I suspect that for documentation I will do another separate "man 
page" (.txt file/wiki page) for "Integrating With Non-Trellis 
Systems", rather than try to cram it all into any of the existing 
documents.  Especially since it will want to grow to reference 
SQLAlchemy integration, as well as GUI examples.