Skip to content

What would you want from a component Introspector / debugging tool?

February 17, 2008

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, 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:

  1. A component registry browser/searcher.
  2. An enhanced DocFinderTab/object introspector that also shows object attributes, registered adapters and possibly even code.
  3. 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! 😉


From → grok, plone, python, zope, zope3

  1. on mouse-over on a viewlet name, it should visually highlight the area and vice-versa. one big difficulty when dealing with viewlets is associating their names with the actual part of the screen that they affect.

    @@manage-viewlets is too invasive, as it breaks the layout, perhaps with the Plone Inspector Tool we have a way to implement it in a non-invasive way, just a thought.

  2. Hmmm. How do you mean that it could be non-invasive? How would that work? The introspector tool would be views that show information. I don’t see how they could preserve layout.

  3. What about an extra tab in the zmi to show the annotations? So much is happening “hidden away” in annotations nowadays, some inspection mechanism would sure be handy 🙂

  4. yurj permalink

    The properties tab could become “properties & annotations” 🙂

  5. Yes, good point, the object introspector should definitely show annotations as well. ZMIntrospector doesn’t show them as they are “hidden” in a BTree.

  6. Clouseau integration somehow somewhere. For example instead of Clouseau just showing doc strings it could show links to these elements.

    A mouse over context sensitive help (only asking because I wrote it), I have a dream of being able to enable it, point at “Login” and it saying (in old Zope 2 parlance) “this is an action, it comes from here and has these properties a how to on changing it is here”.

  7. The Clouseu integration is interesting, although that reasonably has to be done from Clouseau.
    Maybe Closeau has a library of introspector functions that we could use and extend, and then it would be easy to get this functionality in both systems.

    The mouse-over help would be great, but I’m not sure how that can be done, except by adding specific rendering code in any place in Plone that renders something. So I guess the question to you there is the same as to Tom above:

    How could this type of information be done in a non-intrusive way? I don’t see that. We are going to have to have specific views to show this internal information, so it’s going to be extremely “intrusive” as far as I can see.

  8. shurik permalink

    What about using a semi-transparent overlay? A div covering the viewport that draws the outlines of various elements being inspected and shows their names and appropriate info.

  9. The problem is how to get the relevant div into the page, not how the div should look.

  10. I’ve been monkeying around with manage-viewlets a bit the last few weeks and I’ve got one version that displays like the normal Plone ui with viewlet info being overlaid when hovering over a viewlet. I think that’d at least get us partway there…

    The problem I’m running into is that certain elements are laying over top of others due to css positioning (like the logo’s containing div sitting on top of the site tools and search box). Can we, with javascript and css, accurately select a specific element of the current page?

  11. But how do you get that code onto the page, without modifying any templates? That is still my question.

  12. Well, for this project, the manage-viewlets template is wrapping each viewlet in a div with a kss-attr class that includes a hashed verison of the viewlet name, interface, and viewlet manager. That lets me do lookups in the Python code that the KSS calls.

    Don’t know how we’d do that for things like Archetypes fields…

  13. Doesn’t that mean that each view you want this support on needs to be overriden?

    That’s not feasible, and it is rather intrusive. 🙂

  14. Hmm.. Well, actually the AT templates are adding kss-attrs…

    For example, the “text” field in a document has: “kssattr-atfieldname-text kssattr-templateId-widgets/rich kssattr-macro-rich-field-view”, so right there, we know exactly what field in the object is being shown.

  15. I still don’t understand how it works. Try to explain it to me like I’m five years old.

  16. Sorry, I’m thinking out loud and not being particularly clear. I’m focusing mainly on the front-end of this thing, figuring out how the html can designate what’s what.

    If you look at the html source of the front page of a Plone site (an ATDocument), you’ll see that the Archetypes fields have class names defined that start with “kss-attr”. Those are variables that can be passed along to KSS. So the main body text div has a class name defined: “kssattr-atfieldname-text” (so that’s saying “this is a KSS variable, named ‘atfieldname’ and the value is ‘text'”). Now that we know where the name of the field the content of that div is coming from we can do some lookups to find out more about it.

    Portlets do the same thing, hashing their name (and some other things that I can’t recall at the moment), which would allow us to do similar lookups. Viewlets should do the same thing, I suppose.

    So, right there, we’d have access the current content object, the fields being displayed, the portlets, and the viewlets. That’d at least get us off to a good start.

  17. “I’m focusing mainly on the front-end of this thing, figuring out how the html can designate what’s what.”

    And I still don’t understand how the backend is supposed to work.

    “Now that we know where the name of the field the content of that div is coming from we can do some lookups to find out more about it.”

    What is “we” in this context?

  18. Apologies. I’ve been thinking of the inspector tool as a Firebug-like click-something-and-tell-me-what-it-is style tool. After rereading your post (and please correct me if I’m wrong here), you’re aiming for a series of pages to show much more than that.

    Regardless, I’ve done a quick little product to show what I was getting at if you’re interested:

  19. That would indeed also be a very useful thing to have!

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: