In our first example,
we want to perform simple text substitution on the HTML template document.
The HTML file html/hello_world.htm has klass attributes which serve as compiler (kompiler?) hints to Seamstress:

When looking at HTML::Seamstress, we are looking at a uniquely positioned 4th-generation HTML generator. Seamstress offers two sets of advantages: those common to all 4th generation htmlgens and those common to a subclass of HTML::Tree.

Monks,
I'm tired of writing meta code in templating languages.
I'm really good at writing Perl, and good at writing HTML,
but I'm lousy at the templating languages (and I'm not too
fired up to learn more about them).

There is nothing guaranteeing that open tags will match close tags or that close tags will even exist. To make the correspondence between open and close tags even more troublesome, they are in different files. And it is not easy for an HTML designer and/or design tool to manipulate things once they have been shredded apart like this.

With the tree-based approach of Seamstress, the end tag will exist and it will match the open tag. Well-formedness is job 1 in tree-based HTML rewriting!

Software engineers refer to this as orthogonality. The contents of the document remain legal HTML/XML that can be be developed using standard interactive design tools. The flow of control of the code remains separate from the page. Technologies that mix content and data in a single file result in code that is often difficult to understand and has trouble taking full advantage of the object oriented programming paradigm.

The book "Godel, Escher, Bach: An Eternal Golden Braid" by Douglas R Hofstadter makes it clear what it means to operate at object-level as opposed to meta-level. When you buy into earlier-generation HTML generation systems you are working at object-level: you can only speak and act as the HTML with no ability to speak about the HTML.

Compare a bird's eye view of a city with standing on a city block and you have the difference between the 4th generation of HTML development versus all prior generations.

If you have a strong hold on object-oriented Perl and a solid understand of the tree-based nature of HTML, then all you need to do is read the manual pages showing how Seamstress and related modules offer tree manipulation routines and you are done.

Extension just requires writing new Perl methods - a snap for any object oriented Perler.

Class-based object-oriented programming makes use of inheritance and other techniques to achieve maximum code reuse. This typically happens by a certain base/superclass method containing common actions and a derived/subclass/mixin method containing extra actions.

A genuine tree-based approach (such as HTML::Seamstress) to HTML generation is supportive of all methods of object-oriented reuse: because manipulator and manipulated are separate and manipulators are written in oo Perl, we can compose manipulators as we please.

This is in contrast to inline simple object systems (as in Mason) and also in contrast to the if-then approach of tt-esque systems.

We have solved our problem. However, we can create even more re-use because the both of these classes are very similar. They only vary in 2 things: the particular head and body they provide. You can abstract this with whatever methodmaker you like. I tend to prefer prototype-based oop over class-based, so with Class::Prototyped, here's how we might do it:

A tree of HTML usually contains subtrees with no inter-dependance. They therefore can be manipulated in parallel. If a page contains 5 areas each of which takes N time, then one could realize an N-fold speedup.

The real world is unfortunately more about getting HTML to work with IE and maybe 1 or 2 other browsers. Strict XHTML may not be acceptable under time and corporate pressures to get things to work with quirky browsers.

If you know object-oriented Perl and know how to rewrite trees, then everything that Seamstress offers will make sense: it's just various boilerplates and scripts that allow your mainline code to be very succinct: think of it as Class::DBI for HTML::Tree.

unifying HTML and the HTML processing via a Perl class

Seamstress contains two scripts, spkg.pl and sbase.pl which together make it easy to access and modify an HTML file in very few lines of startup code. If you have a file named html/hello_world.html, Seamstress makes it easy for that to become the Perl module html::hello_world with a new() method that loads and parses the HTML into an HTML::Tree.

a Catalyst View class with meat-skeleton processing

The meat-skeleton HTML production concept is discussed below. Catalyst::Seamstress::View is all ready to go for rendering simple or more complex pages.

Let's see why this is a good idea. In Mason, your Perl and HTML are right there together in the same file. Same with Template. Now, since Seamstress operates on the HTML without touching the HTML, the operations and the HTML are not in the same file. So we create a Perl module to glue the HTML file to the operations we plan to perform on it.

This module (auto-created by spkg.pl and perhaps sbase.pl) has a constructor new(), which grabs the HTML file and constructs an HTML::Element tree from it and returns it to you.

It also contains a process() subroutine which processes the HTML in some way: text substitutions, unrolling list elements, building tables, and whatnot.

Finally, it contains a fixup() subroutine. This subroutine is designed to support the meat-skeleton paradigm, discussed above. The process() subroutine generated the $meat. After <$meat> has been placed in $skeleton, there may be some page-specific processing to the whole HTML page that you want to: pop in some javascript, remove a copyright notice, whatever. That's what this routine is for.

Now that I've said all that, please understand that you are perfectly free to call new() and do what you want with the HTML tree. You don't have to use process() and fixup(). But they are there and are used by Catalyst::View::Seamstress to make meat-skeleton dynamic HTML development quick-and-easy (and non-greasy).

HTML pages typically have meat and a skeleton. The meat varies from page to page while the skeleton is fairly (though not completely) static. For example, the skeleton of a webpage is usually a header, a footer, and a navbar. The meat is what shows up when you click on a link on the page somewhere. While the meat will change with each click, the skeleton is rather static.

So, nothing about this is forced. This is just how I typically do things and that is why Catalyst::View::Seamstress has support for this.

In all honesty, the meat-skeleton paradigm should be supported here and called from Catalyst::View::Seamstress. But the problem is, I don't want to create an abstract API here unless I have used the meat-skeleton paradigm from one other framework besides Catalyst. Then I will have a good idea of how to refactor it so any framework can make good use of the paradigm.

