WebFront

A system which pulls data from Google Sites, compiles it all into a single XML DOM, and then processes it using XSL by whatever stylesheets were downloaded; it evolved from several attempts to create a CMS aggregation service or tool. Previous incarnations went by the names WeatherFall and FanSiter.

The code which is checked into ObremSDK is currently a PHP script.

Slugs

I borrowed the term slug from WordPress where it indicates the relative portion of a URL identifying a post. In WebFront, the site has a slug which is determined by the top-level page name being used to generate the site. Each page, file, and list in the site also has a slug which the XSL then usually uses to create the final file name. The root page's slug is always an empty string, because it is a special index entry.

Site XML

The site XML is passed through XSL which then determines what files with what names to output. Only <file> nodes are saved by the script. Here is the general structure of the XML:

<site>
  <page slug="" name="" kind="">
    <data type="xml">...</data>
  </page>
  <file slug="" name="" kind="" href="" updt="" mime="" conv="">
    <data type="txt">...</data>
  </file>
  <list slug="" name="" kind="">
    <data type="...">...</data>
    <item col1="" col2="" />
    <item col1="" col2="" />
  </list>
</site>

All child elements of site may have one or more <data> child node, and their attributes are common as well:

• slug: See WebFront#Slugs.
• name: Page/list title or file name.
• kind: Google Sites template (webpage, announcementspage, announcement, listpage, attachment).
• href: URL of source data.
• updt: Unix-style timestamp (integer).
• mime: Optional MIME / Content type of data.
• conv: Optional MIME type to convert data to. See WebFront#Conversions.

Any child data of <file> will take precedence over the @href, but otherwise that URL is downloaded to @name. Note that initially when the site is being generated those child elements are non-existent which means a XSL processor may utilize the downloaded file as a base in its processing. The <data> nodes have a @type parameter which must be either "txt" (use textContent of node) or "xml" (use innerXML of element).

Lists are the same as pages except they also have <item> child elements. Each one of these is basically a row and each one should have the same attributes as its siblings, representing the column names and values. It's possible, though unlikely, that a change to column names during processing will cause them to be off. A list is created when the page template in Google Sites is set to, drum roll please, list!

Meta Data

In addition to the common attributes mentioned in the previous section, any site part (page, file, or list) may have arbitrary meta data in the form of other attributes. Usual meta data attributes are keywords, description, author, and date.

Conversions

The <file> element's @conv attribute allows for files to be converted between types. This is highly dependent on the script's capabilities to distinguish content types and translated them and always requires @mime to have been set as well. Here is a current list of possible conversions:

• svg / ico / png / gif / jpg => png / gif / jpg / ico

SVG support is minimal / experimental and uses my own svg.php module. I decided against ImageMagick (the convert command-line utility) because many hosting services (such as MediaTemple, what I use currently) have an ancient version that does a terrible job on things I need like preserveAspectRatio.

Finally, the @name must be the final filename. For example, if converting from SVG to PNG you'd want the name to have a .png suffix rather than .svg.