Padre::Plugin::WebGUI Tab Icons

Version 0.03 of Padre::Plugin::WebGUI (my WebGUI plugin for the Padre Perl IDE) is on its way to the CPAN, with one small but rather nice feature: tab icons. Just as the plugin uses WebGUI’s native icons to display the Asset Tree for your site, you now get the same attractive icon in the tab that opens up when you double-click to edit something. Apart from the aesthetics, it’s handy to know at a glance what sort of asset you’re editing (WebGUI uses the same trick for the edit icons on your site when you turn admin mode on). I was hoping to be able to add hover-text too (in case you don’t recognise the Asset type from its icon) but thus far I haven’t figured out if wxPerl and/or Padre supports it.

The following screenshot shows a nice example of several tabs open at once with different WebGUI Asset types displaying their own icons.

Tab_Icons

Padre::Plugin::WebGUI now with remote editing

Up until now the WebGUI Padre plugin I’ve been working on has been more or less a proof-of-concept / toy / test-bed for experimental ideas. Whilst that has been fun (and made for good conference slides), the reality is that I haven’t actually been using the plugin for my daily WebGUI development, so how could I expect other WebGUI developers to do so?

I’m hoping to change that. As of today I’ve stripped out all the experimental features and concentrated on the single feature that seems to have the widest possible appeal, namely, remote editing.

Version 0.02 of Padre::Plugin::WebGUI, which is on its way to the CPAN, allows you to connect over HTTP to your webgui site, view you asset tree and edit your assets from inside the Padre text editor. That hopefully makes it as useful for designers and content managers as it is for developers.

Previously the plugin got most of its power from the WGDev library. However this meant that you had to install WebGUI and WGDev as a prerequisite. Given that the WRE ships with non-threaded perl, this meant either installing these prereqs into your system perl or building another perl specifically to run them. Not an overly arduous task, but enough of a hurdle to dissuade most WebGUI developers from playing with the plugin. That obstacle has now been removed. You do not need to have WebGUI or WGDev installed to run the plugin.

Using WGDev also meant that you could only connect locally to your site. That restriction is now gone.

Installation

Firstly, install Padre.

To allow your WebGUI site to talk to the plugin, add this content handler (WebGUI::Content::Padre) to your site and restart modperl (the easiest way to do this is to drop the module into your /data/WebGUI/lib/WebGUI/Content dir and add the new content handler to your site config file. There is also an install script that will do the site config editing for you).

Next install the plugin from the CPAN


cpan Padre::Plugin::WebGUI

Usage

Inside Padre, go to the Plugin Manager and enable the WebGUI plugin. You should then see a WebGUI item appear in your Plugins menu.

From the WebGUI menu, tick “Show Asset Tree” and double-click on “Connect” in the new panel that appears.

connect

You will be prompted for the URL of the site you want to connect to. Currently you need to enter you the site in the form: http://username:password@site.com (later we will add a site manager to make this nicer). Remember that this can be any webgui site that you have access to, not just a local site.

connect2

You will then see the Asset Tree dynamically populated with information from your site.

asset_tree

Try double-clicking on an article.

getting_started

A new file tab should open with the name set to the name of your article (with [wg] prepended). The article content will be loaded into to tab, with Padre’s HTML syntax highlighting in effect. If you have Padre::Plugin::HTML installed, you can use the Tidy/Lint/Validate the HTML to your heart’s content. And every time you hit Save, your changes will be pushed up to the site as a new Version Tag.

look_ma

Try double-clicking on another sort of asset, for instance a Template. Once again, the template html will be loaded into a new tab with nice syntax highlighting.

template

And for fun, try opening up a CSS Snippet. The plugin will detect that your snippet is set to the ‘text/css’ mime type and use CSS code highlighting instead of HTML.

css

And similarly for JavaScript Snippets.

javascript

Design and Extensions

As far as Padre is concerned the file you are editing is just a regular file on your file system. For example when you edit the text, an asterisk (*) appears next to the name of the file indicating that you haven’t save it yet. The integration between the webgui content handler and the plugin is minimal, meaning that you could conceivably use this plugin to do remote editing on non-webgui sites too.

