We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22303 MODX Staff
    • 10,725 Posts
    Quote from: TobyL at Feb 06, 2009, 01:23 AM

    Jason, how would you load this as an extension in 0.9.6? The DocumentParser does have a loadExtension() method but it can only load DBAPI and managerAPI.
    Oh, my bad, thought it was meant to load any extension. TBH, I forget how 0.9.6. does a lot of things; I’m already working on 2.1 in my head and making sure I know how it’s all gonna work. tongue

    Quote from: TobyL at Feb 06, 2009, 01:23 AM

    I can imagine using a plugin triggered by the onWebPageInit to load the mollum class (and provide a global instance if necessary), but beyond that I don’t see how to make it an extension of the modx object. Or am I misunderstanding?
    Sure, that is absolutely just as valid; you could even store the instantiated object as a placeholder if you wanted to share it across multiple components in a single request.

    Quote from: TobyL at Feb 06, 2009, 08:14 AM

    I’m trying to get my head around this. You basically want to make a third party service add-on that is then easily made available to other add-ons am I correct? I don’t see what the difficulty is for developers of those other add-ons to simply check if the particular add-on exists, include it , create an instance of it and use it in the same way you would for instance use PHPmailer or any other third party product.
    I agree with Toby on this one; this just doesn’t make sense to me using an arbitrary event; folks would have to then learn how to invoke the events in addition to registering plugins on them to do something. It’s much easier to me to simply write a little PHP class and in a plugin or snippet get an instance of the object I want and simply calls it’s functions.
      • 3749
      • 24,544 Posts
      Quote from: TobyL at Feb 06, 2009, 08:14 AM

      In the front end, though, there’s really no common event that occurs before saving or emailing user content, but it would be easy for developers to invoke one when processing user input if it existed.

      Now you are getting me confused smiley The front end does not save anything and does not email anything and when in the core does it process front-end user input? So where would you have that event triggered? Isn’t it the snippets or plugins that do most of the processing, saving and emailing?

      Yes, the snippets that do the processing, saving, and emailing would trigger the event and I’d argue that, in that case, the saving, emailing, etc. is happening in the front end.  The event would then be handled in various possible plugins listening for that event.

      I guess I haven’t been clear on where I’m coming from. Looking at the list of MODx System Events, there is an event for almost everything that can "happen" in the MODx front end or back end. It’s one of the main things that makes MODx so extensible without hacking the core.  One event that "happens" is that a front-end user submits content that needs to be analyzed or modified before further use (emailing, saving to DB, saving to disk, etc.). There’s no system event for that event. It seemed like an omission to me and I can imagine lots of uses for it.  They could all be implemented without a system event, but that could be said for many of the things that currently use system events (e.g. captcha). To me, a web user submitting content is conceptually the same as a web user logging in (in fact the second is a subset of the first, IMHO).

      I’m fine with having Mollom be a service and I can see that it might work better as a service. I just wanted to clarify my ideas on the potential system event.

      I guess I’m also confused about which "services" should be services and which should be plugins (e.g. why is Captcha a plugin rather than a service -- isn’t it providing basically the same kind of functionality that Mollom does?).

      WebLoginPE, BTW, creates three system events if they’re not already there: ’OnBeforeWebSaveUser’, ’OnBeforeAddToGroup’, ’OnViewUserProfile’, so I’m not the only one thinking the front end could user more System Events.  wink

        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
        • 22303 MODX Staff
        • 10,725 Posts
        What you are talking about is not a System Event really, but you can add custom events to that table for a custom component, similar to how WebLoginPE does. I’m not sure if these shows up in the plugin interface however, and dependency on custom events would be up to the components that use it.

        Regardless, components that make use of the Mollum service class can wrap it however they want to. I’d prefer simply using the Mollum object in a form processing snippet (or set of them) on the front-end or a plugin registered to existing events on the back-end. You may want to create a set of Ajax service wrappers for each Mollum function. Someone else may want to use it to check content published by managers, or using plain HTML form posts. This is the beauty of web services and providing it as a reusable class provides everyone the flexibility to use it how they want to, rather than how MODx prescribes.
          • 3749
          • 24,544 Posts
          Fair enough (still wondering, though, why Captcha is a plugin rather than a service since all the same arguments apply there, no?-- I’m sure there’s a good reason, I just can’t see it).

          Just a few questions:

          How do I instantiate a new XML-RPC client?

          Is there an advantage to using the jsonrpc subclasses for it as we do with regard in the modTransportProvider class?

          Are there guidelines somewhere for creating a MODx service?
            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
            • 22303 MODX Staff
            • 10,725 Posts
            Quote from: BobRay at Feb 06, 2009, 01:35 PM

            (still wondering, though, why Captcha is a plugin rather than a service since all the same arguments apply there, no?-- I’m sure there’s a good reason, I just can’t see it).
            Because I didn’t implement it? tongue But seriously, I can’t see it either -- I would agree that a Captcha implementation could and should be a reusable "service" class.

            Quote from: BobRay at Feb 06, 2009, 01:35 PM

            How do I instantiate a new XML-RPC client?
            I’d wrap the service client in something like this:
            <?php
            require_once MODX_CORE_PATH . 'model/modx/xmlrpc/xmlrpc.inc';
            require_once MODX_CORE_PATH . 'model/modx/xmlrpc/xmlrpc_wrappers.inc';
            
            class SampleService {
                var $modx;
                var $options;
                var $client;
                
                function SampleService(& $modx, $options = array()) {
                    $this->modx = & $modx;
                    $this->options = $options;
                }
                
                function &getServiceClient($url = '') {
                    if (empty($this->client)) {
                        $url = empty($url)
                            ? (!isset($options['url']) ? '' : $options['url'])
                            : $url;
                        if (empty($url)) {
                            $this->client = null;
                        } else {
                            $modx->loadClass('xmlrpc');
                            $this->client = new xmlrpc_client($url);
                        }
                    }
                    return $this->client;
                }
                
                function _callServiceMethod($method, $params = array()) {
                    $response = null;
                    if ($this->getServiceClient()) {
                        $msgParams = array();
                        foreach ($params as $param) $msgParams[] = new xmlrpcval($param);
                        $msg = new xmlrpcmsg($method, $msgParams);
                        $response = $this->client->send($msg);
                    }
                    return $response;
                }
                
                /* Add specific service methods to format complex parameters and/or transform the responses 
                   to make it easier for users to call specific business methods of the service */
            }
            
            
            /* Code to use it would be like...(though you would really want to call specific business methods) */
            if ($modx->getService('sample', 'SampleService', '', array('url' => 'http://localhost/some/service/url/'))) {
                $response = $modx->sample->_callServiceMethod('methodname', array('foo', 'bar', true));
                if (!$response->faultCode()) {
                    /* do something with the expected response */
                } else {
                    /* report an error */
                }
            }
            ?>


            Quote from: BobRay at Feb 06, 2009, 01:35 PM

            Is there an advantage to using the jsonrpc subclasses for it as we do with regard in the modTransportProvider class?
            For communicating with a service that was being implemented in the JSON-RPC protocol that would be useful; that’s what the default transport provider server implementation is, but ultimately, it could be implemented as a server accessed via any remote protocol (i.e. XML-RPC, JSON-RPC, SOAP, plain XML, plain JSON, or whatever) we implement the service as.

            In this case, it is an existing XML-RPC web service we are simply creating a custom client for, so JSON-RPC is irrelevant.

            Quote from: BobRay at Feb 06, 2009, 01:35 PM

            Are there guidelines somewhere for creating a MODx service?
            Just what I said, as long as the constructor accepts the two parameters (the reference to modx and an array of configuration options) you can implement a "service" class like we are talking about here. Don’t get confused, these "service" classes are simply classes for closely and easily integrating just about any modular code with modX, and have nothing to do with "web services", other than in this instance we are creating a MODx "service" class the happens to communicate with an XML-RPC web service.
              • 3749
              • 24,544 Posts
              Quote from: OpenGeek at Feb 06, 2009, 04:50 PM

              Quote from: BobRay at Feb 06, 2009, 01:35 PM

              (still wondering, though, why Captcha is a plugin rather than a service since all the same arguments apply there, no?-- I’m sure there’s a good reason, I just can’t see it).
              Because I didn’t implement it? tongue

              Au contraire mon frere. wink

              It took a while to find it, but here’s where I got the idea:

              http://modxcms.com/forums/index.php/topic,23283.msg170117.html#msg170117

              At that point in my MODx development, I don’t think I would have thought of making it a plugin. OTOH, I for sure never would have thought of making it a service class and wouldn’t have today if you hadn’t suggested it. wink


                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
                • 22303 MODX Staff
                • 10,725 Posts
                Right, I should have said, "create a reusable class the handle the details of Captcha and use it in a plugin or snippet, or wherever you need it". Ah, love that hindsight. wink
                  • 3749
                  • 24,544 Posts
                  [
                  author=OpenGeek link=topic=32772.msg199888#msg199888 date=1234029360]
                  Right, I should have said, "create a reusable class the handle the details of Captcha and use it in a plugin or snippet, or wherever you need it". Ah, love that hindsight. wink

                  I think we do have a fairly reusable class. All you have to do to use it is this:

                  require_once MODX_CORE_PATH/ 'components/captcha/classes/veriword.class.php';
                  
                  if ($modx=>config['captcha_use_mathstring']) {
                      $vword = new VeriWord($modx,$width,$height, "MathString");
                  } else {
                      $vword = new VeriWord($modx,$width,$height);
                  }
                  $vword->output_image();
                  $vword->destroy_image();


                  You can also send the desired captcha word to the contructor. That’s the Evo version but the Revo version is quite similar. I think it would be very easy to use outside the plugin.
                    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