Hi, I am hoping to use this for debugging. Our project is fairly complex and I use a controller function to apply multiple operations to content (each of these may use one or more function). When I get a 500 error, it's very hard for me to pinpoint the source of the issue.
I can get the data from the form filled by the user and a few of the redirect, but that only gets me so far, if I could track both the function names and the parameters for sub-functions, it would save me a lot of time. Below is an example of what I call a controller... I use those when I need content to be saved before I can query it again for the next updating operation. Each if the workflow step uses multiple sub functions that are not accessed through http and that are as far as I know untraceable. (: Transforms content to xliff for each language and export packages for translation vendors :) *declare* %rest:path('/translation/create-package') %rest:GET %rest:query-param('menu-id', '{$menu-id}', '') %rest:query-param('lang', '{$lang-in}', '') (: The step that we were at when the function was called :) %rest:query-param('step-id', '{$step-id}', '0') %rest:query-param('package-number-in', '{$package-number-in}', '') %output:method("html") %output:html-version("5.0") *updating* *function* *translation:create-package-controller*(*$menu-id* *as **xs:string*, *$lang-in* *as **xs:string**, *$package-number-in* *as **xs:string*, *$step-id* *as * *xs:string*){ ... *let* *$workflow* := <steps> <step *id*=*"1"* *name*=*"Add-ids"*>Add @ids for en-us</step> <step *id*=*"2"* *name*=*"Health-check"*>DB health check for en-us</step> <!--step id="3" name="Check-keywords">Check for keywords that may need to be replaced by prompts</step--> <step *id*=*"3"* *name*=*"Process-to-xliff"*>Process files to skeletons and xliff</step> <step *id*=*"4"* *name*=*"Register-packages"*>Register new packages in translation-management.xml... before deleting files with no new segments.</step> <step *id*=*"5"* *name*=*"Old-content-to-target"*>Process files in no-new-segment (could have different attributes or deleted content) to target lang.</step> <step *id*=*"6"* *name*=*"Delete-no-new-segment"*>Deletes no-new-segment xliffs that were processed in step Old-content-to-target. </step> <step *id*=*"7"* *name*=*"Set-target-status"*>Sets updatibility of target topic</step> <step *id*=*"8"* *name*=*"Export-and-zip"*>Export and zip files</step> </steps> ... * switch* (*$workflow*//*step*[*@id*=*$this-step*]/*data*(*@name*)) *case *'Add-ids' *return *(:let $debug := file:append('debug-create-pack-crash.xml', ' In Add-ids '):) *let **$t* := '' *return *(*admin:add-ids*('en-us'), *db:output*( *$next-step-forward*)) ... *case *'Set-target-status' *return *(:let $debug := file:append('debug-create-pack-crash.xml', ' In Set-target-status '):) *let **$t* := '' *return *(*for **$lg* *in * *$lang* *return **translation:toggle-target-status*(*$lg*), *db:output*( *$next-step-forward*)) .... *case *'Export-and-zip' *return *(*let **$zip* := *translation:export-and-zip*(*$menu-id*, *$lang*, *$package-number*) (:let $debug := file:append('debug-create-pack-crash.xml', ' In Export-and-zip '):) *return *((), *db:output*( *$next-step-forward*)) ) *default* *return *((), *db:output*( *admin:display-in-dashboard*(<div><div *class*=*"l2"* *style*=*"color:red;"* >An error has occured, you should have been redirected to the export function before reaching this point. Default in switch steps.</div>{ *app:get-beep-div-for-dashboard*('error')}</div>))) }; On Tue, Aug 19, 2014 at 10:26 AM, Christian Grün <christian.gr...@gmail.com> wrote: > Hi France, > > I would also be interested if you'd like a functionality as proposed > by Andy, and if you are interested in improving debugging your XQuery > code, or if you think that such a function could also be helpful in > productive code? Do you have some more input? > > Thanks, > Christian > > > On Mon, Aug 18, 2014 at 7:14 PM, France Baril > <france.ba...@architextus.com> wrote: > > Hi, > > > > I'm working on improving our tracking capabilities. I was hoping to find > a > > function that would do the equivalent of what the code bellow does, but > for > > internal functions that are not called through the rest interface. > > > > string-join(for $name in request:parameter-names() > > return $name || ': ' > > || string-join(request:parameter($name), > > '; '), > > > > ' ') > > > > In short, I was wondering if there is way I can read the function's > > parameters and their values without listing each one explicitly. > > > > I searched the documentation without success. > > > > -- > > France Baril > > Architecte documentaire / Documentation architect > > france.ba...@architextus.com > -- France Baril Architecte documentaire / Documentation architect france.ba...@architextus.com