Re: [Templates] EtText 2 TT2? (Std widget library/api)
On Tue, 11 Jun 2002, Andy Wardley wrote: On Sat, Jun 08, 2002 at 03:51:54PM -0700, Bryce Harrington wrote: Has anyone developed a listing of standard macro-names (i.e., and API) for common template-toolkit snippets (i.e. widgets)? Kind of. The HTML and Splash template libraries achieve something like this. Although it's an ad-hoc standard, it is at least a reasonably well-defined interface to code against. ... The TT docs (in the 'docs' directory) are an (ugly) example of this. You can go and tweak the templates in docs/lib and build the documentation in a different style if you like *Nod* Okay, sounds like the direction I want to go. In fact the splash skinning approach has been sort of an inspiration for me on this. I guess the way I'd like to see this extended is to have a standardish TT2 skin API that I could make ettext (or other wiki-like converters) speak in. This way, one could write the site's contents in an arbitrary kind of structured text, convert it into this neutral templated language, and then apply the look and feel template skin atop it. Sort of CSS-by-brute-force but more flexible. I will research and try to think about how I can extract/derive a general process/mechanism for writing converters like these, and spec up a skin-neutral TT2 syntax they can output to. Looks like some really good ideas are being explored. There are all sorts of useful widgets like this that should be part of the HTML, Splash, or some other library, but aren't. It's easy to add new widget templates, but we're starting to hit a complexity barrier with the current approach. The Splash! templates, for example, already contain way too many code-like directives that should really be handled by a plugin, or better yet, a view. Could you elaborate on this? I saw some references in going through the mail archives about where one should draw the line between doing it in TT2 vs. Perl. Is there a pointer to something that expresses your official philosophy for TT2 with respect to what should be done in template syntax vs. what ought to be in code? It also allows me to define all my metadata and document structure information in one place (a blechXML/blech file) and then process this to build various index pages, navigation components, menus, etc., automagically. This is very cool. WebMake does things similarly (tho I think TT2 is better on the extensibility front). I investigated using WebMake with TT2 as a general purpose build driver (my needs were more sophisticated than ttree could do), but ended up rolling my own cobbled together build system. Hmm, yet another area I'd like to explore further some day. Have you looked into WebMake or other existing build tools for features to add (or replace) ttree? I take it most people end up crafting something to suit their particular needs when they outgrow ttree? Stas Bekman had taken the issue of building document sets a good few steps further for the modperl 2 docs. A script then walks the directory, examining the config files, scanning directories, processing and copying files, and doing all sorts of other magic to build a final document system, complete with navigation, menus, etc. Hmm, interesting, yeah I should like to look into that. I wrote up a similar system myself that we use at OSDL but it's way too kludgy to be of general use yet, and have been intending to find a more general purpose solution for quite some time now. (Our driving requirement was to be able to easily build test and development versions of the site, and be able to build the site on one machine (behind the firewall) and rsync it out to production machine.) Cool, okay thanks; this gives me lots of meat to chew on. Bryce
Re: [Templates] EtText 2 TT2? (Std widget library/api)
On Sat, Jun 08, 2002 at 03:51:54PM -0700, Bryce Harrington wrote:
Has anyone developed a listing of standard macro-names (i.e., and API)
for common template-toolkit snippets (i.e. widgets)?
Kind of.
The HTML and Splash template libraries achieve something like this.
For example:
[% PROCESS splash/menu
buttons = [
{ link = 'buttons.html', text = 'Buttons' }
{ link = 'menus.html', text = 'Menus' }
{ link = 'tabs.html',text = 'Tabs'}
]
%]
Check out stonehenge.com which Randal has recently relaunched with a
Splash interface. Although it's an ad-hoc standard, it is at least
a reasonably well-defined interface to code against. When he wants
to change the look and feel, Randal can create a new set of widget
templates that conform to the same interface and shouldn't have to
touch any of his content pages.
What I'm thinking of is a system where an end user can submit content in
lightly-formatted plain text and instead of converting it directly to
HTML (via ettext2html), runs it through one of a set of processors that
can convert it to a standardish TT2 syntax, and then use template
toolkit to render the HTML using a site-specific TT2-based style macro
library.
The TT docs (in the 'docs' directory) are an (ugly) example of this.
They're built from a gnarly and knobbly mish-mash of Pod, XML, templates
and various other bits and pieces (in 'docsrc', a separate bundle available
from the web site). What you end up with in 'docs' are a set of templates
which get processed at 'make' time to build the final document set. You
can go and tweak the templates in docs/lib and build the documentation
in a different style if you like.
Final processing is done by ttree which simply walks the
directory and processes each page. All the navigation elements, menus,
etc., are implemented as templates. The source pages include directives
like this that get generated by some insidious code in the docsrc
processing script and generating templates:
[% WRAPPER ndx %]
[% WRAPPER ndxitem
link='Tutorial/index.html'
name='Tutorial'
title='Template Toolkit Tutorials'
-%]
This section includes tutorials on using the Template Toolkit..
[% END %]
[% WRAPPER ndxitem
link='Manual/index.html'
name='Manual'
title='User guide and reference manual for the Template Toolkit'
-%]
This is the comprehensive user guide and reference manual..
[% END %]
...etc...
[% END %]
The end result is that you get a nice table of contents, and you
can change your 'ndx' and 'ndxitem' templates and re-process to
get a different TOC style.
There are all sorts of useful widgets like this that should be part
of the HTML, Splash, or some other library, but aren't. It's easy to
add new widget templates, but we're starting to hit a complexity
barrier with the current approach. The Splash! templates, for example,
already contain way too many code-like directives that should really be
handled by a plugin, or better yet, a view.
The motivations for building the docs from templates were twofold.
First, and foremost, I wanted to reduce the vast number of places
where chunks of documentation were repeated (e.g. configuration
options which appear in each Template::* module and also in the
Template::Manual::* pages) or conformed to a similar, or even
identical format (e.g. the version, copyright, see also sections).
It also allows me to define all my metadata and document structure
information in one place (a blechXML/blech file) and then process
this to build various index pages, navigation components, menus, etc.,
automagically. It constructs everything as complete POD documents,
adding standard headers and footers, and then Pod::POMs them for
generating the above HTML templates, complete with all the TOC
directives, etc.
There are downsides. The whole system is badly hacked together,
fragmented, fragile, difficult to understand and hard to maintain.
However, I think that's a limitation in this particular implementation,
not in the concept. And despite the limitations, it does make the
job of maintaining the TT documentation much easier (read: possible)
once you know you're way around it (and don't touch anything that
isn't broke :-)
Stas Bekman had taken the issue of building document sets a good few
steps further for the modperl 2 docs. He has built the DocSet module
which allows you to create a directory tree of documents along with
configuration files that specify the structure of each part of the
document system. They can also specify directories to be searched
for files, files to be copied and so on.
A script then walks the directory, examining the config files, scanning
directories, processing and copying files, and doing all sorts of other
magic to build a final document system, complete with navigation, menus,
etc. I've
Re: [Templates] EtText 2 TT2?
On Mon, 10 Jun 2002, Curtis Poe wrote: Along the same vein, has anyone linked TT2 with a structured-text processor like STX or EtText? What I'm thinking of is a system where an end user can submit content in lightly-formatted plain text and instead of converting it directly to HTML (via ettext2html), runs it through one of a set of processors that can convert it to a standardish TT2 syntax, and then use template toolkit to render the HTML using a site-specific TT2-based style macro library. Mabye build on chromatic's Text::WikiFormat? I thought it used TT2, it seems not, but still ... http://search.cpan.org/search?mode=modulequery=Text%3A%3AWiki Ooh, good pointer, I'll play with this. I was just chatting with chromatic about this. Text::WikiFormat is used with the Slash wiki and there should be no problem hooking it up. More detailed info can be found in chromatic's article on this: http://www.onlamp.com/pub/a/onlamp/2002/01/17/slash_plugin.html Very interesting, but unfortunately the inversion of what I'm looking to do - this appears to plug Wiki into TT2, whereas I essentially want to plug TT2 into Wiki. Still, way cool to see work being done along these lines. Thanks guys, I think I'll try to hack together something and post back here when ready, in case anyone else can make use of such a thing. Bryce
Re: [Templates] EtText 2 TT2?
Oops. Only sent this to Richard. I should have sent it to the list. - Original Message - From: Richard Tietjen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 10, 2002 9:08 AM Subject: Re: [Templates] EtText 2 TT2? Message: 1 Date: Sat, 8 Jun 2002 15:51:54 -0700 (PDT) From: Bryce Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Templates] EtText 2 TT2? (Std widget library/api) Along the same vein, has anyone linked TT2 with a structured-text processor like STX or EtText? What I'm thinking of is a system where an end user can submit content in lightly-formatted plain text and instead of converting it directly to HTML (via ettext2html), runs it through one of a set of processors that can convert it to a standardish TT2 syntax, and then use template toolkit to render the HTML using a site-specific TT2-based style macro library. Mabye build on chromatic's Text::WikiFormat? I thought it used TT2, it seems not, but still ... http://search.cpan.org/search?mode=modulequery=Text%3A%3AWiki I was just chatting with chromatic about this. Text::WikiFormat is used with the Slash wiki and there should be no problem hooking it up. More detailed info can be found in chromatic's article on this: http://www.onlamp.com/pub/a/onlamp/2002/01/17/slash_plugin.html Cheers, Curtis Ovid Poe
[Templates] EtText 2 TT2? (Std widget library/api)
Has anyone developed a listing of standard macro-names (i.e., and API) for common template-toolkit snippets (i.e. widgets)? Along the same vein, has anyone linked TT2 with a structured-text processor like STX or EtText? What I'm thinking of is a system where an end user can submit content in lightly-formatted plain text and instead of converting it directly to HTML (via ettext2html), runs it through one of a set of processors that can convert it to a standardish TT2 syntax, and then use template toolkit to render the HTML using a site-specific TT2-based style macro library. The motivation for this is probably pretty obvious: my content submitters don't know HTML and probably wouldn't be bothered to learn TT2 syntax either but do seem to groove on wiki-style syntaxes. Unfortunately, the site uses various stylistic elements for representing headers, data tables, etc. that I do as TT2 macros (marketing is talking about doing a sitewide redesign in the near future, so I need the abstraction). Bryce
