Eric, right now, the configuration data would simply contain a number of details such as - endpoint_url - api_key - secret - user_id
the question really is whether one would want to use the library in the same application with different configuration details. I hadn't originally envisaged this, but Michael Kay makes this point in a future message, so I'll think about this. thanks, Jakob. On Wed, Dec 28, 2011 at 00:25, Eric Bloch <[email protected]> wrote: > I presume persistent state (like configuration) is managed and specified > differently for each xquery processor - as such, whatever you do may have > some processor dependent code. > > E > > Eric Bloch > [email protected] > > > > On Dec 27, 2011, at 3:13 PM, Jakob Fix wrote: > >> Hello, >> >> I'm about to write an xquery library and I'm curious whether there are >> best practices around regarding the inclusion of other library modules >> (a quick Google search didn't turn up anything useful). >> >> In particular, I'm interested in how one would implement this: >> >> - a library module (out of several) >> that uses configuration data specific for each application it is used in, >> and >> that itself makes use of lower-level functions. >> >> for example, a library module with a number of publicly exposed api >> functions that each would take an "api_key" argument that is specific >> to the application and probably stored in a separated configuration >> file. Itself, it may make use of an http-get function defined in yet >> another library module. >> >> I would like to avoid the case where each function signature needs to >> have a required argument (the api_key and maybe others too) that could >> be added much more elegantly by looking up a global variable read from >> the configuration file. For example, for the functions documented >> here (http://developer.marklogic.com/pubs/5.0/apidocs/ec2-2009-11-30.html) >> each function has always the same three arguments that serve to >> identify the caller. In my case, there can be three such arguments, >> but only one is required. >> >> instead of this >> d:get-data($api_key as xs:string, $secret as xs:string?, $from as >> xs:string, $to as xs:string) as element(result) {}; >> >> I'd like this >> d:get-data($from as xs:string, $to as xs:string) as element(result) { >> http:get($config:url, $config:api_key, $config:secret, $from, $to) }; >> >> where the authentication arguments would be retrieved from the >> configuration file when necessary and added to the http get request >> inside the function body. >> >> >> so, would it be advisable to have this (where only application.xqy has >> all information necessary, but minimal inclusion takes place) >> >> - application.xqy that includes >> - configuration.xqy >> - library1.xqy >> - library2.xqy >> - lowlevelfunctions.xqy >> >> or rather this (where each library module is independent as it >> includes what's needed) >> >> - application.xqy that includes >> - library1.xqy which includes >> - configuration.xqy >> - lowlevelfunctions.xqy >> - library2.xqy which includes >> - configuration.xqy >> - lowlevelfunctions.xqy >> >> or still another scenario? >> >> sorry if that sounds confusing, >> Jakob. >> _______________________________________________ >> [email protected] >> http://x-query.com/mailman/listinfo/talk > _______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
