GloWorm 0.1-alpha1 now available

Standard rules apply – as this is an alpha release, I reserve the right to laugh and point if you muck up a production site with this product. If you don't know what GloWorm is or would like to see it in action, see my sneak peek.

GloWorm (get the alpha from pypi) requires Plone 3.1.x to run and so far I've only attempted to run it in Firefox (which works beautifully) and Safari 3 (which doesn't quite), but I'll get into that more below.

How it works

The PTTOTPATMMAIS Interface

The main issue with creating a poke-that-thing-on-the-page-and-tell-me-more-about-it-style interface is that we need to provide some way for the HTML bits that make up the page to know which Plone bits went into making them. I mean

<a id="portal-logo" href="http://localhost:8080/plone" accesskey="1">
  <img width="252" height="57" title="Plone" alt="" src="http://localhost:8080/plone/logo.jpg"/>
</a>

gives us a bit of a clue, but really doesn't tell us where this code came from. The key was finding (and fixing) a well-hidden request flag, 'debug'. REQUEST.debug provides two switches, sourceAnnotations and showTAL. sourceAnnotations sticks comments in the rendered HTML, showing that "this next block of code came from this file, starting at line x." But I haven't quite figured out how that'll be useful or how to get at the values in the first place. These look like:

==============================================================================
file:/Users/ems174/gloworm/parts/plone/CMFPlone/skins/plone_templates/main_template.pt (line 91)
==============================================================================

showTAL is really what made things click. It causes those TAL statements used in Plone's page templates to be included in the HTML sent to the browser. So, the template for portal-logo looks something like this:

<a metal:define-macro="portal_logo"
   id="portal-logo"
   accesskey="1"
   tal:attributes="href view/navigation_root_url"
   i18n:domain="plone">
    <img src="logo.jpg" alt=""
         tal:replace="structure view/logo_tag" /></a>

And with the showTAL flag on, the rendered HTML will look like:

<a metal:define-macro="portal_logo" id="portal-logo"
   accesskey="1"
   tal:attributes="href view/navigation_root_url"
   i18n:domain="plone" href="http://localhost:8080/plone">
    <img src="http://localhost:8080/plone/logo.jpg" alt="" title="Plone" height="57" width="252" /></a>

Now we're getting somewhere! KSS provides the ability to look up html attributes of any page item, and we've just shoved a whole lot of those into the page. A KSS rule like:

*:click {
    evt-click-preventdefault: True;
    ...
    inspectElement-talattributes: nodeAttr(tal:attributes, True);
    ...
}

Will allow us to click on any page element and pass the value of tal:attributes (among other things) along to a Python method that can figure out what to do with it.

Tracking Down the Viewlets

Tracking down which viewlet a bit of HTML belongs to follows mostly the same pattern. Coaxing the ViewletManager rendering method to spit out <tal:viewlet> tags around each viewlet, which now show up in the HTML source thanks to showTAL, those same KSS methods can allow us to identify the containing viewlet. In this case, I'm assigning each tal:viewlet element a kssattr-viewlethash class name which can be found by using the kssAttr call. viewlethash is a big long string of junk made by smashing together all of the values needed to do a queryMultiAdapter lookup to get the viewlet itself, similar to the way kssattr-portlethash is used in plone.app.portlets.As far as the show/hide and inline editing, that's nothing particularly new, thanks to the folks that made plone.app.customerize and plone.app.viewletmanager. 

How it Doesn't Work

All of that being said... this is still really rough code. GloWorm has some big holes that need to be...filled?...whatever you do to holes in a product...

Monkeypatching

GloWorm installs 2 monkeypatches: One to fix the bug in Products.PageTemplates.PageTemplate.pt_render which should hopefully be fixed in a future Zope (I've submitted a patch). The other is to override plone.app.viewletmanager's render method to add those <tal:viewlet> blocks. Which brings me to...

ViewletManager adaptation

By all that is good and holy, how does one properly adapt one of Plone's viewletmanagers? Much of the last two weeks was spent beating my forehead against any more-or-less horizontal surface over this bit. I can adapt a Products.Five.viewlet.manager.ViewletManagerBase, but not one of plone.app.viewletmanager's and as far as I can tell the two have nothing in common. What gives?

Cross-browser compatability

As I mentioned at the top, this breaks in Safari 3. Probably others as well. The sad part is that it's working right up to the point where it tries to write the inspection output back to the GloWorm panel because it can't find the proper CSS selector. Which is probably caused by...

Invalid HTML

I've got two <html> blocks in the @@inspect view. Because i'm trying to...

Include the current context

@@inspect was intended to show the page it was called on, plus the GloWorm panel. Hey, I figured, that'll be simple. I'll just create a viewlet that'll sit in plone.portalfooter and say it's only for this view. But as soon as I use a <html tal:replace="structure context" />, *poof*, my page loses all track of the interfaces that @@inspect provides. So, for the time being, I'm forced to slap some stuff onto the end of the page, outside of the <html> block. Fantastic.

Next Steps

If you've made it this far, you're the kind of person I want to be talking to. The above issues are major sticking points and I'm out of ideas. I think this product, or a descendant of it at least, can work, and can be great for Plone. I'm looking for ideas, suggestions, collabroators, and code. Leave a comment, drop me an email at EricSteele @ psu dot edu or find me on IRC (esteele). I'd be happy to go into more detail about any bit of what's here, what isn't, and what should be.Happy PTTOTPATMMAIing!

Eric Steele