genshi and hdfdump
Emmanuel Blot
Is there a "magic" debug parameter such as "hdfdump" that can be used
along with Genshi-rendered pages?
BTW, I think this page:
http://genshi.edgewall.org/wiki/TracInterfaceCustomization
as nothing to do w/ Genshi, as some other Trac* pages
For the sake of simplicity and clarity, I think these pages would
better be removed from the Genshi project.
TIA,
Manu
Emmanuel Blot
> along with Genshi-rendered pages?
Follow-up: Alec implemented it in [4868].
Thanks.
Manu
Christian Boos
... and if it's there to stay, should probably be restricted to
TRAC_ADMINs ;-)
-- Christian
Christopher Lenz
I was playing with the idea to move this functionality out into a
"TracDevTools" plugin, which would include "pretty" template data
dumping as well as other things (such as an enhanced version of the
about/plugins page, showing relationships between components via
extension points).
The template data debugging will be based on the IRequestFilter
extension point, and probably use AJAX to be able to drill-down into
objects (in a manner similar to evalexception). Also, it'll define
its own permission actions and maybe be configurable to only work on
requests via localhost, or on the local network, or a configurable
set of IPs.
I've started work on that plugin and will probably push it up on trac-
hacks.org in the next couple of days.
Any ideas for what other functionality such a plugin could provide
for aiding plugin developmnent?
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Alec Thomas
> I was playing with the idea to move this functionality out into a
> "TracDevTools" plugin, which would include "pretty" template data
> dumping as well as other things (such as an enhanced version of the
> about/plugins page, showing relationships between components via
> extension points).
>
> The template data debugging will be based on the IRequestFilter
> extension point, and probably use AJAX to be able to drill-down into
> objects (in a manner similar to evalexception). Also, it'll define
> its own permission actions and maybe be configurable to only work on
> requests via localhost, or on the local network, or a configurable
> set of IPs.
>
> I've started work on that plugin and will probably push it up on trac-
> hacks.org in the next couple of days.
>
> Any ideas for what other functionality such a plugin could provide
> for aiding plugin developmnent?
This sounds useful.
An extra addition might be interface validation, like this patch:
http://www.swapoff.org/files/interface-check.diff.
Also, once workflow goes in, Eli's Graphviz visualisation and validation of
the workflow state changes.
Though these might be more useful as TRAC_ADMIN only preference panels.
Something else to think about might be an AJAX API in Trac. More and more
plugins are starting to use AJAX, so it might be useful to have this built
into the core.
Alec
--
Evolution: Taking care of those too stupid to take care of themselves.
Christian Boos
That sounds very interesting indeed.
On Mar 1, 8:43 pm, Christopher Lenz <cml...@gmx.de> wrote:
> The template data debugging will be based on the IRequestFilter
> extension point, and probably use AJAX to be able to drill-down into
> objects
I see this also useful on the error page, as an enhancement for the
list of frame locals.
> Any ideas for what other functionality such a plugin could provide
> for aiding plugin developmnent?
Well, a good object inspector would do 90% of the job.
I guess we'd need also a "Done" button so that the server can release
all the information kept for a request, once we're done inspecting the
results.
What would be also useful is a trace of all the SQL queries that were
executed during the request (in the spirit of the commented out print
lines I've left in IterableCursor).
-- Christian
Alec Thomas
> Something else to think about might be an AJAX API in Trac. More and more
> plugins are starting to use AJAX, so it might be useful to have this built
> into the core.
I've added a jsonrpc handler to the now inappropriately named XML-RPC plugin.
It lets you do things like this in JavaScript:
rpc = new $.jsonrpc("http://localhost:8080/stable/jsonrpc");
rpc.expose("wiki.getPageHTML");
$("#test").click(function() {
page_handler = function(content) {
$('#test').after(content);
}
rpc.server.wiki.getPageHTML(page_handler, "WikiStart");
}
Any method exposed through XML-RPC is also exposed through JSON-RPC, and normal
permissions apply.
Christian Aust
the XMLRPC functionality should go IMHO? XMLRPC is a must for me.
- Christian
p.s.: I'm working on a Windows native application accessing trac via
XMLRPC that allows you to do some kinds of manipulation of Wiki data
not available in the web. Specifically, we use trac to gather
documentation for our projects, my software allows you to export a
set of pages for import into MS Word or else. That helps us a lot. If
somebody's interested, I'll hand over a beta.
[It's written in REALbasic, so native Linux and Mac versions are
available, too.]