Tony Bowden's Radio Weblog:
Updated: 03/05/2002; 15:16:56.

 

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

 
 

05 April 2002

Dynamic META tags in Template Toolkit

Thanks to Jonas Liljegren, I finally found a workaround to a limitation in the Template Toolkit.

I tend to wrap all my templates in a base template, which will add a standard header and footer etc to every page. TT allows you to set META variables in your inner template which will affect how this gets processed.

So, for example, in my default wrapper file I tend to have something like:

   DEFAULT wrapper = template.wrapper or 'wrapper/main_content'; 
   PROCESS components/browser_title;
   PROCESS components/header;
   PROCESS $template WRAPPER $wrapper;
   PROCESS components/footer;

This allows the inner content of every page to be wrapped in a certain way (in the main_content wrapper), but be overriden within a given template, by saying:

  [% META wrapper = "wrapper/flibble" %]

However, due to how the version of TT works, this can only contain static text. This causes problems in, for example, my "browser_title" template, which will contain something like:

  <title>[% template.browser_title || "My Site Name" %]</title>

It's fine if I want to set the title of a particular page to "Product Information", but less good if I want to set it to the name of the particular product being passed to that template!

Jonas came up with a useful hack to get around this. He defined a new Interpolate plugin which would, when USEd, translate any template variable starting with a minus sign into a re-evaluated version of that:

package MyPath::Template::Plugin::Meta::Interpolate;
use strict; use base "Template::Plugin";
sub new { my ($self, $context, @params) = @_;
my $template = $context->stash->{'template'};
foreach my $key (keys %{$template}) { next if $key =~ /^_/; my $val = $template->{$key}; if( $val =~ /^-(.*)/ ) { my $src = "[% $1 %]"; $template->{$key} = $context->process($src, {}); } }
return $self; }

Now, in my template, I can do: [% META browser_title = -product.name %]

Perfect for improving the google ranking of all my dynamically generated product pages!

Thanks Jonas.


From the catching up on CSS mailing lists department: CSS Mix and Match classes,  popups without Javascript, and forms without tables.

Wheels Within Wheels

I've been talking to quite a few people about the whole intersection of wikis, blogs and outliners over the last few days.

Bill Seitz, who writes his Blog within a wiki talks about viewing wiki pages as OPML.

Ken MacLeod has created a Blog macro for MoinMoin.

Aaron of Montreal has created OTLML for Outliner Markup to help address some of the perceived shortcomings in OPML.

Chris and Earl over at Vanilla have also been doing some interesting work on WikiLogs.

But, I have to say, a lot of this disturbs me somewhat.

In particular, I'm not convinced by the idea of blogging within a wiki. I think a wiki works best in DocumentMode, where the information is truly collectively owned, and the incremental tweaks of many visitors create a coherent whole. ThreadMode, on the other hand, where each person merely adds their thoughts rather than shaping the collective consensus, makes it much more difficult to follow, with many of the dead-ends, sidetracks, and disagreements that are so prevalent on mailing lists or usenet.

In "conversation mode", weblogs, although a stage removed from mailing lists etc, still require an interested party to follow many avenues of investigation and thought. This is not a bad thing. But a wiki can be more than that. It represents a consensus of opinion (even when there is no consensus!) It's the summary of many conversations. Eventually most ThreadMode wiki pages are expected to be refactored into DocumentMode.

And, in "history mode", weblogs are a useful record of your thoughts and ideas over time. In many ways they should be sacrosanct. Editing an entry from several months or years ago to reflect your current thinking is bad form.

So I'm starting to see almost a progression path - from outline to blog to wiki. It's already happening at one level with some of the people publishing their outlines. Dave Winer promotes thoughts from his instant outline to his Scripting News weblog - presumably ones which he believes deserve a wider readership. The bigger, more widely relevant(?) issues, he writes up into DaveNet pieces, where he can craft more coherent whole articles.

Some people's "end of line" publishing is to a page which enables readers to add comments (ThreadMode). However, by replacing that final step with publishing to a Wiki, in Document mode, you can truly release your thoughts, allowing the community to tweak, adapt and extend your ideas in a wholly different way. This is the power of a wiki.

But, to twist back to the beginning, I'm starting to see real value in wiki pages, once settled in Document Mode, being expressed as outlines. The ability to see the main points at a glance, and drill down for the information you want, is invaluable.

So, in some ways, an outline is both the best start point and the best end point. But to make that progression I believe that the information needs to be freed from the inherent constraints of outlining.

I'm sure there are parallels for this elsewhere, but I can't think of any right now ...




© Copyright 2002 Tony Bowden.



Click here to visit the Radio UserLand website.

 


April 2002
Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Mar   May