Comments (10)
So you want to put condition and action into the single object with predefined DSL? Your example misses target object class, condition and event, where should they be according to your proposal?
from triggerable.
class SendWelcomeSms < Triggerable::Actions::Action
def run_for?(object, trigger_name)
return object.receives_sms.is_a?(::TrueClass)
end
def run_for! object, trigger_name
SmsGateway.send_to object.phone, welcome_text
end
end
class User
trigger on: :after_create, do: :send_welcome_sms
end
But again it looks weird because for each action need to create separate class. And what the difference between observers?
from triggerable.
Rails observers are deprecated and they can't help you to do the thing I call "automations" (scheduled actions for records which satisfy some conditions)
from triggerable.
Without integrations into Resque, Sidekiq or DelayedJob it not usable. Did you tested this automation in multi-thread environments? I suppose not.
from triggerable.
I'm just running Triggerable::Engine.run_automations
using whenever schedule, fits my needs for now
from triggerable.
Hm... But it's too expensive. For each cron task you loading whole rails environment. And on environments like Heroku need to pay additional cost for such processes.
from triggerable.
Yes, but it's a single cron task (all automations are being executed in the same environment).
from triggerable.
I see the benefit of DSL language is that you can use one action for several different conditions/model classes. If you put condition in class it will be impossible.
I think to run automations correctly you should just be sure that run_automations
thread is single. I think using Clockwork for such case is good.
from triggerable.
@anfinil I don't see any benefits of if: { or: [{ field1: '1' }, { field2: 1 }, and: {field3: '1', field4: '1'}] }
. It looks weird for complex cases.
from triggerable.
Of course long conditions looks weird but they also will look weird in separate classes. :-)
We are using triggerable in production and we don't have very complex conditions. If you want to use complex condition in trigger you could always incapsulate it model function.
Triggerable gem was inspired by Zendesk triggers/automations and it is good to have:
- 'Specification' of business logic in one place (we have separate folder for all triggers/automations)
- UI editor for updating triggers/automation conditions. Because using DSL and list of predefined actions you can load triggers/automations from database.
from triggerable.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from triggerable.