Although aTbRef originally evolved as a way to share extra information about Tinderbox and to explore what could be achieved using HTML export, the project has continued to explore methods of using features, even if they aren't exported. If you have the TBX look at (note that many of this page's links only work in the TBX as their targets don't export):
- Splitting content from the back-of-house notes. Visible data of the web site is created by exporting the first root note "A Tinderbox Reference File" and it's contents. Everything else—prototypes, templates, boilerplate code, etc.—is stored outside the 'content' area. The two pools of data rarely need to be worked on together via agents so splitting the two out makes for more efficient maintenance and upkeep. There are a number of items at root level as this reflects the needs of export. Be aware that tinderbox can't export a note to a relative position other than in its relative (TBX) outline location. Thus if you want all notes to reference a single CSS file it is best tol place that at the TBX root level, etc.
- A map view of note colours. All the predefined Tinderbox colours and their shades. Also used to create an online image. The listing shows the hex values for all the defined colours/shades.
- A map view of shapes, borders and patterns. A map showing various map visualisation aspects. Also used to create an online image.
- Agents to restate major listings. Look at each of the listings of action code, attributes and export codes. Notice how there is a main listing and then this is re-started divided up by scope, purpose, etc. The agent in some cases use colour to make the main list (within the TBX) more visually descriptive as to purpose. Look at $AgentPriority setting which have in some cases been reduced to ease loading of the main update cycle time.
- Controlling agents. In the root-level UTILS section are various upkeep agents, mostly set to 'off' when not needed. An 'all agents' agent allows all such agents to be found and controlled from one location - whether in the content or back-of-house.
- Timelines. Although aTbRef doesn't output timelines, both the Change Log and Previous Versions containers can be viewed as Timelines and will show relevant data. The Previous Versions uses child notes that are not exported.
- Prototypes. These are used mainly for the notes in the 3 big lists, which use a number of special-to-context attributes for their key attributes. An agent-based prototype is used for the per-version change log entries. Setting just the new version number initialises a number of other features.
- Boilerplate code. The export template code is kept less complex as certain common-to-all-pages code is stored as 'boilerplate' and used in templates via ^include()^ code. In the original HTML$ templates this made more sense as there were 5 primary page templates for content, each reflecting some different layouts.
- Images. Whilst image support has varied over Tinderbox versions, aTbRef has deliberately not used embedded images. This both gives more export control (formatting, compression, naming) and allows for a smaller overall TBX. All images are placed in a root level folder and simply the filename is stored in the note, the template figuring out the path. This also allows for the images themselves to be linked to from elsewhere are reference material. Having only one image per note (if any) was a deliberate design choice originally to facilitate template design and may be reviewed in later versions as image support is improved.
- Image Linking. An agent 'Image Linker' has its $File set to the local location of the 'images' folder used to store the images used by webpages (you can adjust it if using your own local TBX copy of aTbRef). All notes using a web image store the image filename in $WebImage. The agent finds these notes and sets their $File to the agent's $File + a / + the note's $WebImage. this correctly sets $file for the note allowing the linked image to be viewed (via Finder) from the TBX. This assumes you have downloaded the images. One small exception is where the Doc-level preferences that repeat App-level ones are alias notes but use a different screen grab (stored in a separate attribute). The latter notes will open their original's image but in the circumstances that doesn't really matter.
- Images and templates. Originally there was a template for 'wide' images, which needed to sit above $Text as opposed to most that could mix with text. In the HTML5 versions this is removed as image inclusion is based on the image attribute and a Boolean landscape/portrait attribute.
- HTML export. All templates used are stored in the TBX in the TEMPLATES container. Originally the export was in HTML4 and used tables. This has been replaced by HTML5, and a resulting reduction in the overall number of page templates. The older set are retained, for comparison - and an still be used to local export. Template and boilerplate code notes with a '5' in their title are for HTML5 use. Compare the old and new versions to see how improvements have been made.
- Conditional includes. The ^similarTo^ code involves more computation for export - with such links included it takes 20 times longer to export the whole site. Thus the boilerplate note used to generate this output has a Boolean to enable/disable the include. Try exporting in each condition and note the difference. Switch now moved to the calling template.
- HTML sitemap. This is a simple envelope/letter technique to map the whole site as a single HTML outline. Far too large an HTML page for real use, this is really just a demo.
- XML sitemap. Use to help Google spider your site more efficiently. The XML is very verbose and creates an 8+MB file. For this reason export of the XML sitemap is turned off by default (use HTML view on that item to enable it). The note calling the export has $HTMLDontExport shown as a key attribute as toggling the 'Export' box on HTML causes the view to re-preview the code which can be slow. This export alone generates a c.8 MB XML page, so don't turn it on unless you really want to see it at work!
- RSS & Atom feeds. These are basically two different flavours of the same form of syndication, and especially useful for those who use newsreaders. both feeds use an envelope/letter method of export. As the agents making the feeds look for changed items, these are deliberately placed at the end of the root so they process at the end of each agent update cycle (which proceeds in outline order across the file).
- CSS. The file uses a Code prototype for the note holding CSS code to avoid things like hash characters being misinterpreted as quicklist items. The is no specific benefit to maintaining the CSS this way. At the time it was just another test of what was possible. It also helps keep everything needed in one place. Indeed, except the images the whole site uses only data stored in the one TBX.
- Version and build-checker. This is rather more advanced a a feature built as an experiment for a small number of users who prefer using the TBX file over the HTML version. The notes output a small file which is updated every time a full HTML export is done. The notes use $AutoFetch, when the TBX is open, to see if a newer aTbRef output is available. The version checker is for new version releases (major or minor) and the update checker is for new complete TBX exports.
- The Zipper-images and Zipper notes are used to make up-to-date Zips of the images folder (as this is not part of the TBX) and a Zip of the TBX itself. Although Tinderbox runs all agents before starting a full export, there is no easy means to trigger a save, so if using this technique it is best to run a forced update ('Update now', via the File menu) and save manually (again via the File menu) before running a full HTML export.
- See more.