$scriptProperties and AJAX

I was just wondering about best practice solutions to using these properties with AJAX functionality. For example, awhile back I upgraded my poll snippet to work with revolution. It uses AJAX extensively (while degrading nicely for browsers without JS/AJAX support) but without a request handler. It basically calls the current page and just calls exit() to prevent anything other than the snippet output from being displayed. Obviously, this isn’t the optimal way to do this, since MODx loads up all sorts of unneeded stuff on this type of request.

So I wrote a request handler and managed to get it working, *BUT* $scriptProperties obviously isn’t loaded in the external handler. You can get around this by using something like this in your AJAX processor:

$snippet = $modx->getObject( 'modSnippet', array( 'name' => 'SnippetName' ) );        
$scriptProperties = $snippet->getProperties();

The issue is from the fact that users can still use parameters in the actual snippet call, to override the properties in the MODx database. In that case, the overridden properties won’t match the properties in the Element’s properties, so some pretty weird stuff could happen. I guess there’s no way around this, but would the ideal solution be for the user to simply create a new "Properties Set", override the default parameters with their own, and modify the code snippet above to get the properties from the new set instead?

The other issue is with things like page links. A number of times I use something like $modx->makeUrl( $modx->resourceIdentifier, ’’, ’some=parameters’ ), but with an AJAX call using a handler, it isn’t a "resource" so makeURL chokes. Leaving the URL blank isn’t an option as certain parameters (ie poll_id) are used to create the onclick handler (plus, if JS is disabled, the link no longer works).

Any ideas on either of these issues? Thanks!

[[!Sherpa? &context=`connector`]]

This is not true; Revolution is made especially for the purpose of executing any kind of PHP request, including your AJAX requests, through a standard gateway, or through specific gateways now with contexts (i.e. consider using a context for your custom AJAX connectors), to make sure security standards, sessions, and other details are all consistent across requests, and that you can easily manage your AJAX connectors as you would any other MODx Resource. So I would say if you are writing request handlers that do not extend the modRequest class and execute in a custom context, you aren’t really using AJAX in MODx in an optimal way.

<?php

/**
 * This is our base connector file, for use with AJAX requests in the frontend.
 * It mainly just sets up some initial settings and instantiates the main MODx class.
 * 
 * @package ajaxpoll
 * @subpackage processors.ajaxpoll
 * @version 1.0
 * @author [snip]
 */

$basePath = dirname( dirname( dirname( dirname( dirname( dirname( __FILE__ ) ) ) ) ) );
$pollPath = dirname( dirname( dirname( __FILE__ ) ) );

require_once( $basePath . '/config.core.php' );

if( !defined( 'MODX_CORE_PATH' ) ) {
    define( 'MODX_CORE_PATH', $basePath . '/core/' );
}

require_once( MODX_CORE_PATH . 'model/modx/modx.class.php' );

$modx = new modX();
$modx->setDebug( E_ALL & ~E_NOTICE );
$modx->setLogLevel( MODX_LOG_LEVEL_ERROR );
$modx->setLogTarget( 'HTML' );
$modx->initialize( 'connector' );
$modx->getRequest();
$modx->request->sanitizeRequest();
$modx->request->handleRequest( array( 
    'location'          => 'frontend', 
    'action'            => '', 
    'processors_path'   => $pollPath . '/core/processors/'
) );

?>

$scriptProperties is available anytime you call $modx->runSnippet() or instantiate the object as you did above and call $snippet->process(). I’m not clear on the problem you are trying to solve here. You should never have to call $snippet->getProperties() unless you are building a management interface or some other core extension to work specifically with properties as definitions. $scriptProperties is automatically aggregated at run-time, when processing an Element, as are all properties for any Element type.

That’s not an issue in my estimation; that’s by design. How is overriding the property sets in a tag an issue? To me that’s a powerful feature and was the whole intention of having default properties separate from property sets and tag properties, and allowing both property sets and tag properties to override the default. Maybe I’m confused on the what we are discussing exactly...

IMO, it should be a Resource. Otherwise, your code needs to be responsible for generating the URLs of the request handlers outside the framework.

Quote from: Ricjustsaid at Jan 13, 2009, 06:12 PM

Any ideas on either of these issues? Thanks!

I would recommend making a Resource that has a template of (blank), setting its content type to JS (you’re returning JSON, right?), and then putting inside its content field your snippet. I do something similar with a snippet I’ve been developing, that goes like so:

[[!Sherpa? &context=`connector`]]

And my snippet loads the proper things necessary to output the JS. It’s up to you, however, on how you want to do it, in the end.