Quote from: sottwell at Apr 13, 2007, 01:11 PM
And also consider the difference between a snippet (to display stuff on the front-end) and a plugin (to modify the parsing process). A plugin may well need to use the "internal" functions and variables, such as the documentObject, because it is actually modifying the actions of the parser.
Actually, what you are describing is antithetical to the purpose of an API; though I agree that plugins can modify the parsing process, doing so should still be done through a prescribed, formal API. The fact is the getDocumentObject function should never be called by anything other than the core MODx engine itself. The documentObject variable it produces is public and available to plugins and other add-ons, but by definition, these not-so-clearly labeled "private" functions such as getDocumentObject(), mergeSnippetContent(), or cleanDocumentIdentifier() (just to name a few) should never be called by any add-on, snippet, plugin, module, or otherwise. Code that currently does this (and there are many examples), will need to be rewritten for future compatibility.
As for modifying actions of the parser by calling these internal functions, though possibly necessary to accomplish some more advanced features in the current codebase, this is simply a work-around and necessary evil for the time being. There are much better ways to override core functionality without risking upgrade paths. Unfortunately, these internal functions must be allowed to evolve with the changes to the core engine, or progress will become virtually impossible. As we will see when 0.9.7 becomes available, providing a custom parser class to override or provide new functionality is going to become not only possible, but very easy to do. This will become the preferred approach to extending or customizing the MODx parser, as well as many other parts of the core (i.e. session handling, error handling, etc).
MODX Staff
☆ A M B ☆
