If the goal is debugging .. another approach might be to think about Aspect Oriented Programming something like http://www.mkyong.com/spring3/spring-aop-aspectj-annotation-example/
/Andy
On 19 August 2014 18:05, France Baril france.baril@architextus.com wrote:
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.gruen@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.baril@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.baril@architextus.com
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com