-
☆ A M B ☆
- 24,524 Posts
First of all you’ll need to get the terminology straightened out to avoid confusion.
Snippets are bits (not always small bits!) of PHP code for front-end dynamic behavior, similar to having <?php...?> tags in an HTML document. Wayfinder, for generating lists and menus, is a good example of a snippet. Any included or support files for snippets are stored in assets/snippets/snippetname.
Modules are extensions to the Manager, adding new features such as newsletter management. Included and support files for modules are stored in assets/modules/modulename.
Plugins are inserted code to modify processing at specific events, such as when a user logs in, or at certain points during the parsing of a document to generate a web page. Again, includes and support files are stored in assets/plugins/pluginname.
The latter two are used for adding or modifying core and Manager behavior without modifying the core scripts themselves.
-
☆ A M B ☆
- 24,524 Posts
For modules and plugins it really doesn’t matter if you include a configuration file or use the Configuration tab. Both ways the name/value pairs will be passed in to the application at run-time. Having them in the Configuration tab makes it a bit easier for users to configure them after installation.
For snippets, it’s a different matter. For example, take the Wayfinder snippet. You could use the Configuration tab to specify the startId for all instances of Wayfinder calls. But menus are generated at all different levels of websites, requiring different values for the startId, so a global setting like this doesn’t make a lot of sense. In this case, using parameters in the snippet’s tags for each individual call makes more sense. On the other hand, snippets like Wayfinder, Ditto and eForm can have very long parameter lists. So it makes even more sense to just have one or two parameters in the snippet tags, and have one of those parameters specify a config file, where all the other settings are defined with simple PHP variable definitions. You can even have the templates for their various elements defined in the config file instead of using chunks, thus saving some database activity as well as saving space in the site cache file.
-
☆ A M B ☆
- 24,524 Posts
If you look at the file manger/includes/document.parser.class.inc.php, you’ll see that this is the main parser script for generating web pages out of templates, snippets, chunks, template variables and documents. If you do a search for "invokeEvent", you’ll see a number of these events sprinkled through the code. They also exist in the manager/action files, as well as the manager/processor files. Plugins can intercept these "events" and add their own code to modify whatever process is going on, without having to modify the original script code.
For example, I’m researching LDAP with the thought of adding LDAP compatibility layer to MODx. I will need to use events involving creating new users, validating users, in fact anything having to do with users, in order to insert the code to add the user data to the LDAP database, and to validate the user against the LDAP database, while still having all of the MODx user management functionality. I’ll have a plugin that "listens" for several of these events in the user management scripts and does whatever necessary with the LDAP database, then returns processing to the MODx script where it left off, perhaps with a couple of extra variables assigned for it to work with.
If you’ve ever worked with a program like CubeCart, and all of its "mods", you’ll know what I mean. Having to hack the core code to add or modify functionality is a nightmare. Pretty soon you’ve got hacks of hacks, then there’s a major security update and you’re SOL because you don’t even remember which hacks went where!
Snippets can also use this feature. A commonly used case of a snippet with events is the eForm snippet. It is a basic form validation and mailing script, originally intended for contact forms, that sort of got out of hand. Now it has several events where you can add your own functions to add more validation, get data from a database to fill a select drop-down field for the initial form generation, save form POST data to a file or the database, or modify the data before it gets mailed off, or just about anything else you can think of to do with a form. All this, with no need to hack the original eForm code. In this case, instead of using plugins, you use a snippet to define your function and make sure the snippet is called before the eForm snippet, so the function will be available.
The TreasureChest ecommerce module/snippet combination that ScottyDelicious is working on uses events, but he’s registered them in the database along with the other MODx script’s events, so you can use plugins with it. All that means is that the TreasureChest installer adds the events to the system_events table in the database. Then they’ll show up on the plugin form’s System Events tab, and the parser will insert the code at the appropriate point in the script’s processing.
Susan, thank-you for the time you take to explain all that information. It’s really helpful
