Any facilities to have global events, or a publish/subscribe model in Boo?

[Philosophil]

Hi

I'm curious to know if Boo has a built-in approach to handle global
events through a global publish/subscribe paradigm.

For example, suppose that on the 'cart updated' event I want a user
control to update the value for the number of items inside the cart
and I want another control to make sure that it doesn't show an
advertisement for a product already in the cart.

WPF has the command pattern, the Smart Client library has the publish
or subscribe paradigm so I'm curious if Boo has something 'out of the
box' for this.

I find that decoupling actions through global events is a lot easier
when building a responsive UI.

I think Boo doesn't have such support but I could extend it to add
some keywords inside a class to handle the auto-wiring, correct?

GlobalSubscriptions:
  CartUpdated += UpdateTotal


Thanks for any leads

Phil

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang?hl=en
-~----------~----~----~----~------~----~------~--~---

[Cedric Vivier]

Hey Phil,

On Tue, Sep 8, 2009 at 9:32 PM, Philosophil <philippe.lavoie@...> wrote:

I'm curious to know if Boo has a built-in approach to handle global
events through a global publish/subscribe paradigm.
(...)
WPF has the command pattern, the Smart Client library has the publish
or subscribe paradigm so I'm curious if Boo has something 'out of the
box' for this.

.NET has an event system that sounds similar to what you want.
I think you just want to declare events in a static class (possibly with some setup in the static constructor).
See http://boo.codehaus.org/Events

Cheers,

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang?hl=en
-~----------~----~----~----~------~----~------~--~---

[Philosophil]

The publish subscribe model is different than this. In that model, you
defined your 'payload' and then tell the system that you want to be
notified when that event occurs and you also tell it when you want to
raise that event. i.e. in C#

public class ApplyFilterToImageEvent:
CompositePresentationEvent<IImageFilter> { }


public class PhotoViewer
{

   PhotoViewer ()
   {
         _eventAggregator =
ServiceLocator.Current.GetInstance<IEventAggregator>();
          ApplyFilterToImageEvent filterEvent =
_eventAggregator.Get<ApplyFilterToImageEvent>();
          filterEvent.Subscribe(UpdateView);
   }

   void UpdateView(IImageFilter filter)
   {
        _image.ApplyFilter(filter);
        InvalidateVisual();
   }
}


public class FilterSelection()
{
     public void ApplyFilter(object sender, ButtonEvent e)
     {
          MeanFilter filter = new MeanFilter();
          _eventAggregator.Get<ApplyFilterEvent>().Publish(filter);
     }
}


Things to notice in the above code, the service locator allows us to
fetch the appropriate event aggregator, i.e. based on dynamic criteria
or configuration or compile time .
There isn't a single point of definition, i.e. events are independant
classes which define the type of payload they accept.
Wiring is made inside the class itself, this simplifies development.
Arguably, I can also check a configuraiton value somewhere to know if
I should actually hook-up with the event. However it would be more
appropriate for the eventAggregator to reject a 'subscribe' request
than to add complexity in the client class.

I know the above can be done in C# and Boo i.e. I'm doing it right
now :). I was just curious from a language perspective if Boo offered
new facilities regarding this pattern that could make this even more
simple. In particular, automating the 'unsubscribe' aspect when an
object is out of scope would be very nice since events are a notorious
source of memork leaks when you use a lot of short time to live
objects. Adding a IDisposable to every class that registers itself is
cumbersome. It's doable but cumbersome nonetheless.

Cheers

phil

On Sep 8, 9:52 am, Cedric Vivier <cedr...@...> wrote:

> Hey Phil,
>
> On Tue, Sep 8, 2009 at 9:32 PM, Philosophil <philippe.lav...@...>wrote:
>
> > I'm curious to know if Boo has a built-in approach to handle global
> > events through a global publish/subscribe paradigm.
> > (...)
> > WPF has the command pattern, the Smart Client library has the publish
> > or subscribe paradigm so I'm curious if Boo has something 'out of the
> > box' for this.
>
> .NET has an event system that sounds similar to what you want.
> I think you just want to declare events in a static class (possibly with
> some setup in the static constructor).
> Seehttp://boo.codehaus.org/Events
>
> Cheers,

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang?hl=en
-~----------~----~----~----~------~----~------~--~---

