Take a look to the code:

SomeEditor>>wireSaveButtonFor: anItem
	self saveButton
		subscribe: MVPSubmitButtonPressed do: [:ann| self onSaveRequestedFor: anItem] ;
		yourself.

If try to use there a #send:to: I’ll have to find somehow that item so it’s great to use #on:do: there.

The only thing I really had to take care of is to subscribe only once so subscriber evaluates only once the reaction.

Just for convenience I’ve made a couple of methods in Announcer so I can subscribe as usual or only if don’t previously subscribed (#ifNotYetSubscribe:send:to:) for sends.

I need the same convenient feature for #on:do: but is not as easy as with message sends where you can look the receiver to decide if already subscribed. With contexts you can compare the home but I’m not sure if that it will be enough for all cases to decide if subscribed or not.

As for #send:to: and #on:do:, that’s cool, I was just wondering if you preferred one over the other, I guess not.

Also I get your point about app to app interactions where this also apply. In fact today I was wondering how I’ll make this seaside apps to run in different images and interact. For instance a simple seaside app running in an image that just login users and redirect valid sessions to the right application in the right image. Probably something like rst or remote objects should be used for that.

About the #send:to: and #on:do: I think it’s not big deal. Don’t make a significant difference unless you want your code more testable. If that you usually make more granular almost all just to test all that you can. Also you may want the same action of that instance to be achieved as a reaction (the category under I use to put those #onSomethingHappened: methods) of that announcement and also from other causes that are not reactions to announcements.

Beside those cases I don’t see why not to use #on:do: have the two options is sweet.

I ended the refactoring and still amazed with the amount of simplified code and now I’m going ahead on the design in a very clean way. I feel there is more room now.

Personally, I prefer to sling blocks instead of symbols so I usually go for #on:do: instead of #send:to:, though I can’t totally say why, other than it feels better. I’m interested in why you prefer #send:to:, if only to test my preference.

I do also like the idea that not every object is automatically it’s own announcer, sometimes a global announcer is nice. I wouldn’t want to be constrained to child to parent events. Thinking about it, it might even be interesting to have an event be its own announcer instead of some context specific place like the session. Maybe you want to have user to user interactions or app to app interactions.

This is the approach people should prefer instead of wanting every component to have a parent, a common complaint about Seaside. Having a parent inevitably leads to tighter coupling while children throwing events naturally leads to loose coupling and more composeable objects.

For components the critical decoupling is needed from a component to its parent, so.. I’m using now one Announcer per component. I’ve set it in an instVar in the abstract class of my components family and all the wiring stuff get massively simplified.

To illustrate this, now I can do:

SomeComponent>>wireEvents
    super wireEvents.

    self someSubcomponent downOneItemButton
    subscribe: ButtonPressed send: #onSubcomponentDownOne: to: self.

It feels really good

PS: to be completely analog (and more because they are objects) to the #wend:send:to: of the Smalltalk itself one should have one announcer per object but for now that is unnecessary.

cheers,

Sebastian
PS: suggestion noted

Your English can be a bit hard to follow sometimes, might I suggest Smalltalk is often terser and clearer than English when you’re trying to explain something interesting.

At first I’ve started simple and, like you said, put some collaborators on the announcements so subscribers can decide what to do.

Then I’ve see a valuable chance of using double dispatch. That way subscribers can understand a kind of reaction but each can implement the reaction in it’s own way.

Just a comment about your last sentence:

“I see the announcement as a way to enable loose coupling, making them too specific would require too much knowledge from the subscriber to be considered loosely coupled.”

Loose coupling is meant to be between the subscribers and the announcers. Aprioristically it doesn’t care at all how much coupled a subscriber is to an announcement. In fact the way you describe you use them (making the subscribers what to do depending on the announcement carried objects) seems tightly coupled when compared to one single double dispatch polymorphic message. But see, that could be just fine until happens to you that you need better than that. By better I mean you *need* polymorphism among subscribers so that’s why I’ve used there double dispatch.

I’d never have announcements so specific that I needed hundreds of them, I’d make them general enough to have a few dozen at most, and carry the extra data on them so listeners can make the decision whether it wants to act on the announcement or not.

I see the announcement as a way to enable loose coupling, making them too specific would require too much knowledge from the subscriber to be considered loosely coupled.

-pollution of the namespace
-consumption of time (so capital) naming things
-consumption of time in organizing classes in packages of about one hundred or two hundred announcements
-To name a new announcement of the very same nature just to make react some particular subscriber. (Now I wonder about this being the critical one)
-Other hidden costs?

Of course each *ingredient* will be lighter of harder regarding on how heavily or lightly make use of announcements.

For rich web apps. the trend I’m sensing is to be more heavier than lighter.

So the short answer is: it’s necessary if you want to scale the management of subscription and reaction to announcements in a more general way but maintain things cheap.

A concrete example (that I will describe simplified): today I’ve made some editor component to announce aPresenterEventWiringRequested. That announcement claims that it’s adding a script to #click event for one of it’s buttons, let’s say a save button (don’t think in a submit button here but, from the DOM point of view you can think as if it where a div with an image inside).

The motivation bound to that announcement is the presenter itself (in fact is an editor with a toolbar (with #save and #cancel buttons) and some fields).

A distant parent presenter of it, has also interest in performing something when #click happens on that element’s button, so it register itself as motivated by any PresenterEventWiringRequested who has as subject that presenter.

When real render time comes for the #click of that button the editor component adds it’s own action scripts and announces. That way the subscribers, that distant parent between them, because it was motivated, receives that announcement so they have the chance to add it’s own scripts (maintaining the separation of concerns between them).

With a little help on how to render things the result is that you’ll have the script of that button with the effects or stuff of he’s own, lets say close the editor with an effect, concern added to the other scripts added by the motivated subscribers, lets say to change some status bar or whatever task or update disconnected from the editor.

That way I have only one general announcement for doing things about how to wire element’s events that only the proper instances will react to and I’m not forced to create different ones just because it’s another button (just to mention one of a dozen of widgets multiplied by about a dozed of potential events they can react).

I hope I’m being clear enough :)

Cheers,

Sebastian

I faced the situation in which I want to subscribe some component to an announcement but that component don’t want to receive all the announcements of that kind of announcement. I just want/need that component to receive some of them and ignore others.

In the magazine analogy you’ll receive all numbers but you will select just those with the subject you are interested in.

First I thought about creating classes is very cheap (you only pay one slot in the global namespace and use some operative time for properly name it).

Lots of times that is enough but sometimes I actually need the same kind of motivation but with different subjects. So I wonder how you or if you know ways to deal with that.

I also wanted to expose here this to criticism to see if it survives more than mine (which so far it is because it works well):

I’ve made Motivations for that filtering process. Subscribers have a collection of motivations, empty by default. So they can define it’s criteria for selecting announcements by adding Motivations about subjects.

The announcements I’m using always have to be made and announced with a motivation.

So if the component matches the satisfaction criteria between motivations then the announcement performs the intended action.

As default satisfaction criteria I’ve implemented an affinity policy by making #satisfies: aMotivation to answer true when the motivations are same class has the same subject.

That makes the feature and prevents me of polluting the announcements space of names.

Cheers

MVP, Model View Presenter is remarkably implemented in Dolphin Smalltalk. This ST happens to be windows coupled and heavily desktop development oriented.

This environment is very good for that. It’s just desktop apps are today’s IMHO a more risky business than yesterdays.

You can download the community edition which is free and play around to have the MVP idea.

Several years ago in the seaside list (must be in the archives) I discussed about using seaside components as presenters (presenters in the MVP mean). So the gap between developing desktop or web apps is 5% (actually to achieve the gap to be 1% we need something full duplex like comet).

This allows reusability of basic presenters to be used and abused. I remember Avi arguing that in web the views are so custom that he was not convinced about that being good. I’m still seeing (now feeling) as a good equation for non hacker spirits. I’m feeling that the degree of compositionability is greater. Of course you can allways compose but one thing is to compose to gain just structure and other to gain structure and behavior. I’m feeling that using seaside like this brings a higher rate of real use of that common (so factorized) behavior trough composition as it used to happen in desktop development.

If you want to feed curiosity take a look in any dolphin st example how you will have to implement do a shell with a couple of TextPresenters (as inputs) and then suppose that you don’t have the TextView object that connects your TextPresenters to the OS primitives and callbacks.

Instead of having a TextView talking to the OS how to draw, you have an html canvas to perform the same task (of course todays user agents will make you unable to do everything you can do directly with the OS). That way, user agents becomes the OS and/or the hardware.

That’s the way I’m using seaside: for me user agents are hardware and the canvas are the assembler that gives me access to tell how I want things to be drawn (and a limited behavior by using prototype/scriptaculous).

So instead of XClassView’s I have “primitives” methods that renders the presenter serializing it in a mix of html and js as it’s species defines how to do it.

The user agents are who really have the View objects reified from that serialized stuff in the DOM.

So the architecture will be a kind of Model-PresenterView
a view that can do some stuff local and some other interacting with it’s presenter.

My hierarchy of seaside components is progressively refining as in an analogue way as you can see in it’s dolphin homologue Presenter class.

I even spend some time rising the bet by trying the next logical step: making the Views in user agents not to be a metaphore but real objects defined by it’s seaside homologues. That way seaside components will define it’s own behavior (at server) and the behavior of it’s DOM homologues instances (events wiring and reacting included).

That, for instance, allows multiple events triggered and reacting regarding to it’s species in the user agent without even one html request. The requests and the updates work only when absolutely necessary. Transparent access to factorized behavior, etc.

Was a proof of concept. Can be done. It’s works, but… todays it performs miserably. So I gave a step back.. I’m disappointed with js performance, memory consumption, bad GC.. what can I say. Using it right and performing bad.. stupid machines. It’s a pity. I’ll wait, I don’t know maybe in a couple of years. I’ve read that Firefox 4 will have a new js vm donated by adobe to the open community. That is promising x10 the actual performance. We shall see..

OK, now I’ve used announcements in the session and perceived that if a component subscribes 2 times the same announcement to send the same message to the same receiver, the receiver will receive 2 announces not 1.

Mmm subtle.. unexpected coming from a Dolphiner but it really can’t be considered wrong. If I subscribe myself twice to receive Nature magazine then is expected I receive 2 copies not 1.

One should manage subscriptions with caution about this.

Given the choice between the two, from my position of *new* code, the choice for Announcements is obvious, it’s more object oriented and IMHO more elegant than #triggerEvent.

As for OmniBrowser, I think it’s clearly already been adopted, all the new tools I see are being written in it, because *I guess* it makes building browsers vastly easier than prior frameworks (I’ve never build anything in Morphic, only Seaside so I can’t really say).

Clarifying and taking your line of reasoning my position can be compatible with something like: “hey, #triggerEvent can do this, why should I now look at Announcements and manage to pay the operative costs of the upgrade”.

Thanks for the link, I’ve already read the Vassili post about Announcements and still concluding the same two differences (documentation and elegance) because I’m still unable to see any additional one (that’s why I asked about that in first place summarized by the phrase “show me the value”).

Now.. it’s true that for new applications that cost would be less significant so it’s starting to be attractive *for those cases only* to embrace Announcements now. Which I see as the most valuable conclusion related to development emerging from this discussion.

I know you’re not trying of convincing me, I like that from your posts and your attitude in replies. You encourage but do not evangelize. That’s very valuable and is an intelligent position from my view.

About OmniBrowser well lets see what happens, I think the squeak and the ST community in general is clever enough to embrace valuable frameworks, and, as I said before, have no aprioristic problems with more refined systems/subsystems once they prove they induce better results.

I’m not trying to convince you of anything, that’s up to you, if you want to continue to use #triggerEvent because you’re cozy with, be my guest. Announcements are a better design, and if you want to get into the newer frameworks coming out, like Omni Browser, you need to learn Announcements because it’s what people prefer and it’s what is going to be used.

In inverse order:

1. About your claim of more looseness. As I posted before I see it depends on how you use them so I still unable to see where announcements it’s *more loosely coupled* as you claim. Can you demonstrate that?
2. About adding arguments to the announcement. It is a requeriment to solve what kind of problem? Anyway, nothing stops you to add whatever you want to the objects that came in the arguments of a triggered event.
3. You may already know that you can pass N objects as arguments of a triggered event using: #triggerEvent: aSymbol withArguments: anArray

Todays the only thing I’ve see as a difference with triggered events is:
1. Documentation
2. Elegance by reinventing the subsystem more object orientedly

I have no particular problem with the last two.

Listen.. I like a lot your blog because it brings to discuss very valuable things and it is getting richer and richer material is good to experiment things. This discussions are necessary to explore new possibilities. But I’m also a pragmatic person. So.. show me the value. (LOL)

Hey.. I’m all ears to listen what are those things easily doable with announcements that would be hard or impossible with triggered events once those things proves that they are valuable. In the meantime, with a little of curiosity about announcements future and community adoption, I’ll still be using triggered events.

self triggerEvent: #addQuotedItem:in: with: aQuotedItem with: aHugeBudget

and you passed args knowing what the method you’d be calling looked like, i.e. it takes two args. Announcements are more flexible because the event itself is an object, and it carries its arguments inside of it, if you add 2 or 3 more arguments to the announcement, it won’t break anything. It’s more loosely coupled.

Did you follow my link above and read Vassili’s reasoning? He goes pretty deep into explaining why Announcements are better than the old #triggerEvent and enable you do easily do things that were nigh impossible before.

self triggerEvent: #addQuotedItem:in: with: aQuotedItem with: aHugeBudget

and any other that has previously hooked #addQuotedItem:in: from it will receive the message with the arguments. This is working like this since MVC exists.

Anyway.. to be fair I have to tell that yesterday I though I’ve found an answer to that question and was: “more looseness, this is, to hook even unreacheables”.

When you hook a traditional event you make it by reaching the “neigher” object first like this:

self someComponent when: #someEvent: send: #someReaction: to: self

so with traditional events the reachability of the object that will trigger them is a must. While in the other hand with announcements you don’t need to reach the objects that will neigh the events and you will still receive the events when they happen. But then I’ve figured that it is not out of the box. That you implemented that by making one announcer reachable in the Seaside user session and all the rest hook to it.

And as traditional events makes any object the ability to be “an announcer” I’m perceiving reinventing wheel situation here because I can implement the same with traditional events.

Take a look:

Parent>>initialize
super initialize.
self session when: #removeChild: send: #removeChild: to: self

Child>>removeMe
self session triggerEvent: #removeChild: with: self

Now tell me you don’t love Smalltalk… LOL

self session on: RemoveChild send: #removeChild: to: self
self session announcer on: …

or have you implemented convenience methods on the session itself?

Cheers,

Mike