Rassmalog is a static blog engine based on RSS 2.0, YAML, and Textile. It features an extensible blog formatting mechanism, easy configuration, and automatic tagging, archiving, syntax coloring, and table of contents.
This release adds the ability to use ERB directives in the text of blog entries, adds translations for various languages, refines the automatic table of contents, and improves the obfuscation of email addresses.
Notice
If your blog entries contain the text "<%" (which marks the beginning of an ERB directive), then you must escape those markers by adding an extra percentage sign (%), like this: "<%%". Otherwise, you will get errors from ERB when you generate your blog.
Details
* Added translation files for various languages. These translations were made using online services such as Babel Fish and Systran.
* Wrote better instructions for enabling translation files.
* Removed numbering of links in table of contents.
* Made the number of each heading into a link back to the table of contents. This is very useful for text-mode browsers.
* The entire URL for sending email comments is now obfuscated.
* Added Rassmalog version number to generated output.
* The text fields of blog entries are now treated as ERB templates (see config/entry.erb for details).
* Moved some logic from ERB templates into Rassmalog’s core.
Since nobody had yet obtained the 3.0.1 release, I secretly took the opportunity to roll in a few additional fixes and enhancements. In this manner, 3.0.1 silently mutated into 3.1.0 as follows. :-)
Version 3.1.0
This release fixes the ability to use ERB directives in the text of blog entries, makes ERB directives behave like those of PHP, makes auto-generated HTML anchors more human readable, and corrects the German translation file.
Acknowledgments
Thanks to Josef ‘Jupp’ Schugt for correcting the German translation file.
Details
* Fixed RSS feed generation so that entry body is evaluated as an ERB template.
* Incorporated my PHP-like ERB hack to prevent <% ... %> ERB directives from injecting extraneous newlines into the generated output.
* Auto-generated HTML anchors (for the table of contents) now make use of the text of the heading they refer to. This makes them more human readable than, say, “anchor153”.
> Since nobody had yet obtained the 3.0.1 release, I secretly took > the opportunity to roll in a few additional fixes and enhancements. > In this manner, 3.0.1 silently mutated into 3.1.0 as follows. :-)
> Version 3.1.0
> This release fixes the ability to use ERB directives in > the text of blog entries, makes ERB directives behave like > those of PHP, makes auto-generated HTML anchors more human > readable, and corrects the German translation file.
> Acknowledgments
> Thanks to Josef 'Jupp' Schugt for correcting the German > translation file.
> Details
> * Fixed RSS feed generation so that entry body is > evaluated as an ERB template.
> * Incorporated my PHP-like ERB hack to prevent <% ... %> > ERB directives from injecting extraneous newlines into > the generated output.
> * Auto-generated HTML anchors (for the table of > contents) now make use of the text of the heading they > refer to. This makes them more human readable than, > say, "anchor153".
> oh i like offline generated pages. seems nice. regarding the > search problem: consider integrating a javascript based solution.
I do not know about you but when *I* browse the Web I either use a browser that has no Javascript capability at all or with Javascript deactivated unless I explicitly switch it on. It is annoying enough that Web dysdesigners are so sure that using a flash-enabled webbrowser means that Javascript is activated that they not even inform the user that a Javascript script is used to detect if one has a flash-enabled browser.
That the created pages are usable with any browser was an important reason for my choice to use rassmalog. I do not oppose to include a Javascript engine but the integration than should be done in a clever way. My suggestion is as follows:
1. Keep the current search 2. Add a search using javascript 3. Make use of <noscript> in this manner: a) If Javascript is enabled display "Search (Javascript enhanced)" b) If Javascript is disabled display "Search (no Javascript, deprecate)" 4. Add a small paragraph about why to enable Javascript to the latter search. 5. On the same page add a piece of Javascript that replaces the page by the Javascript version of the search.
A site using Javascript is good if and only if the necessities still work with disabled Javascript. Bells, whistles and eyecandy can rely on Javascript.
> * Robert Wagner, 09.03.2007 20:47: >> oh i like offline generated pages. seems nice. regarding the >> search problem: consider integrating a javascript based solution.
> I do not know about you but when *I* browse the Web I either use a > browser that has no Javascript capability at all or with Javascript > deactivated unless I explicitly switch it on. It is annoying enough > that Web dysdesigners are so sure that using a flash-enabled > webbrowser means that Javascript is activated that they not even > inform the user that a Javascript script is used to detect if one has > a flash-enabled browser.
> That the created pages are usable with any browser was an important > reason for my choice to use rassmalog. I do not oppose to include a > Javascript engine but the integration than should be done in a clever > way. My suggestion is as follows:
> 1. Keep the current search > 2. Add a search using javascript > 3. Make use of <noscript> in this manner: > a) If Javascript is enabled display > "Search (Javascript enhanced)" > b) If Javascript is disabled display > "Search (no Javascript, deprecate)" > 4. Add a small paragraph about why to enable Javascript to the latter > search. > 5. On the same page add a piece of Javascript that replaces the page > by the Javascript version of the search.
> A site using Javascript is good if and only if the necessities still > work with disabled Javascript. Bells, whistles and eyecandy can rely > on Javascript.
> * Robert Wagner, 09.03.2007 20:47: > > oh i like offline generated pages. seems nice. regarding the > > search problem: consider integrating a javascript based solution.
> I do not know about you but when *I* browse the Web I either use a > browser that has no Javascript capability at all or with Javascript > deactivated unless I explicitly switch it on.
so, you're no fun :)
> It is annoying enough > that Web dysdesigners are so sure that using a flash-enabled > webbrowser means that Javascript is activated that they not even > inform the user that a Javascript script is used to detect if one has > a flash-enabled browser.
> That the created pages are usable with any browser was an important > reason for my choice to use rassmalog. I do not oppose to include a > Javascript engine but the integration than should be done in a clever > way. My suggestion is as follows:
> 1. Keep the current search
but tell people about <strg><f> and it's actually a search
> 2. Add a search using javascript > 3. Make use of <noscript> in this manner: > a) If Javascript is enabled display > "Search (Javascript enhanced)" > b) If Javascript is disabled display > "Search (no Javascript, deprecate)" > 4. Add a small paragraph about why to enable Javascript to the latter > search. > 5. On the same page add a piece of Javascript that replaces the page > by the Javascript version of the search.
> A site using Javascript is good if and only if the necessities still > work with disabled Javascript. Bells, whistles and eyecandy can rely > on Javascript.
Josef 'Jupp' Schugt wrote: > * Robert Wagner, 09.03.2007 20:47: >> oh i like offline generated pages. seems nice. regarding the >> search problem: consider integrating a javascript based solution.
> the integration than should be done in a clever > way. My suggestion is as follows:
> 1. Keep the current search > 2. Add a search using javascript > 3. Make use of <noscript> in this manner: > a) If Javascript is enabled display > "Search (Javascript enhanced)" > b) If Javascript is disabled display > "Search (no Javascript, deprecate)" > 4. Add a small paragraph about why to enable Javascript to the latter > search. > 5. On the same page add a piece of Javascript that replaces the page > by the Javascript version of the search.
I like this idea and will try to implement something along these lines. I will also remind (although it may be considered offensive to be reminded of such basic operations -- like someone telling you how shoelaces are tied) the reader gently about using their browser's search mechanism, be it <control><f> or <forward-slash>. I will also state clearly that the "search" page is really just an exhaustive listing of the content of all entries available on the blog.
Thank you all for your suggestions.
P.S. It may be a few weeks before I get around to implementing these things (final exams are approaching), so feel free to submit a patch if you're able. :-)
Suraj Kurapati wrote: > Josef 'Jupp' Schugt wrote: >> * Robert Wagner, 09.03.2007 20:47: >>> regarding the >>> search problem: consider integrating a javascript based solution.
>> the integration than should be done in a clever >> way. My suggestion is as follows:
>> 1. Keep the current search >> 2. Add a search using javascript >> 3. Make use of <noscript> in this manner: >> a) If Javascript is enabled display >> "Search (Javascript enhanced)" >> b) If Javascript is disabled display >> "Search (no Javascript, deprecate)" >> 4. Add a small paragraph about why to enable Javascript to the latter >> search. >> 5. On the same page add a piece of Javascript that replaces the page >> by the Javascript version of the search.
I evaulated Tipue and several other JavaScript search engines, and Tipue seems to be the best choice because it does not require prior preprocessing (indexing) of the data to be searched.
However, when I integrated Tipue, it did not seem to offer a huge advantage over the browser's internal search mechanism. For instance, it doesn't implement any query relaxation -- I'm thinking of edit-distance and Soundex algorithms -- so it's hard to find something unless you know exactly how it is spelled beforehand.
With the browser's search mechanism, you get to see a much larger context of a match whilst searching. In contrast, search engines strip away much of the context, which is useful in situations like this -- where you're manually scanning for something that resembles what you're actually looking for.
> I will also remind (although it may be considered offensive to be > reminded of such basic operations -- like someone telling you how > shoelaces are tied) the reader gently about using their browser's search > mechanism, be it <control><f> or <forward-slash>.
I decided to omit such a reminder, simply because it might seem offensive.
> I will also state > clearly that the "search" page is really just an exhaustive listing of > the content of all entries available on the blog.
I have done this with great reluctance, because it caused the addition of yet another template file (config/index.erb), in the new 3.2.0 release.