Re: Handling Configuration File Parameters -- Historical Unrefined Approach Just for Discussion

Hi Alex,

An eval-pipeline step has been mentioned before, but as far as I know
no one's implemented it as an extension function.

I don't know if this is what you're looking for, but I've done
something similar at runtime (not preprocessing). I had a problem
where I needed to edit the contents of an XQuery dynamically.  I
settled on using a step that took parameters and replaced any
instances of ${varname} with its string value.  For example, I would
construct an xquery this way:

    <p:identity>
      <p:input port="source">
        <p:inline>
          <c:query xmlns="http://exist.sourceforge.net/NS/exist"
start="1" max="20" cache="no">
            <c:text>
              declare namespace c="http://www.w3.org/ns/xproc-step";
              let $login := xmldb:login("xmldb:exist:///db",
"${user}", "${password}")
              let $response :=
xmldb:create-collection("${parent-collection}", "${collection}")
              return (element c:result { concat(request:get-url(), $response) })
            </c:text>
          </c:query>
        </p:inline>
      </p:input>
    </p:identity>

    <wxp:resolve-placeholders>
      <p:input port="parameters">
        <p:empty />
      </p:input>
      <p:with-param name="user" select="$user" />
      <p:with-param name="password" select="$password" />
      <p:with-param name="parent-collection" select="$parent-collection" />
      <p:with-param name="collection" select="$collection" />
    </wxp:resolve-placeholders>


The <wxp:resolve-placeholders/> step uses <p:parameters/> to create an
XML out of the parameters, which is then passed to a transform which
replaces the variable names with their values.

-James


On Fri, Feb 19, 2010 at 6:37 AM, Alex Muir <alex.g.muir@gmail.com> wrote:
> Hi,
>
> I was reading posts about configuration file parameters in the xproc list
> archives and having my own issues using them that it led me to recall my
> solution when creating a simple xslt pipe line as probably all on this list
> have done.
>
> Regarding handling the configuration file:
>
> We started with name value pair configuration declarations in the top of the
> pipe which were referenced below using xpath which became cumbersome to use
> over time and at some point the idea came to use a simpler perhaps unrefined
> solution that worked well.
> We had to externalize the name value pair configuration xml file to have
> multiple configuration files, some for end users, some for more technical
> people...
>
> Given the need to have multiple configuration files we preprocessed to
> combine the configuration files to pass only one config file through the
> pipe as passing more than one would have been more work.
> PERHAPS THE KEY POINT: Rather than reference the configuration file using
> xpath and having the pipeline processor to pass the configuration file as a
> DOM through the whole process to find config values dynamically as they were
> needed using xpath, we replaced all the xpath with '##VariableName##'
> referencing the same variable name from the config file as the xpath was.
> Then preprocessing we complied the new pipeline xml document finding and
> replacing '##VariableName##' with the correct value for each configuration
> file as we no longer combined config files into one as there was no need.
>
> The simplification saved us development time in the future.
>
> From what I gather this type of script preprocessing is a fairly common
> practice.
>
>
> Questions for discussion:
>
> Are others doing this with their xproc scripts? Why or why not?
>
> I wonder would it be better that I use the parameters configuration file as
> it is currently  designed in xproc rather than I create a small script to
> implement the ## Configuration version?
>
> Is it possible to have a small xproc pipe which executes this process and
> then executes the regular process without running the process twice from the
> command line? ( just thinking out loud here)
>
> Would that just require I use the "exec" step for example if I wanted to
> launch 4 java process of the some pipe compiled with different
> configurations?
> I think that will work, no?
>
> Thanks Much
>
> --
> Alex
> https://sites.google.com/a/utg.edu.gm/alex
>
> Some Good Music -- mix of western and African relaxing acoustic styles
> http://sites.google.com/site/greigconteh/
>

Received on Friday, 19 February 2010 14:52:04 UTC