wip: dsa-directory

[ChaiWithJai]

No description provided.

[donrestarone]

This is a great one-shot example that captures the spirit of building/automating on top of Violet. However the pattern applied in organizing the code isn't correct. So lets fix that,

Here's an example of a 'full stack' Plugin that implements a Printify E-commerce Shop with Stripe checkout: https://github.com/restarone/violet_rails/blob/master/plugins/installers/printify_stripe_e_commerce.rb and its corresponding test suite: https://github.com/restarone/violet_rails/blob/master/test/plugins/installers/printify_stripe_e_commerce_test.rb

Naturally, Plugins don't need to be 'full stack', they can also be 'backend only' for example, BishopTlsMonitoring is a Violet External API Connection that is essentially a PORO that implements an SSL check that is invoked by the Violet External API Connection Code Executor on a cron basis. Here's BishopTlsMonitoring: https://github.com/restarone/violet_rails/blob/master/test/plugin_fixtures/bishop_tls_monitoring.yml and its test file: https://github.com/restarone/violet_rails/blob/master/test/plugins/bishop_tls_monitoring_plugin_test.rb

A final note on Plugins-- they can also be barebones API Namespaces which implement a data layer, but leaves everything else up to the developer (like what to do when Actions fire on lifecycle events). An example of this is Subdomain Events V1: https://github.com/restarone/violet_rails/wiki/API-Namespace-plugin:-subdomain-events-V1 -- which is a lightweight Plugin that fires various Actions based on Subdomain Events (new email received, new forum thread created etc).

In case you want to bundle a plugin with the core framework, you can do so via a migration like this: https://github.com/restarone/violet_rails/blob/master/db/migrate/20220420153229_add_plugin_subdomain_events_to_api.rb -- which scaffolds the plugin in every existing and newly created Subdomain.

Hope this helps with the Claude Skill development!