News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

The flint site is produced in flint which gives an idea of what it can do. I'd characterise it as being on most use to those who can't/won't write HTML or those who can but don't really understand Tinderbox export & includes. Flint uses the Tinderbox wizard system to help the user create a customised TBX which then exports a website for them (as per the f;lint demo site).

Apart from some small errors in RSS/Atom templates (reported separately to Eastgate via email) there are no problems.

As I have a Flint licence, I've reviewed the code of the wizard's original TBX and I've sent an updated version to Eastgate today (fixing the Atom/RSS and updating legacy action/export code); my changes would require users to have v5.7.0+. Contact Eastgate directly re any update issues.

Thanks for the explanation. Flint sound interesting, but it seems like it is not very maintained which might be because a lack of users? Maybe starting with one of the examples on the Tinderbox Exchange would be equally helpful to me as I will probably want to modify stuff.

If I may, I think you're taking a slightly glass-half empty approach . Lest my earlier comments be misinterpreted, the breakages to which I referred were 2 [sic] template names cited in incorrect case (likely an accident during moving the export templates within the TBX as was done for Flint v2.0. The effect of this? RSS or Atom feeds may not export their per-item data correctly. Meanwhile, the code I described as deprecated all still functions correctly. For nearly all Flint users, it is actually a tool you will use only once or twice. Why? As already explained, it is a wizard. You run the wizard which uses the data you supply to pre-configure a TBX with that data plus some things like an export template into which a local copy of your website/blog/feeds goes on HTML Export. Once you start customising the wizard-created TBX, you won't want to over-write it by running the wizard or you'll obviously loose your changes. However, you might use the wizard again to start a new site.

My rationale for updating old action/export code is simply so as to get new users - who might use existing code for guidance - starting on the right foot. If you read the TB Release Notes (Help menu) you'll see action/export code is under constant incremental change, so it's a judgement call as to when code is not current enough. Still, the fact there's older styled TB code doesn't mean the code doesn't function as intended.

Mark B started his blog before Flint was written thus, for reasons given above about how Flint's used, it's not likely he used Flint to make his current site.

Even if you don't use Flint to make your own content directly, unpicking the TBX it creates for you is a really useful demo/learning aid on how to go about includes. In the later context, as a learning tool you can always get it today and if there's an update you'll be able to use that too. If unsure drop an email to support re the status of updates.

I don't always use Flint myself, because I'm pretty good at this point with HTML Export And we've talked less, lately, about Tinderbox and HTML because that tends to annoy people who need Tinderbox for other things.

Recent changes in HTML export have made life MUCH simpler, so there's less to learn and fewer idiosyncrasies to master. And I thin Flint remains a good way to get started. I'd certainly hate to blog without Tinderbox.

Thanks to you both for your replies! I do understand now that Flint creates a custom TBX and the HTLit site is a great example.

I do have one question though, how is image support provided with Flint since images cannot be included in notes at the moment? Is it similar to the aTbRef where one would put the images in a separate folder and reference them that way?

I've always preferred to keep web images in separate folders -- my blog uses /elements for inline images and /covers for book covers -- and then use a macro to embed the image appropriately.

^do(image, Sullivan.jpg, 450, 200, "caption....")

The numbers are width and height of the image.

This does a bunch of nice things. It keeps the images out of the Tinderbox file, so the Tinderbox file is smaller. It lets me manage the image type and quality easily. And the macro isolates changes to image markup; if I decide I want to apply a class or a border to all image in my weblog, I can do it in the macro and avoid changing lots of entries individually.

In aTbRef, a root level /images/ folder holds all images. Although I now use a simpler method (get the aTref TBX to see how) I also wrote this pretty comprehensive macro to do the same as the example above. Macro name: ImgTagMacro code: <img src="$1"^if($2)^ width="$2"^endif^^if($3)^ height="$3"^endif^ alt="$4" title="$4"^if($5)^ id="$5"^endif^^if($6)^ class="$6"^endif^/>

$1: image name (or it could be a full or relative path)$2: image width in pixels$3: image height in pixels$4: title & alt text$5: tag HTML ID value$6: tag HTML class value