Archive | September, 2006

Editing old pages in reSt

One problem with changing from HTML (or a content editor) to reStructured Text in Plone is that the text editor doesnt convert your old HTML docs to reStructured Text.

However, my experience so far is that if you copy the text of the page (not the code), click on the edit tab, delete the HTML code and paste the content of the page back in, it does a pretty good job of keeping the layout of the page. Paragraphs, bullet points and numbered lists are largely mantained. Of course, links images and preformatted text all have to be put back, but what can you do…

Comments { 0 }

Creating proper internal links

Images

Images are the same: .. image:: /images/vasudevaserver.gif

This is bad: /images/vasudevaserver.gif/

The bottom line is: Never add a trailing slash!

Also, please make sure images always have the type of file at the end (.jpg or .gif)

vasudevaserver
Comments { 0 }

Please read: “WYSIWYG Considered Harmful”

A really good article: http://kopsis.blogspot.com/2004/09/wysiwyg-considered-harmful.html

Comments { 0 }

A reStructuredText Primer

This is an on-going post. Please forgive the "work-in-progress" feel.

The text below contains links that look like "(quickref)". These
are relative links that point to the Quick reStructuredText user
reference. If these links don’t work, please refer to the master
quick reference
document.

Structure

From the outset, let me say that "Structured Text" is probably a bit
of a misnomer. It’s more like "Relaxed Text" that uses certain
consistent patterns. These patterns are interpreted by a HTML
converter to produce "Very Structured Text" that can be used by a web
browser.

The most basic pattern recognised is a paragraph (quickref).
That’s a chunk of text that is separated by blank lines (one is
enough). Paragraphs must have the same indentation — that is, line
up at their left edge. Paragraphs that start indented will result in
indented quote paragraphs. For example:

This is a paragraph.  It's quite
short.

   This paragraph will result in an indented block of
   text, typically used for quoting other text.

This is another one.

Results in:

This is a paragraph. It’s quite
short.

This paragraph will result in an indented block of
text, typically used for quoting other text.

This is another one.

Text styles

(quickref)

Inside paragraphs and other bodies of text, you may additionally mark
text for italics with "*italics*" or bold with
"**bold**".

If you want something to appear as a fixed-space literal, use
"``double back-quotes``". Note that no further fiddling is done
inside the double back-quotes — so asterisks "*" etc. are left
alone.

If you find that you want to use one of the "special" characters in
text, it will generally be OK — reStructuredText is pretty smart.
For example, this * asterisk is handled just fine. If you actually
want text *surrounded by asterisks* to not be italicised, then
you need to indicate that the asterisk is not special. You do this by
placing a backslash just before it, like so "\*" (quickref), or
by enclosing it in double back-quotes (inline literals), like this:

``\*``

Lists

Lists of items come in three main flavours: enumerated,
bulleted and definitions. In all list cases, you may have as
many paragraphs, sublists, etc. as you want, as long as the left-hand
side of the paragraph or whatever aligns with the first line of text
in the list item.

Lists must always start a new paragraph — that is, they must appear
after a blank line.

bulleted lists (quickref)

Just like enumerated lists, start the line off with a bullet point
character – either "-", "+" or "*":

* a bullet point using "*"

  - a sub-list using "-"

    + yet another sub-list

  - another item

Results in:

  • a bullet point using "*"
    • a sub-list using "-"
      • yet another sub-list
    • another item
definition lists (quickref)

Unlike the other two, the definition lists consist of a term, and
the definition of that term. The format of a definition list is:

what
  Definition lists associate a term with a definition.

*how*
  The term is a one-line phrase, and the definition is one or more
  paragraphs or body elements, indented relative to the term.
  Blank lines are not allowed between term and definition.

Results in:

what
Definition lists associate a term with a definition.
how
The term is a one-line phrase, and the definition is one or more
paragraphs or body elements, indented relative to the term.
Blank lines are not allowed between term and definition.

Preformatting (code samples)

(quickref)