Padre has a nice architectural design, which makes it really easy for us to associate different WebGUI::Asset types with Padre::Document types. Currently most assets delegate to the default Padre::Document::WebGUI::Asset module which does HTML syntax highlighting and expects only generic content from the content handler running on your site. Padre::Document::WebGUI::Snippet has a slightly higher IQ level in that it asks the server to tell it what mimetype the asset is set to, so that it can use the appropriate syntax highlighter.

We could do some really interesting things by building asset-specific Padre::Document modules. For instance you could build a document type that uses fancy wxWidgets controls to do things that aren’t possible on the web (desktop integration etc..) And it’s just as easy to build these for your own custom asset types as it is for core ones. Given that Padre is cross-platform, you’re basically looking at a way of extending WebGUI interactions out into desktop-land.

If you’re a WebGUI designer/developer/content manager and you want to start playing with Padre::Plugin::WebGUI as a novel way of editing content, come find me on #webgui or #padre.

Finding missing WebGUI Templates

Following on from my previous WGDev post, here’s another example of wgd ls that lets you find missing Templates on a WebGUI site.

One problem that content managers run into is that after deleting a template in WebGUI, any assets that still refer to the template will die a horrible death when users try to view them. What would be nice is an automated way of finding all such assets that refer to missing template, so that you can update them to refer to a different template.

For starters, WGDev can give you a list of all available templates on your site via:


wgd ls root -r --format %assetId% --includeOnlyClass WebGUI::Asset::Template | sort | uniq > available

You can also ask for a list of all in-use templateIds, via:


wgd ls root -r --format %templateId% --filter '%templateId% ~~ /.+/' | sort | uniq > in_use

All you need to do then is ask the comm command to tell you which templateIds are in_use but not available:


comm -23 in_use available

Putting it all together on one line (without the temporary files), that becomes:


comm -23 <(wgd ls root -rf %templateId% --filter '%templateId% ~~ /.+/' | sort | uniq) <(wgd ls root -rf %assetId% --includeOnlyClass WebGUI::Asset::Template | sort | uniq)

The output of this command is a nice list of missing templateIds.

Of course, what you probably then want to do is ask WGDev to give you a list of asset urls that are trying to use these missing Templates, for example, if one item in your list is eHMsLCMqoXYpYrsZ7CWUtg, you would do:


wgd ls root -rf %url% --filter '%templateId% ~~ eHMsLCMqoXYpYrsZ7CWUtg'

Which would print something like


/my/broken/asset/url

Combining this with the previous command to do it all on one line is left as an exercise for the reader ;)

Now, templateId isn’t the only Asset field that templates can be referenced under, for example, if you want to also find missing Style and Printable Style templates, you’d want to do something like:


for tmpl in templateId styleTemplateId printableStyleTemplateId
do
comm -23 <(wgd ls root -rf %${tmpl}% --filter "%${tmpl}% ~~ /.+/" | sort | uniq) <(wgd ls root -rf %assetId% --includeOnlyClass WebGUI::Asset::Template | sort | uniq)
done

It’s not optimised for speed, but it sure is handy. And you could apply the same approach to search for invalid group permissions, etc.. Of course if you found yourself doing this often you’re probably better off writing a dedicated WGDev plugin to wrap up the functionality.

There’s a WebGUI branch on GitHub containing some extra Template Usage-related functions – the plan is to add the ability to find all the different ways that templates are referenced (in Asset definitions, Account module definitions, …) so perhaps we will end up adding a “find missing Templates” button to the Edit Template page.

[ perl ironman ]

Ode to wgd and the command line

Doug just posted an ode to the Linux command line over at the Plain Black staff blog.

I’ve been getting a lot of joy out of the command line today too thanks to Graham’s ridiculously useful WGDev. One wgd command that I only started using in earnest today is the ls command. In its most basic form, it lets you print out a list of assets on your site:


$ wgd ls /home

getting_started
your_next_step
the_latest_news
tell_a_friend
documentation
site_map

