We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 40358
    • 40 Posts
    I consider myself a pretty good PHP programmer, with around 10 years of experience. However, there are a few aspects of OOP programming and the way Modx is structured that I just don't get.

    First, why does the processors return the name of the class in each file? For example in this file: https://github.com/modxcms/revolution/blob/develop/core/model/modx/processors/resource/data.class.php. What is the purpose of this?

    Second, how does Modx include/require the different files needed to get things running? Looking at the link posted in the first question, the class extends modProcessor. How/where/when does Modx include all of these dependencies? I see the loadClass is called here and there, and I assume that method simply does a include/require for that class, but I can't see any place where all these dependencies are included.
    • To be honest, I can't rationalize the processor name—that was a decision by an individual developer, likely made to get around the fact that the MODX architecture was not built on what are by now well-established autoloading standards.

      A lot of the class loading is done by the xPDO::loadClass() method, though the original intention of this was simply to be able to load platform specific classes within xPDO models. Again, this pre-dated modern PHP autoloading standards and the result is generally a mix of custom class loading via loadClass() and various include(_once)/require(_once) usages.

      That said, this is absolutely one of the primary architectural goals for the next major release of MODX. We must adopt already accepted—and remain flexible enough to quickly adopt emerging—PHP standards that will allow MODX developers to make use of modern coding techniques, follow the sage advice at PHP The Right Way, and avoid hours of learning proprietary APIs and packaging techniques in order to develop anything. Autoloading, logging, dependency management and other "core" features in the next major MODX release should reflect the same level of creative freedom for back-end developers it already strongly conveys to front-end developers. IMO, this milestone must be attained to gain enough momentum to reach critical mass in forging a sustainable MODX developer ecosystem.
        • 40358
        • 40 Posts
        Thanks for your reply, opengeek smiley

        However, I still don't understand how (or where) the returned processor name is actually used, what the purpose is.
        • The runProcessor() method just utilizes it to get the name of the processor class when the class is loaded, AFAIK.
            • 40358
            • 40 Posts
            I had no idea you could store return content in a variable while doing a require/include. That makes many things a lot easier.

            Thanks for answering once again smiley
              • 3749
              • 24,544 Posts
              Quote from: optimuscrime at Jun 15, 2014, 06:39 PM
              I had no idea you could store return content in a variable while doing a require/include.

              It can be really handy. It's done often in transport package build files which return an array of objects that are then added to a vehicle.
                Did I help you? Buy me a beer
                Get my Book: MODX:The Official Guide
                MODX info for everyone: http://bobsguides.com/modx.html
                My MODX Extras
                Bob's Guides is now hosted at A2 MODX Hosting