Automatically running additional code (hook? Callback?)

Hi Everyone,

I'm having trouble describing exactly what I'm searching for (if I could, a google search would be easier too), so let me explain.

We want to have a generic class to implement monitors. The idea is that a monitor checks the status of a value and if it is in error, it triggers an action: maybe, an alert or an email.

Ideally, I want to be able to do something like this:

class UpdatesMonitor < OurMainMonitorClass
def monitor
# actually tests the conditions, etc.
end
end

But when it finishes running, I want the system to be able to automatically manage the running of the alerting functions without needing the programmer to add any additional code for it. I guess the parallel is a bit like something in how a controller action in Rails seems to only have the specific method's logic and then the view gets rendered.

I know how we can use ActionMailer outside Rails[1] and want that to be the next step, integrating an ERB view template, etc. for the update emails.

What is the correct thing in Ruby that I am looking for? Any help is much appreciated.

[1] Using ActionMailer outside Rails

Best Regards,
Mohit.
2022-5-9 | 6:07 pm.

What you’re describing is the classical Observer Design Pattern:

A famous Ruby library for observers is Wisper:

Observer can automatically do the alerting as soon as their observable
condition is satisfied. For example, an object status attribute writer
calls the observer after it is done updating the status.

Feel free to ask more questions or provide more clarifications for your
requirements if you need to.

Andy

Andy

···

On Mon, May 9, 2022 at 6:10 AM Mohit Sindhwani <mo_mail@onghu.com> wrote:

Hi Everyone,

I'm having trouble describing exactly what I'm searching for (if I
could, a google search would be easier too), so let me explain.

We want to have a generic class to implement monitors. The idea is that
a monitor checks the status of a value and if it is in error, it
triggers an action: maybe, an alert or an email.

Ideally, I want to be able to do something like this:

class UpdatesMonitor < OurMainMonitorClass
   def monitor
     # actually tests the conditions, etc.
   end
end

But when it finishes running, I want the system to be able to
automatically manage the running of the alerting functions without
needing the programmer to add any additional code for it. I guess the
parallel is a bit like something in how a controller action in Rails
seems to only have the specific method's logic and then the view gets
rendered.

I know how we can use ActionMailer outside Rails[1] and want that to be
the next step, integrating an ERB view template, etc. for the update
emails.

What is the correct thing in Ruby that I am looking for? Any help is
much appreciated.

[1] Using ActionMailer outside Rails

Best Regards,
Mohit.
2022-5-9 | 6:07 pm.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<ruby-talk list: member options login page>

By the way, I tend to avoid the term "callbacks" whenever possible since
it's very vague and not considered object-oriented. In fact, I've blogged
about this a while ago:

···

On Mon, May 9, 2022 at 9:12 AM Andy Maleh <andy.am@gmail.com> wrote:

What you’re describing is the classical Observer Design Pattern:
Observer pattern - Wikipedia

A famous Ruby library for observers is Wisper:
GitHub - krisleech/wisper: A micro library providing Ruby objects with Publish-Subscribe capabilities

Observer can automatically do the alerting as soon as their observable
condition is satisfied. For example, an object status attribute writer
calls the observer after it is done updating the status.

Feel free to ask more questions or provide more clarifications for your
requirements if you need to.

Andy

Andy

On Mon, May 9, 2022 at 6:10 AM Mohit Sindhwani <mo_mail@onghu.com> wrote:

Hi Everyone,

I'm having trouble describing exactly what I'm searching for (if I
could, a google search would be easier too), so let me explain.

We want to have a generic class to implement monitors. The idea is that
a monitor checks the status of a value and if it is in error, it
triggers an action: maybe, an alert or an email.

Ideally, I want to be able to do something like this:

class UpdatesMonitor < OurMainMonitorClass
   def monitor
     # actually tests the conditions, etc.
   end
end

But when it finishes running, I want the system to be able to
automatically manage the running of the alerting functions without
needing the programmer to add any additional code for it. I guess the
parallel is a bit like something in how a controller action in Rails
seems to only have the specific method's logic and then the view gets
rendered.

I know how we can use ActionMailer outside Rails[1] and want that to be
the next step, integrating an ERB view template, etc. for the update
emails.

What is the correct thing in Ruby that I am looking for? Any help is
much appreciated.

[1] Using ActionMailer outside Rails

Best Regards,
Mohit.
2022-5-9 | 6:07 pm.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<ruby-talk list: member options login page>

--
Andy Maleh

LinkedIn: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh>
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub

For a functional solution you can use a Hash with Procs and use each status
as a key . But I recommend the OOP solution too.

···

Em seg., 9 de mai. de 2022 às 07:10, Mohit Sindhwani <mo_mail@onghu.com> escreveu:

Hi Everyone,

I'm having trouble describing exactly what I'm searching for (if I
could, a google search would be easier too), so let me explain.

We want to have a generic class to implement monitors. The idea is that
a monitor checks the status of a value and if it is in error, it
triggers an action: maybe, an alert or an email.

Ideally, I want to be able to do something like this:

class UpdatesMonitor < OurMainMonitorClass
   def monitor
     # actually tests the conditions, etc.
   end
end

But when it finishes running, I want the system to be able to
automatically manage the running of the alerting functions without
needing the programmer to add any additional code for it. I guess the
parallel is a bit like something in how a controller action in Rails
seems to only have the specific method's logic and then the view gets
rendered.

I know how we can use ActionMailer outside Rails[1] and want that to be
the next step, integrating an ERB view template, etc. for the update
emails.