To just include a chunk of preformatted, never-to-be-fiddled-with
text, finish the prior paragraph with "::". The preformatted
block is finished when the text falls back to the same indentation
level as a paragraph prior to the preformatted block. For example:

An example::

    Whitespace, newlines, blank lines, and all kinds of markup
      (like *this* or \this) is preserved by literal blocks.
  Lookie here, I've dropped an indentation level
  (but not far enough)

no more example

Results in:

An example:

  Whitespace, newlines, blank lines, and all kinds of markup
    (like *this* or \this) is preserved by literal blocks.
Lookie here, I've dropped an indentation level
(but not far enough)

no more example

Note that if a paragraph consists only of "::", then it’s removed
from the output:

::

    This is preformatted text, and the
    last "::" paragraph is removed

Results in:

This is preformatted text, and the
last "::" paragraph is removed

Sections

(quickref)

To break longer text up into sections, you use section headers.
These are a single line of text (one or more words) with adornment: an
underline alone, or an underline and an overline together, in dashes
"-----", equals "======", tildes "~~~~~~" or any of the
non-alphanumeric characters = - ` : ' " ~ ^ _ * + # < > that you
feel comfortable with. An underline-only adornment is distinct from
an overline-and-underline adornment using the same character. The
underline/overline must be at least as long as the title text. Be
consistent, since all sections marked with the same adornment style
are deemed to be at the same level:

Chapter 1 Title
===============

Section 1.1 Title
-----------------

Subsection 1.1.1 Title
~~~~~~~~~~~~~~~~~~~~~~

Section 1.2 Title
-----------------

Chapter 2 Title
===============

This results in the following structure, illustrated by simplified
pseudo-XML:

<section>
    <title>
        Chapter 1 Title
    <section>
        <title>
            Section 1.1 Title
        <section>
            <title>
                Subsection 1.1.1 Title
    <section>
        <title>
            Section 1.2 Title
<section>
    <title>
        Chapter 2 Title

(Pseudo-XML uses indentation for nesting and has no end-tags. It’s
not possible to show actual processed output, as in the other
examples, because sections cannot exist inside block quotes. For a
concrete example, compare the section structure of this document’s
source text and processed output.)

Note that section headers are available as link targets, just using
their name. To link to the Lists heading, I write "Lists_". If
the heading has a space in it like text styles, we need to quote
the heading "`text styles`_".

Document Title / Subtitle

The title of the whole document is distinct from section titles and
may be formatted somewhat differently (e.g. the HTML writer by default
shows it as a centered heading).

To indicate the document title in reStructuredText, use a unique adornment
style at the beginning of the document. To indicate the document subtitle,
use another unique adornment style immediately after the document title. For
example:

================
 Document Title
================
----------
 Subtitle
----------

Section Title
=============

...

Note that "Document Title" and "Section Title" above both use equals
signs, but are distict and unrelated styles. The text of
overline-and-underlined titles (but not underlined-only) may be inset
for aesthetics.

Images

(quickref)

To include an image in your document, you use the the image directive.
For example:

.. image:: /images/vasudevaserver.gif

results in:

/images/vasudevaserver.gif

The images/biohazard.png part indicates the filename of the image
you wish to appear in the document. There’s no restriction placed on
the image (format, size etc). If the image is to appear in HTML and
you wish to supply additional information, you may:

.. image:: /images/vasudevaserver.gif
   :height: 100
   :width: 200
   :scale: 50
   :alt: alternate text

See the full image directive documentation for more info.

What Next?

This primer introduces the most common features of reStructuredText,
but there are a lot more to explore. The Quick reStructuredText
user reference is a good place to go next. For complete details, the
reStructuredText Markup Specification is the place to go [1].

Users who have questions or need assistance with Docutils or
reStructuredText should post a message to the Docutils-Users
mailing list
. The Docutils project web site has more
information.

[1] If that relative link doesn’t work, try the master document:
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html.
Comments { 0 }

reStructeredText (ReST) default type on Vasudevaservice.com

reStructeredText (ReST) is now the default content format for all the standard ATCT objects (Pages, News, Events) and EasyBlog, for all sites on this server.

For now, if you still have Kupu as your editor then the default will be overriden by Kupu to html.

Be aware though, that since we are going to use Vasudevaservice.com as testbed for reStructuredText, Kupu has been uninstalled there.

Comments { 0 }

Two directives: sidebar and figure

ReStructuredtext has a "sidebar" directive. See a good example of a sidebar here: http://en.wikipedia.org/wiki/Gorbachev

Sidebars are like miniature, parallel documents that occur inside other documents, providing related or reference material. A sidebar is typically offset by a border and "floats" to the side of the page; the document’s main text may flow around it. Sidebars can also be likened to super-footnotes; their content is outside of the flow of the document’s main text.

Sidebars may occur anywhere a section or transition may occur. Body elements (including sidebars) may not contain nested sidebars.

If you would have the following css inside your Plone skin:

.sidebar
{
color: red;
font-weight: bold;
float: right;
width: 10em;
}

The following code:

.. sidebar:: Sidebar Title
   :subtitle: Optional Sidebar Subtitle

   Subsequent indented lines comprise
   the body of the sidebar, and are
   interpreted as body elements...

   .. image::  /images/vasudevaserver.gif

Would be rendered as a sidebar of text floating on the right.

Now, for what concerns images, reStructuredText has a wonderful directive, "figure", which also support a "class" attribute.

Let’s assume we also have this css:

.float-right
{
float: right;
border-style: dashed;
border-width: 1px;
border-color: red;
}

The following reStructuredText:

.. figure:: /images/vasudevaserver.gif
   :alt: logo
   :figwidth: image
   :figclass: float-right
   :align: right

    This is the caption.

Would produce the following:

logo

This is the caption.

That is for today! We saw how easy it is to employ the two powerful directives "sidebar" and "figure".

See you next time!

Comments { 0 }

change color tabs vscore

vsCore which is used on Vasudevaserver has a few new features. Firstly colors of tabs can be changed through ZMI.

when caching has expired the tabs will change at top.

  • subskin feature – Very useful, when you want to have many plone instances and still keep the same main_template

These features are not included in the current vsCore tarball; a new tarball will be uploaded shortly…..

Comments { 0 }

Evaluating Plone form mailer

With Plone Form mailer, you can design email forms through the web. We at Vasudeva Server have had occasion to use them a lot.

Their best point is the ease with which you can actually get a form drummed up and ready on your site. The ‘edit’ tab lets you enter text before and after the form, configure who to send it to, sort out what the email is going to look like, and design a ‘thank-you’ page. The ‘modify form(zmi)’ tab lets you work on the form itself.

The edit tab

The fields to enter in the ‘edit’ tab are pretty intuitive (and have
been made more so in recent versions). There are a couple of times
where you have to enter a TALES expression, like the mail recipient or
the email address of recipient. For example, if your name is Mr Happy
and your email address is happy@happy.com then enter string:Mr Happy and string:happy@happy.com in the relevant fields. One nice feature is they warn you what bits not to touch if you haven’t a clue what youre doing!

The ‘modify form’ tab
By default, the form has a field for name, email and message. One
recent improvement to Plone Form mailer is that the whole form doesnt
fall apart if for some reason you delete the email field. Clicking on
the tab takes you to a ZMI interface where you can see a menu
containing each of the fields. You can add more fields by clicking on
the top right, including checkboxes, radiofields, you name it.

Issues
Sometimes we have had problems implementing PloneFormMailer using
scripts other than Roman (eg Cyrillic). Sometimes the checkboxes dont
work and the characters are not correctly interpreted in the email.

One issue is that form mailers invariably always present problems when migrating Plone, and usually have to be deleted and recreated again. However PloneFormMailer is quite young and we would expect this to be sorted out in the future.

You can read more about Plone Form Mailer on their section  of  the Plone site

Comments { 0 }