in reply to Re: Allowing Plugins
in thread Allowing Plugins

> Also, you've got code (plugins) that are really configuration items (who can login, etc). Don't conflate behaviors (code) with input (data).

I guess I was unclear. The reconciliation program figures out that a person should be able to login (because of the import flags). The plugin is given a person and told that this person either gets to login, or doesn't. The plugins are designed not to need any knowledge of which queries guarantee the permission, just that this record needs it.

Replies are listed 'Best First'.
Re^3: Allowing Plugins
by dragonchild (Archbishop) on Feb 25, 2008 at 19:22 UTC
    The plugin is given a person and told that this person either gets to login, or doesn't. The plugins are designed not to need any knowledge of which queries guarantee the permission, just that this record needs it.

    So, what exactly is the plugin doing again that a class doesn't?


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      It is a class. I'm a bit confused (I'm pretty new to perl, hopefully plugin doesn't mean something more specific in perl) The plugins will inherit from a base plugin class and just override the methods. Is there an easier way to go through modules and see what classes have the same superclass? That'd do the trick.
        I'm confused as to why you are thinking so hard about this. Why wouldn't a allow_login() and disallow_login() method (or whatever) all within the same class suffice? From what I'm understanding, this is a one-off product that will do the translation once and you're done.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?