[Justin Chase-2]

In .net 4 (which I assume Boo will upgrade to reasonably shortly after it RTMs) has IObservable, which sounds exactly like what you're talking about here.

This:

http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html

is an excellent article on the subject. There is also a video on Channel 9 about it with more details:

http://channel9.msdn.com/shows/Going+Deep/Kim-Hamilton-and-Wes-Dyer-Inside-NET-Rx-and-IObservableIObserver-in-the-BCL-VS-2010/

I could definitely foresee some boo macros to make this clean (any design pattern is a great candidate for a macro really). And actually it's not a whole heck of a lot different than just standard generators in boo I guess, except, perhaps, more broadly applicable.

On Tue, Sep 8, 2009 at 9:39 AM, Philosophil <philippe.lavoie@...> wrote:

The publish subscribe model is different than this. In that model, you
defined your 'payload' and then tell the system that you want to be
notified when that event occurs and you also tell it when you want to
raise that event. i.e. in C#

public class ApplyFilterToImageEvent:
CompositePresentationEvent<IImageFilter> { }


public class PhotoViewer
{

  PhotoViewer ()
  {
        _eventAggregator =
ServiceLocator.Current.GetInstance<IEventAggregator>();
         ApplyFilterToImageEvent filterEvent =
_eventAggregator.Get<ApplyFilterToImageEvent>();
         filterEvent.Subscribe(UpdateView);
  }

  void UpdateView(IImageFilter filter)
  {
       _image.ApplyFilter(filter);
       InvalidateVisual();
  }
}


public class FilterSelection()
{
    public void ApplyFilter(object sender, ButtonEvent e)
    {
         MeanFilter filter = new MeanFilter();
         _eventAggregator.Get<ApplyFilterEvent>().Publish(filter);
    }
}


Things to notice in the above code, the service locator allows us to
fetch the appropriate event aggregator, i.e. based on dynamic criteria
or configuration or compile time .
There isn't a single point of definition, i.e. events are independant
classes which define the type of payload they accept.
Wiring is made inside the class itself, this simplifies development.
Arguably, I can also check a configuraiton value somewhere to know if
I should actually hook-up with the event. However it would be more
appropriate for the eventAggregator to reject a 'subscribe' request
than to add complexity in the client class.

I know the above can be done in C# and Boo i.e. I'm doing it right
now :). I was just curious from a language perspective if Boo offered
new facilities regarding this pattern that could make this even more
simple. In particular, automating the 'unsubscribe' aspect when an
object is out of scope would be very nice since events are a notorious
source of memork leaks when you use a lot of short time to live
objects. Adding a IDisposable to every class that registers itself is
cumbersome. It's doable but cumbersome nonetheless.

Cheers

phil

On Sep 8, 9:52 am, Cedric Vivier <cedr...@...> wrote:
> Hey Phil,
>

> On Tue, Sep 8, 2009 at 9:32 PM, Philosophil <philippe.lav...@...>wrote:

>
> > I'm curious to know if Boo has a built-in approach to handle global
> > events through a global publish/subscribe paradigm.
> > (...)
> > WPF has the command pattern, the Smart Client library has the publish
> > or subscribe paradigm so I'm curious if Boo has something 'out of the
> > box' for this.
>
> .NET has an event system that sounds similar to what you want.
> I think you just want to declare events in a static class (possibly with
> some setup in the static constructor).

> Seehttp://boo.codehaus.org/Events

>
> Cheers,

--
Justin Chase
http://www.justnbusiness.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang?hl=en
-~----------~----~----~----~------~----~------~--~---

[Philosophil]

This Rx stuff seems very interesting.

Phil

On Tue, Sep 8, 2009 at 10:59 AM, Justin Chase<justin.m.chase@...> wrote:

