Hi Jean-Philippe,
thanks for providing us with the (concise) details.
In our existing RESTXQ projects, we directly decorate all executable functions with specific %rest:path annotations; this way, there is no need for an additional “dispatcher” function that delegates a call to a specific module or function. You can dynamically add and remove modules to your web application, as all .xqm files will automatically be parsed for restxq annotations before each query execution. Next, the implementation is smart enough to only parse code that has ben changed, so you shouldn’t encounter any bottlenecks even when working with hundreds of restxq modules. But I’m not sure if adding modules with restxq entry points is a reasonable alternative for your approach?
Your feedback is welcome; feel free to ask for more details, Christian ___________________________
2013/6/21 Jean-philippe Magué jean-philippe.mague@ens-lyon.fr:
Dear Christian,
Thanks for your response. I'm going to try be more specific, but to remain concise.
In our restxq application, we have one "main" module and several "dependent" modules. The main module receives the http requests (well, it declare functions annotated with a path, say ourApp/{$param}), and calls functions in one of the dependent module. This dependent module is determined by the path : a request to ourApp/moduleA will cause the main module to use functions in the moduleA dependent module, while a request to ourApp/moduleB will cause it to call functions in the moduleB dependent module.
It works just well if we import all the dependent modules in the main module using the regular way, with import module statements. Yet, we want to go one step forward and import the dependent modules only when/if needed. More precisely, we'd like to be able to add new dependent modules in the restxq directory without having to modify the main module by adding new import module statements.
But it's probably some kind of inappropriate perfectionism that isn't worth spending much time !
Best,
Jean-Philippe
PS: Thanks for looking at the circular import issue. Having our dependent modules importing back the main module would be very helpful!
On Thu, Jun 20, 2013 at 10:44 PM, Christian Grün christian.gruen@gmail.com wrote:
Dear Jean-Philippe,
as you correctly guessed, there is no function in BaseX for dynamically importing XQuery modules. The function xquery:invoke [1] may serve a similar purpose. I’m not sure how the invocation of Java code could help here, so could you give us some more information on what you plan to do, and what needs to be done at runtime in your scenario?
Thanks, Christian
PS: our team member Leo is currently having a look at the circular module import issue.
[1] http://docs.basex.org/wiki/XQuery_Module#xquery:invoke ___________________________
Exist-db has an util:import-module function that allows to dynamically import an XQuery module at run time. I haven't found anything equivalent in BaseX. Is that right ?
I have also tried to see how to implement such a function directly in Java, but as far as I understand the module parsing process, functions prefix are checked at compile time. That would compromise any attempt to write such a function. Am I right ?
Best,
Jean-Philippe
-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08
--
"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Jean-Philippe Magué Maître de Conférences en Humanités Numériques Responsable de l'Atelier des Humanités Numériques : ahn.ens-lyon.fr Ecole Normale Supérieure de Lyon +33 (0)4 26 23 38 08
--
"Using computers will therefore lead us to a more profound and systematic knowledge of human expression; in principle, it can help us to be more humanistic than before." Busa, 1980.