I added a bunch of extensions to ls today, the first one being a -r option that tells ls to recursively list assets. Given that this prints to STDOUT, you can pipe this into any other command line tool to manipulate the output. For example, to list all assets that have the word “you” in their menu title:


$ wgd ls /root -f "%menuTitle%" -r | grep -i you
Profile Account Layout
Inbox Account Layout
Friends Layout Template
Account Layout
Shop Account Layout
Contributions Layout
Default Account Layout
Layout
Your Next Step

(the -f “%menuTitle%” option above tells the command to output only the menuTitle property of each asset).

Under the hood ls is calling asset->getLineage(), so I exposed a few of the getLineage API options to ls.

For example, this is one way of getting a sorted list of Survey templates on your site:


$ wgd ls root -r --includeOnlyClass WebGUI::Asset::Template -f "%url% %namespace%" | perl -ane 'print "$F[0] ($F[1])\n" if $F[1] =~ m/survey/i' | sort
root/import/expireincompletesurveyresponses/expireincompletesurveyresponses (ExpireIncompleteSurveyResponses)
root/import/survey/default-answer-edit (Survey/Edit)
root/import/survey/default-feedback (Survey/Feedback)
root/import/survey/default-gradebook-report (Survey/Gradebook)
root/import/survey/default-overview-report (Survey/Overview)
root/import/survey/default-question-edit (Survey/Edit)
root/import/survey/default-questions (Survey/Take)
root/import/survey/default-section-edit (Survey/Edit)
root/import/survey/default-survey-edit (Survey/Edit)
root/import/survey/default-survey-summary (Survey/Summary)
root/import/survey/default-survey (Survey)
root/import/survey/default-survey-take (Survey/Take)
root/import/survey/default-test-results (Survey/TestResults)

While I was writing this post, Andy asked me to provide him with a list of all Carousel wobjects on a site we’re working on. That’s as easy as:


$ wgd ls -r root --includeOnlyClass WebGUI::Asset::Wobject::Carousel

The most useful option I added to ls is the –filter smartmatch filter option. This option filters the results using an asset property of your choosing. Format looks like “%url% ~~ smartmatch”, where “url” is the field to filter against, and “smartmatch” is either a Perl regular expression such as “/(?i:partial_match)/” or a string such as “my_exact_match”.

For example, the following command lists all templates that include absolute urls. We generate the output to an html file so that someone can easily open all the links and manually review/remove the absolute urls:


$ wgd ls -r /root --filter "%template% ~~ /http:///" --includeOnlyClass WebGUI::Asset::Template --format "<a href=http://dev.localhost.localdomain/%url%?func=edit>%url%</a><br>" > links.html

links.html then contains:

<a href=http://dev.localhost.localdomain/style_01?func=edit>style_01</a><br>
<a href=http://dev.localhost.localdomain/style_02?func=edit>style_02</a><br>
<a href=http://dev.localhost.localdomain/style_03?func=edit>style_03</a><br>

...

One type of command that I can see myself using a lot in the future is the following, which displays all assets that are viewable to a specific group (in this case the “Turn Admin On” group, which has an id of “12″):


$ wgd ls -r root --format "%groupIdView% %url%" --filter "%groupIdView% ~~ 12"
12 root/import/newsletter
12 root/import/projectmanager/resource
12 root/import/wiki

Alternatively, you can use a variation of the above to list all assets that are NOT viewable to a certain group (or groups). This is great for finding assets that have accidentally been set to say, Admins, when you want them viewable by Registered Users. For example, the following command lists assets that are not viewable to the default “Visitors”, “Everyone”, or “Registered Users” groups:


$ wgd ls -r root --format "%groupIdView% %url%" | perl -ane 'print "$F[0] $F[1]\n" if !grep {$F[0] eq $_} qw(1 2 7)'
12 root/import/newsletter
12 root/import/projectmanager/resource
12 root/import/wiki

All of these commands take in the order of 1 second to run, which is a lot less time consuming than manually reviewing your site asset-by-asset. And if you incorporate them into your test suite, you can re-verify their output against your site policy/expectations whenever you like.