[OPEN-ILS-DEV] Passing parameters to patron search in staff client

[Mark Gavillet]

Thanks for this Jason, it's really going to speed things up for me - particularly CTRL+SHIFT+F7 which looks really useful!

Cheers
Mark

On 23 Sep 2011, at 12:46, Jason Etheridge wrote:

> On Fri, Sep 23, 2011 at 7:10 AM, Mark Gavillet
> <mark.gavillet at ptfs-europe.com> wrote:
>> I'm working on a couple of custom pieces of functionality, which when
>> finished, we were hoping to submit back to the community.
> 
> Awesome.
> 
>> I hope you don't mind me asking another quick question. Is there a
>> recommended way of debugging Evergreen? I'm finding it a bit difficult to
>> track what is going on when I do something in the client.
> 
> It is a bit of a Frankenstein.
> 
> If you make a server/skin/custom.js from the custom.js.example file,
> the console will get a lot more noisy with dump statements.  If using
> a Windows staff client, you'll want to add -console to the target in
> the shortcut that spawns the client.
> 
>> Ideally I'd like to be able to find out which xul files are being used to construct a tab,
> 
> Control+Shift+F7 will open a debug box for whichever interface has
> focus, and you can eval stuff like location.href to see where you're
> at.  The DOM inspector under Admin -> For Developers is also
> invaluable.
> 
> For certain embedded interfaces in the client, you can click on the
> faded Debug label in the upper right and get at the URL and the source
> code.  Such interfaces can often be ran outside of the staff client by
> pasting the URL into Firefox, though in general, the client pushes a
> lot of stuff (data and callbacks, usually through a variable called
> xulG) into an embedded window's scope, that the content can then make
> use of.
> 
>> which OpenSRF methods are being called, and which parameters are being passed between screens.
> 
> For parameters between the screens, you can do the Control+Shift+F7
> trick and inspect xulG, and/or look for any lingering URL query params
> with location.href.
> 
> OpenSRF methods will show up in the console (with that custom.js
> file), but you can also tail the osrfsys.log on the server and pipe
> grep it for CALL:
> 
> Or the gateway.log, and grep it for ACT:
> 
> In the logs, when you see something like
> [ACT:4984:./osrf_http_translator.c:293:1316693765498419], that last
> number is a thread trace, which you can use to link a lot of things in
> the logs together (though if you're the only one using a system, it's
> not as important).
> 
> There's also a source debugger, which while not as nice as Firebug or
> the Chrome dev tools, is functional.  Admin -> For Developers ->
> Venkman
> 
> -- 
> Jason Etheridge
>  | Equinox Software, Inc. / Your Library's Guide to Open Source
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  jason at esilibrary.com
>  | web:  http://www.esilibrary.com