> In .net 4 (which I assume Boo will upgrade to reasonably shortly after it
> RTMs) has IObservable, which sounds exactly like what you're talking about
> here.
> This:
> http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html
> is an excellent article on the subject. There is also a video on Channel 9
> about it with more details:
> http://channel9.msdn.com/shows/Going+Deep/Kim-Hamilton-and-Wes-Dyer-Inside-NET-Rx-and-IObservableIObserver-in-the-BCL-VS-2010/
> I could definitely foresee some boo macros to make this clean (any design
> pattern is a great candidate for a macro really). And actually it's not a
> whole heck of a lot different than just standard generators in boo I guess,
> except, perhaps, more broadly applicable.
>
> On Tue, Sep 8, 2009 at 9:39 AM, Philosophil <philippe.lavoie@...>
> wrote:
>>
>> The publish subscribe model is different than this. In that model, you
>> defined your 'payload' and then tell the system that you want to be
>> notified when that event occurs and you also tell it when you want to
>> raise that event. i.e. in C#
>>
>> public class ApplyFilterToImageEvent:
>> CompositePresentationEvent<IImageFilter> { }
>>
>>
>> public class PhotoViewer
>> {
>>
>>   PhotoViewer ()
>>   {
>>         _eventAggregator =
>> ServiceLocator.Current.GetInstance<IEventAggregator>();
>>          ApplyFilterToImageEvent filterEvent =
>> _eventAggregator.Get<ApplyFilterToImageEvent>();
>>          filterEvent.Subscribe(UpdateView);
>>   }
>>
>>   void UpdateView(IImageFilter filter)
>>   {
>>        _image.ApplyFilter(filter);
>>        InvalidateVisual();
>>   }
>> }
>>
>>
>> public class FilterSelection()
>> {
>>     public void ApplyFilter(object sender, ButtonEvent e)
>>     {
>>          MeanFilter filter = new MeanFilter();
>>          _eventAggregator.Get<ApplyFilterEvent>().Publish(filter);
>>     }
>> }
>>
>>
>> Things to notice in the above code, the service locator allows us to
>> fetch the appropriate event aggregator, i.e. based on dynamic criteria
>> or configuration or compile time .
>> There isn't a single point of definition, i.e. events are independant
>> classes which define the type of payload they accept.
>> Wiring is made inside the class itself, this simplifies development.
>> Arguably, I can also check a configuraiton value somewhere to know if
>> I should actually hook-up with the event. However it would be more
>> appropriate for the eventAggregator to reject a 'subscribe' request
>> than to add complexity in the client class.
>>
>> I know the above can be done in C# and Boo i.e. I'm doing it right
>> now :). I was just curious from a language perspective if Boo offered
>> new facilities regarding this pattern that could make this even more
>> simple. In particular, automating the 'unsubscribe' aspect when an
>> object is out of scope would be very nice since events are a notorious
>> source of memork leaks when you use a lot of short time to live
>> objects. Adding a IDisposable to every class that registers itself is
>> cumbersome. It's doable but cumbersome nonetheless.
>>
>> Cheers
>>
>> phil
>>
>> On Sep 8, 9:52 am, Cedric Vivier <cedr...@...> wrote:
>> > Hey Phil,
>> >
>> > On Tue, Sep 8, 2009 at 9:32 PM, Philosophil
>> > <philippe.lav...@...>wrote:
>> >
>> > > I'm curious to know if Boo has a built-in approach to handle global
>> > > events through a global publish/subscribe paradigm.
>> > > (...)
>> > > WPF has the command pattern, the Smart Client library has the publish
>> > > or subscribe paradigm so I'm curious if Boo has something 'out of the
>> > > box' for this.
>> >
>> > .NET has an event system that sounds similar to what you want.
>> > I think you just want to declare events in a static class (possibly with
>> > some setup in the static constructor).
>> > Seehttp://boo.codehaus.org/Events
>> >
>> > Cheers,
>>
>
>
>
> --
> Justin Chase
> http://www.justnbusiness.com
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Boo Programming Language" group.
To post to this group, send email to boolang@...
To unsubscribe from this group, send email to boolang+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/boolang?hl=en
-~----------~----~----~----~------~----~------~--~---