Started event going away

[Michael Lipp]

I have noticed that the "Started" event is supposed to go away in 1.7. I think this is a bad idea. Here are two use cases that require the Started event.

(1) Modifiying an event. In a component system, it is a desirable feature to wrap an existing component, in order to adapt its behaviour. In circuits I can achieve something very similar by adding a "wrapper-component" that listens for a started event, modifies the event in some respect and optionally restores the original state after the event has been processed (in case the same event object is used again). I admit that I can achieve the "Started" part with a filter as well, but balancing a filter-handler (for the start) with an "End"-handler (for the end) doesn't feel right.

(2) Tracking a "broadcast". If you want to track components that provide some service, you can do this in the way the dispatcher keeps track of the controllers, listening for registered and unregistered events from components of a specific kind. This, however, has two prerequisites: components must be "of a kind" (i.e. inherit from some class to be easily identifiable) and the relationship between the tracking component and the tracked component must be static. Being tracked cannnot depend on some state of the component. A more flexible approach is to send an event "SendEventIfYourAreAXYZ" and track the response events from the components. Those must, of course, be framed by a  "Started" query and "End" query event, so that a listening "registry" component knows when to start and end a new registration cycle. That's where the "Started" and "End" events from circuits 1.6 come in nicely.

 - Michael

[James Mills]

Hi Michael,

Thanks for your interest in circuits.

I think we removed the event.started property and related event because it didn't make much sense in our train of thought(s).

The way it was designed to work (before) was whenever you would call .fireEvent(...) a Started event would also be fired for the same event if event_object.start was True. We didn't find this very useful in any use-cases thus far and thought that the "right" approach was to use a higher priority event handler (or filter if need be).

I suppose we could add it back, but do you really need it ? Can you not achieve the same thing and achieve better resulted with a higher priority event handler or filter ? E.G:

@filter()

def on_before_foo(...)

or

@handler(priority=999)

def on_before_foo(...)

Let us know :)

cheers

James

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "circuits" group.
To view this discussion on the web visit https://groups.google.com/d/msg/circuits-users/-/sYVfVFgqqp8J.
To post to this group, send email to circuit...@googlegroups.com.
To unsubscribe from this group, send email to circuits-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/circuits-users?hl=en.

[Michael Lipp]

Hi James,

> I suppose we could add it back, but do you really need it ? Can you not
> achieve the same thing and achieve better resulted with a higher priority
> event handler or filter ? E.G:
>
> @filter()
> def on_before_foo(...)
>
> or
>
> @handler(priority=999)
> def on_before_foo(...)
>

Yes, this should work. But then it should also work to have a filter
with priority -999 instead of an end event, wouldn't it?

I know that the end event was re-added due to my comment on issue #22,
but actually I only asked for the end event *or* a replacement...

Regards,

Michael

[Alessio Deiana]

There's a difference.

The End event receives the event after the return value has been assigned to it:

event.value will be filled.

That said I am not sure it is really needed ?

[Michael Lipp]

Actually, event.value.value will always (in any handler) return the accumulated results from the handlers already invoked. So you can really replace the special end-handler with a handler with very, very low priority.

Of course, this handler with low priority shouldn't be a filter, as this prevents others from receiving this emulated end-event. It must be an ordinary handler with low priority.

[James Mills]

Yeah that sounds right.

cheers

James

Sent from my iPad

On 02/02/2012, at 21:15, Michael Lipp <m...@mnl.de> wrote:

Actually, event.value.value will always (in any handler) return the accumulated results from the handlers already invoked. So you can really replace the special end-handler with a handler with very, very low priority.

Of course, this handler with low priority shouldn't be a filter, as this prevents others from receiving this emulated end-event. It must be an ordinary handler with low priority.

--

You received this message because you are subscribed to the Google Groups "circuits" group.

To view this discussion on the web visit https://groups.google.com/d/msg/circuits-users/-/1pPQ7BfPEmMJ.