I like especially the customize viewlet bit a lot. I think this bit should go into Plone itself. The other features seem very useful as a development tool.

I think, I misunderstood that post the same exact way you did. A tool like this would go a long way to help show a new skinner, and hopefully other newbies what plone's ui and more are made up of. I'd love to help with this.

Shurik from #plone

Great concept. Looking forward to playing with the beta.

-- siebo

Eric, this is really, really cool! I'm very interested in using this but also (probably equally) interested in taking a look at the code that enables this. is it KSS based? i'm sure that by blogging about the actual development of GloWorm you'd increase its utility even more... just an idea ;-)

cheers,

Tom Lazar

if this is any more than a joke it is great! how on earth did you do this?

This is very cool stuff and exactly what we need. I guess it's a mix of instrumentation and ajax to get this running. If you provide a good API, then it should be simple to integrate it with Firebug or so.

I hope you consider working with Martin Lundwall who got the introspector project in GSoC.

When will we see code :)

Florian Schulze

Sure, I'd be happy to work with him. I completely missed that the introspector was picked up as a GSoC project. Any idea where I could find some contact information for him?

I am also half convinced that this is a cruel joke. :) Or at least, a mock-up rather than functional code. But if it isn't, then this could be the best thing for Plone since the invention of Firebug.

Firebug integration for may be useful for introspection. Maybe it's not worth it, but could make it easier to inspect the page and view Plone-specific things alongside CSS information, for example. Look at FireKiss, the KSS firebug plugin as an example.

I wrote up some notes about introspection earlier. Not all of these may be directly relevant, though. I think we may want to keep the component introspector different from the one that deals with visual elements (views, viewlets, portlets).

""" One of the major hurdles that new integrators face is to discover how the things that they see in the browser fits together with the code they see on the filesystem. Current adapter, utility and event registrations are similarly opaque. To make this work easier, Plone should have an optional tool to inspect a content object or view and discover its underlying structure.

Below are some ideas about what this tool should support

• 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. """

~ Martin

Thanks for the kind words, everyone. Rest assured, this is actual code. :)

The main key behind doing getting this working was the showTAL debug flag in the Zope template renderer. This keeps the TAL code in the final rendered result.

So if you had a template that said:

<div tal:content="string:foo">[some string]</div>

you'd wind up with a result like:

<div tal:content="string:foo">foo</div>

from that point, the rest is just using KSS to get HTML attributes.

The reason that I'm labeling this as a "proof-of-concept" is that Zope loses the request.debug.showtal variable somewhere along the line. I've fixed the code, but until I get it committed to the Zope core and/or write a monkeypatch for it, GloWorm isn't going to work for anyone but me. :(

The viewlet mangement and editing code is taken from my plone.app.viewletmanager branch (http://dev.plone.org/plone/browser/plone.app.viewletmanager/branches/esteele-ui) which is what got me started down this road.

I'll do my best to get an experimental version of product out there this week so that you folks can try it out.

This is brilliant, brilliant, brilliant! Gloworm + Clouseau are power-tools that will actually deliver on reducing the Plone learning

http://drupal.org/themedeveloper is quite interesting as well. gloworm certainly is doing more work under the covers (since zope is using a component architecture). but these are really fantastic mechanisms to lower the bar