-
1. Re: Scoping for events
One idea would be to emulate scopable listeners in application code - by outjecting/injecting listeners, but this only works for one listener per event type (i.e., bijection name).
May this be a sign of a feature missing - I mean, some kind of aggregated outjection, where multiple components contribute to a single name (this would obviate need for a separate events mechanizm)? -
2. Re: Scoping for events
Of course it is possible!
events.xml uses method binding expressions, which can refer to any listener in any scope! -
3. Re: Scoping for events
events.xml feels like going against the grain of Seam, namely having "drag-and-drop configuration", or "zero configuration".
Am I wrong with this feeling? -
4. Re: Scoping for events
I think events.xml is perfectly reasonable. Remember what you are trying to do here: decouple the actual observer and observable classes. Annotations is probably not the Right Way.
Actually, thinking about it further, I think @Observer gives you everything you need. The observer method is defined by a scoped component! -
5. Re: Scoping for events
An application-wide instance of Init contains a map from event names to ObserverMethod. While each ObserverMethod certainly has a reference to component to be notified, this is not the feature I miss.
My problem is that this mapping from event names to observers is application-wide (read: monolithic), which is not consistent with value mappings (I mean, e.g., Component.getInstanceToInject) that use a kind of lexical scoping and thus it is possible to have different values bound to the same name.
Thus the natural workaround sounds to just store observers as values (bijection) and thus piggyback one feature on another, but unfortunately the nature of observers requires multiple independent components to contribute their observers to the same event name, and I do not see how to do that with bijection. I hope I am more clear now. -
-
7. Re: Scoping for events
Imagine an application with workspace management, which uses 3rd-party ProductFinder and ProductEditor components (for finding products by some criteria, and modifying a selected product), the finder outjecting a product, and the editor injecting the product. The application has multiple conversations in parallel, each of them holding a single instance of the ProductFinder and ProductEditor, and most importantly, each pair of the finder and the editor shares their own product, so searching products in finders do not affect editors that are not bound to them.
Now the question is - how does a finder notify an editor that a selected product changed? By event, of course! But calling Events.raiseEvent("productChanged") will notify all editors, not just the bound one. This is the problem I see, and I would be grateful if you explain the intended solution to this use case. -
8. Re: Scoping for events
He wants a way for events to be restricted to the context of the emitter. So he can have local conversation scoped events without worry that this event will bleed into observers in other conversations.
Apparently eventhough the @Observer method is defined by a scoped component, it is still observing events globally.
On the other hand, somtimes you want global events, sometimes you want local events. I'm guessing there's a request in here somewhere for the ability to specify some sort of event filter.
Are conversations supposed to be able to communicate with each other via events? Bug or feature? -
9. Re: Scoping for events
I am glad I finally managed to formulate my idea.
"CptnKirk" wrote:
On the other hand, somtimes you want global events, sometimes you want local events.
Why not just say: "the scope for the events you want varies", from application-wide (the only choice ATM) to a conversation-wide."CptnKirk" wrote:
Are conversations supposed to be able to communicate with each other via events? Bug or feature?
Having scoped events does not mean full isolation, it means controlled isolation. If you want conversations to communicate via specific event, just bind the event high enough in scopes to be visible for both conversations. If you want the event to be private to the conversation, bind it in the conversation. The same idea works for bijection of values, why not generalize it to events as well? -
10. Re: Scoping for events
"CptnKirk" wrote:
He wants a way for events to be restricted to the context of the emitter. So he can have local conversation scoped events without worry that this event will bleed into observers in other conversations.
Sounds to me like he is asking for the exact opposite."CptnKirk" wrote:
Apparently eventhough the @Observer method is defined by a scoped component, it is still observing events globally.
No, event processing takes place in the same conversation that produced the event."CptnKirk" wrote:
On the other hand, somtimes you want global events, sometimes you want local events. I'm guessing there's a request in here somewhere for the ability to specify some sort of event filter.
We can do "local", we can't do "global"."CptnKirk" wrote:
Are conversations supposed to be able to communicate with each other via events? Bug or feature?
Conversations are able to communicate with each other via session-scoped components, or via components held in a containing conversation. They are not able to communicate via events.
It would not be impossible to implement an event that is distributed to all conversations in a particular session, but it would be impossible to implement eg. all conversations in all sessions. not convinced that I like the idea. -
11. Re: Scoping for events
So, I still don't see why you can solve the usecae by having the @Observer method in session or application scope, and manipulate state in that scope, that will then be visible to other conversations.