The best example of usage is the Quickstart directory in this distribution. You can read HTML::Seamstress::Quickstart and actually run the code in that directory at the same time. After doing so, the following sections are additional instruction.

The first thing to remember is that Seamstress is really just convenience functions for HTML::Tree. You can do entirely without Seamstress. It's just that my daily real-world obligations have lead to a set of library functions (HTML::Element::Library) and a convenient way to locate "templates" (spkg.pl) that work well on top of HTML::Tree

move spkg.pl and sbase.pl onto your execution $PATH

sbase.pl and spkg.pl are used to simplify the process of parsing an HTML file into HTML::Treebuilder object. In other words instead of having to do this in your Perl programs:

The lines of code is not much different, but abstracting away absolute paths is important in production environments where the absolute path may come from who knows where via who knows how.

run sbase.pl

sbase.pl will ask you 2 very simple questions. Just answer them. When it is finished, it will have installed a package named HTML::Seamstress::Base on your @INC. This module contains one function, comp_root() which points to a place you wouldn't typically have on your @INC but which you must have because your HTML file and corresponding .pm abstracting it are going to be there.

run spkg.pl

In the default seutp, no options need be supplied to this script. They are useful in cases where you have more than one document root or want to inherit from more than one place.

In a mod_perl setup, you would want to pre-load your HTML and Class::Cache was designed for this very purpose. But that's a topic for another time.

In a setup with HTML files in numerous places, I recommend setting up multiple HTML::Seamstress::Base::here, HTML::Seamstress::Base::there for each file root. To do this, you will need to use the --base_pkg and --base_pkg_root options to spkg.pl

That's it!

Now you are ready to abstract away as many files as you want with the same spkg.pl call. Just supply it with a different HTML file to create a different package. Then use them, new them and manipulate them and $tree->as_HTML them at will.

First save this somewhere on your document root. Then compile it with spkg.pl. Now you simply use the "compiled" version of HTML with API calls to HTML::TreeBuilder, HTML::Element, and HTML::Element::Library.

Table unrolling, pulldown creation, li unrolling, and dl unrolling are all examples of a tree operation in which you take a child of a node and clone it and then alter it in some way (replace the content, alter some of its attributes), and then stick it under its parent.

Functions for use with the common HTML elements --- <table>, <ol>, <ul>, <dl>, <select> are documented in HTML::Element::Library and are prefaced with the words "Tree Building Methods".

Beyond the "compilation" support documented above, Seamstress offers nothing more than a simple structure-modifying method, expand_replace(). And to be honest, it probably shouldn't offer that. But once, when de-Mason-izing a site, it was easier to keep little itty-bitty components all over and so I wrote this method to facilitate the process.

In this case, the content of each sideBlock is the name of a Perl Seamstress-style class. As you know, when the constructor for such a class is called an HTML::Element, $E, will be returned for it's parsed content.

In this case, we want the content of the div element to go from the being the class name to being the HTML::Element that the class constructs. So to inline all 3 tags you would do the following;

This does the same thing as the TreeBuilder new_from_file() method, but it blesses the object into the invocant class. This makes the invocant class derive from Seamstress which means it has HTML::TreeBuilder, HTML::Element , and HTML::Element::Library at its disposal.

The 3rd generation solutions embed programming language constructs with HTML. The language constructs are either a real language (as is with HTML::Mason) or a pseudo/mini-language (as is with PeTaL, Template or HTML::Template). Let's see some Template code:

The fourth generation of HTML production is distinguished by no need for tampering with the HTML. There are a wealth of XML-based modules which provide this approach (XML::Twig, XML::LibXML, XML::TreeBuilder, XML::DOM). HTML::Seamstress is the one CPAN module based around HTML and HTML::Tree for this approach.

The fourth generation is also the way that a language like Javascript rewrites HTML. By using Seamstress, you can always think about manipulating your HTML in the same way!

Based on Zope's TAL, this is a very nice and complete framework that is the basis of MkDoc, a XML application server. It offers a mini-language for XML rewriting, Seamstress does not. The philosophy of the Seamstress is the orthogonal integration of Perl and HTML not a mini-language and HTML.

If I wanted to ape XMLC entirely, I would have used TJ Mather's XML::DOM. Because XMLC is based around DOM API calls. However, TreeBuilder is very handy and has a lot of nice libraries around it such HTML::PrettyPrinter. The biggest win of XML::DOM is it's easy integration with XML::Generator

From the docs, it looks like XML::GDOME is the successor to this module.

But the most cogent argument for using full-strength languages as opposed to mixing them occurs in the Text::Template docs:

When people make a template module like this one, they almost always
start by inventing a special syntax for substitutions. For example,
they build it so that a string like %%VAR%% is replaced with the
value of $VAR. Then they realize the need extra formatting, so they
put in some special syntax for formatting. Then they need a loop, so
they invent a loop syntax. Pretty soon they have a new little
template language.
This approach has two problems: First, their little language is
crippled. If you need to do something the author hasn't thought of,
you lose. Second: Who wants to learn another language? You already
know Perl, so why not use it?

And for the Mason users whose retort is "we do use Perl!" the obvious reply is: "granted, but in an embedded fashion with ad hoc, inflexible object mechanisms, non-tree-based (hence syntactically suspect) HTML manipulation, and no ability to statically validate the Perl or HTML"

HTML_Tree is a C++ HTML manipulator with a Perl interface. Upon using his Perl interface, I began to notice limitations and extended his Perl interface. The author was not interested in working with me or my extensions, so I had to continue on a separate path.