What would you want from a component Introspector / debugging tool?
A couple of weeks ago I discussed the possibility of having a component registry browser with some friends. I mentioned this and also tools like ZMIntrospection to people at the Plone Strategic Planning Summit 2008 (others may have had the same idea, the process during the summit was such that it’s pretty much impossible to assign blame for ideas to anyone specific, so if somebody else also brought this idea forward: I’m not trying to steal the credit 😉 ).
The summit deemed it a good idea, and I was assigned as a champion for the task of creating a Plone Inspector tool. I might possibly have somebody lined up to do this as a project for the university, which seems great. I’ll come back with a time line in case he accepts.
Waiting for this, I’m gathering requirements. What does people want it to do? My requirements were the following:
- A component registry browser, to more easily see why your adaptations and lookups doesn’t work as expected.
- An object introspector like ZMIntrospection that works for views, so I can see what the attributes on a view is.
- It should if possible be pure zope3-code, so as to work both on Grok and Plone. (Tall order, I know).
Martin Aspeli also came up with this feature list (there is a bit of overlap):
- The tool is completely disabled in non-debug mode and is available to the Manager role only!
- When invoked upon a particular browser view, show its name, where it is defined, and what context and layer it is defined for. Ideally, it should be possible to generate a short code snippet that shows the view registration in full so that it can be easily adapted for a customised version.
- Similarly, display detailed information about all viewlets visible on the view where the introspector is invoked.
- When invoked directly upon a content object, show a class inheritance tree, with docstrings for public methods ala the DocFinderTab. Ideally it should be possible to drill down to view actual code.
- Similarly, display the views and viewlets that are registered for this context, in order of specificity (general views come last), with full information about how these are registered.
- Similarly, display any other adapters that are registered for this type, in order of specificity, with full information about how they are registered and which factory is in effect.
- Where appropriate (when displaying views, viewlets or portlets) it should be possible to invoke the portal_view_customizations machinery.
- Provide a context-less view that can browse all adapter, utility and event handler registrations. This should group registrations by interface and separate global from local components.
- The views that make up the tool should provide some viewlets so that third party products can insert their own introspection tools where necessary. For example, plone.app.portlets should do this to make it possible to view portlet registrations alongside view and viewlet registrations.
We can so far see a couple of main areas, with fuzzy delimitations:
- A component registry browser/searcher.
- An enhanced DocFinderTab/object introspector that also shows object attributes, registered adapters and possibly even code.
- A view introspector that shows view information and viewlets.
In any case, work will start out with part 1 of this, and hopefully later expand in to the other areas.
So, what are your requirements? The more idea we have, the better this tool will be. No guarantees that we will implement it, though! 😉