get the documentMap() function

In ajaxSearch to get the documents where to search i use a function getListIDs :

This getListIDs use the $modx->documentMap() function

My concern is that from an ajax window I haven’t the modx object initialised In the current version of AS, the complete IDs list is transmitted thru javascript. Rather to transmit a long list of ID, I would like transmit only the parents Ids. But This required to use the $Modx->documentMap function in the Php script called from the ajax script.
So my question is what are the minimum core functions (and order) I need to call to set up a modx objet with a correct map ?

For the moment in the ajax context i have only the following variables :

global $database_server;
global $database_user;
global $database_password;
global $dbase;
global $table_prefix;
global $database_connection_charset;

Which is obviously not enought to get the documentMap function. Thanks for your answer.

This is a long-standing problem and one of the reasons I endeavored to rewrite MODx as an OO application which would allow use of the core API functionality with minimal bootstrap requirements (i.e. load as little as possible until needed). For now, if you prefer to use the modx object in your separate Ajax script, you can use a technique that netnoise introduced in 0.9.6.1, which allows you to include the main index.php file, which initializes the modx object for usage, and prevents the executeParser() method from being called. To do this, simply define a constant MODX_API_MODE with the boolean value true before including the index.php.

There is another alternative however. Personally, I’d rather see the ajax request itself served by an additional snippet, distributed with the AjaxSearch add-on, that can simply be configured on another page (that likely would not be shown on a menu; i.e. a document serving as an Ajax service). This is how I implement all ajax requests in my MODx sites.

I created a unit testing script to test certain aspects of my 0.9.6 snippet code. Here’s what the MODx setup portion looks like:Basically, the four lines below "Setup the MODx API" are the what you need to use.

I didn’t use [tt]index-ajax.php[/tt] because it limited me to use only files in the snippets folder, so I needed more control. For your AjaxSearch snippet, this might be the better option.

Thanks Matthew for your testing script. This is exactly what I need.

Jason,

1/ For now, if you prefer to use the modx object in your separate Ajax script, you can use a technique that netnoise introduced in 0.9.6.1, which allows you to include the main index.php file, which initializes the modx object for usage, and prevents the executeParser() method from being called. 2/ Personally, I’d rather see the ajax request itself served by an additional snippet, distributed with the AjaxSearch add-on, that can simply be configured on another page (that likely would not be shown on a menu; i.e. a document serving as an Ajax service). This is how I implement all ajax requests in my MODx sites.

Not sure to understand the two options. Just now the ajaxSearch php code is called by :

// Setup the parameters and make the ajax call
var pars = Object.toQueryString({
q: _base + ’ajaxSearch.php’,
search: s,
as_version: as_version,
debug: debug,
ajaxMax: ajaxMax,
…
hideMenu: hideMenu,
listIDs: listIDs
});

var ajaxSearchReq = new Ajax(’index-ajax.php’, {postBody: pars, onComplete: doSearchResponse});
if (newToggle.isDisplayed()) {
newToggle.toggle();
ajaxSearchReq.request.delay(600, ajaxSearchReq);
} else {
ajaxSearchReq.request();
}

I plan to include in ajaxSearch.php code the following lines:

// Setup the MODx API
define(’MODX_API_MODE’, true);
// initiate a new document parser
include_once(MODX_MANAGER_PATH.’/includes/document.parser.class.inc.php’);
$modx = new DocumentParser;

$modx->db->connect();
$modx->getSettings();

And then use modx->documentMap function to get all the list IDs from the &parents.

In this solution ajaxSearch.php is not a MODx snippet only a php script distributed with the ajaxSearch add-on . But how could I call a MODx snippet from javascript ? Or I have understood nothing

First, this is all you need to get access to $modx...

And presto, $modx->documentMap is available.

As for using a snippet to reply to an Ajax request, this is the same as returning any request to a MODx document. Just don’t use a template, return the proper content type and have the snippet contain the logic of your separate ajax file. This allows MODx to control access to it just like any document. You could use a parameter, maybe ajaxDocId or something and use it like so:

Why this wasn’t done as a snippet in the first place, I personally can’t understand, but I’m weird.

Quote from: OpenGeek at Mar 07, 2008, 11:26 AM

First, this is all you need to get access to $modx...

// Setup the MODx API
define('MODX_API_MODE', true);
// initiate a new document parser
include('/path/to/index.php');

And presto, $modx->documentMap is available.

Jason, this only initializes the [tt]$modx[/tt] object. The [tt]$modx->documentMap[/tt] array is not populated (because it is stored in [tt]siteCache.idx.php[/tt]) until the [tt]getSettings()[/tt] method is called. That is, unless we’re talking about 0.9.7 in which case I need to shut up :-/

My mistake, I remembered incorrectly (been spending all my time with 0.9.7 lately); like I said, I always opt to implement such requests as MODx documents/snippets myself, so I don’t know from experience how this works in 0.9.6.x, so, carry on...

@Jason - is wasn’t done that way because I wasn’t thinking clearly (and I don’t think I had seen that done at the time)

Glad to see this is getting moved over to a snippet, let me know if you need any help or want to collaborate on it.

Quote from: kylej at Mar 07, 2008, 12:49 PM

@Jason - is wasn’t done that way because I wasn’t thinking clearly (and I don’t think I had seen that done at the time)

Well, hello kylej! And my apologies, I didn’t mean my comment as a crack at your thinking when originally implementing it. In fact the reason I believe was to keep the request as trim as possible. I think though if having the $modx object available is needed to meet functional requirements, it will be just as efficient to do it as a MODx document/snippet.

No problem... I think one of the good things about setting it up as a snippet would be to eliminate the need to pass all of the different setting through javascript. As we have seen this can cause security alerts for modx users and it would help eliminate a lot of the junk that gets passed from the original snippet call.

And yes... I am going to be making a concerted effort to get more involved here again. I’ve been having a hard time sitting at a computer at night after doing it all day (and having a second child). But I am getting ready to buy a MacBook Pro and then I can sit on the couch and not feel to holed up in the basement.