Well, I wrote the Auditor module as a module because :-
It doesn’t depend on any triggering events, i.e. its not a plugin.
It needs to be accessible from within the manager only, as an add-on to the manager itself, not in a snippet that needs to be run from a page etc.
It’s invoked when you press the Auditor menu item in the Modules section, i.e. each module runs when you invoke it from the modules menu.
It first sets up path data, checks perms then displays the current state of the Auditor system, subsequent key presses are directed back to the module code by MODx, so you end up with a case statement of ’isset’s deciding what internal function has been invoked.
Does this help a bit, looking at existing module code should help also.
Use MODx, or the cat gets it!
-
☆ A M B ☆
- 2,475 Posts
Ok, to summarize:
Write a Snippet if your code needs to execute when a page loads on the front-end. Example: displaying current date/time to user.
Write a Plug-in if your code needs to execute when certain system events occur. Example: special action when a web-user logs in (OnWebLogin event)
Write a Module if your code only needs to be accessible within the manager control panel. It is executed on an "as-needed" basis. Example: CRUD access to custom database table.
Is that too overly simple?
Is that too overly simple?
I think it summarizes nicely.
Use MODx, or the cat gets it!
-
☆ A M B ☆
- 2,475 Posts
Ah... thanks. That explains some weird behavior I saw. I guess to be thorough, I should have looked at what was actually being written to the database.