To resolve imports via xdmp:eval, set the 'root' option - just as you would do to invoke a module. Take a look at how cq does it. The code is Apache-licensed.
If the imports aren't available on the server at all, you will have to make them available. That is where the Modules database might come it. You could use the server filesystem too, but using a database is cleaner. And you would have to copy everything that your module(s) need. -- Mike On 1 Mar 2012, at 07:35 , Alex Jitianu wrote: > Hi, > > Unfortunately if a query is submitted through xdmp:eval you can't give a base > URI for resolving any relative imports that that query might have. Or can > you? So I kind of require a mix between xdmp:invoke and xdmp:eval. The > "module URI"->"updated module content" mapping to be passed to the > xdmp:invoke was my idea of such a mix. The server first looks for a module in > the Modules database? And are you suggesting that I create a temporary > structure in the Modules database in which the server will find my updated > version of the modules before finding them in their real location? > > Thanks, > Alex > > On 3/1/2012 5:12 PM, [email protected] wrote: >> xdmp:eval has the static-check option too. You could send the module to it >> as a string. >> >> Beyond that, the Modules database makes a dandy persistent uri->content >> repository. You could have a hierarchy of temp files, perhaps something like >> /sync.ro/ >> .sessions/{$SESSION}/{$RELATIVE-PATH}. Use a scheduled task to clean out >> anything older than N hours or days. >> >> -- Mike >> >> > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