What is the correct thing in Ruby that I am looking for? Any help is
much appreciated.

[1] Using ActionMailer outside Rails

Best Regards,
Mohit.
2022-5-9 | 6:07 pm.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<ruby-talk list: member options login page>

--
Fellipe Fingoli

Hi Andy,

Thanks!

By the way, I tend to avoid the term "callbacks" whenever possible since it's very vague and not considered object-oriented. In fact, I've blogged about this a while ago:

Code Master Blog: Callbacks

Yes, I have been struggling with the correct term to be able to search what I need.

    What you’re describing is the classical Observer Design Pattern:
    Observer pattern - Wikipedia

    A famous Ruby library for observers is Wisper:
    GitHub - krisleech/wisper: A micro library providing Ruby objects with Publish-Subscribe capabilities

    Observer can automatically do the alerting as soon as their
    observable condition is satisfied. For example, an object status
    attribute writer calls the observer after it is done updating the
    status.

Yes, this might be what I need - let me read more. I'm basically looking at a mechanism similar to how controller actions in Rails result in the view being rendered... but yes, let me start here.

    Feel free to ask more questions or provide more clarifications for
    your requirements if you need to.

Thanks for the reply. Of course, I am mainly looking at seeing what I should read to get closer to the idea - and not being able to search was a major impediment.

Best Regards,
Mohit.

···

On 2022-5-9 9:20 pm, Andy Maleh wrote:

On Mon, May 9, 2022 at 9:12 AM Andy Maleh <andy.am@gmail.com> wrote:

Thanks Fellipe!

For a functional solution you can use a Hash with Procs and use each status as a key . But I recommend the OOP solution too.

    Hi Everyone,

    I'm having trouble describing exactly what I'm searching for (if I
    could, a google search would be easier too), so let me explain.

<snip>

I think my example of using monitors might have thrown us off a bit but let me see what the others have told me to see if that moves me forward. In short, I'm keen to have functions like after_execute, before_execute (and the Rails callbacks seemed like the correct model).

Best Regards,
Mohit.
2022-5-9 | 9:57 pm.

···

On 2022-5-9 9:39 pm, Fellipe Fingoli wrote:

Em seg., 9 de mai. de 2022 às 07:10, Mohit Sindhwani > <mo_mail@onghu.com> escreveu:

Mohit, thanks for clarifying your needs further.

I'm basically looking at a mechanism similar to how controller actions in

Rails result in the view being rendered

This is actually known as the "Controller Pattern" under the OOP GRASP
Patterns (General Responsibility Assignment Software Patterns), which can
be applied outside of MVC for any purpose (e.g. in the use of command line
tools like Thor or Rake):

I'm keen to have functions like after_execute, before_execute

These are unfortunately misnamed in Rails. The use of such methods is
actually part of the "Template Method Design Pattern":

A "template method" usually lives in an abstract superclass as a template
for executing some common reusable code while calling "hook methods"
before/after/around/between the main code. Subclasses may then override the
"hook methods" only to customize their behavior while keeping the "template
method" reusable common code the same. There are variations on the
"Template Method Design Pattern" that allow overriding the "template
method" too, but commonly only "hook methods" are overridden.

That should offer you quite a few terms to lookup on Google. I hope that
helps!

Andy

···

On Mon, May 9, 2022 at 9:58 AM Mohit Sindhwani <mo_mail@onghu.com> wrote:

Thanks Fellipe!

On 2022-5-9 9:39 pm, Fellipe Fingoli wrote:

For a functional solution you can use a Hash with Procs and use each
status as a key . But I recommend the OOP solution too.

Em seg., 9 de mai. de 2022 às 07:10, Mohit Sindhwani <mo_mail@onghu.com> > escreveu:

Hi Everyone,

I'm having trouble describing exactly what I'm searching for (if I
could, a google search would be easier too), so let me explain.

<snip>

I think my example of using monitors might have thrown us off a bit but
let me see what the others have told me to see if that moves me forward. In
short, I'm keen to have functions like after_execute, before_execute (and
the Rails callbacks seemed like the correct model).

Best Regards,
Mohit.
2022-5-9 | 9:57 pm.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<ruby-talk list: member options login page>

--
Andy Maleh

LinkedIn: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh>
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub

Hi Andy,

Thanks!

···

On 2022-5-9 11:45 pm, Andy Maleh wrote:

Mohit, thanks for clarifying your needs further.

> I'm basically looking at a mechanism similar to how controller actions in Rails result in the view being rendered

This is actually known as the "Controller Pattern" under the OOP GRASP Patterns (General Responsibility Assignment Software Patterns), which can be applied outside of MVC for any purpose (e.g. in the use of command line tools like Thor or Rake):
GRASP (object-oriented design) - Wikipedia

> I'm keen to have functions like after_execute, before_execute

These are unfortunately misnamed in Rails. The use of such methods is actually part of the "Template Method Design Pattern":
Template method pattern - Wikipedia

A "template method" usually lives in an abstract superclass as a template for executing some common reusable code while calling "hook methods" before/after/around/between the main code. Subclasses may then override the "hook methods" only to customize their behavior while keeping the "template method" reusable common code the same. There are variations on the "Template Method Design Pattern" that allow overriding the "template method" too, but commonly only "hook methods" are overridden.

That should offer you quite a few terms to lookup on Google. I hope that helps!

Yes, you seem to have got the correct words for me to look at.

Best Regards,
Mohit.
2022-5-10 | 4:15 pm.