In my experience customizing and deploying CMSs for clients, 99% of folks want a WYSIWYG editor, for good or ill. Usually good.

• the way it uses “connectors” to allow for the integration of the WYSIWYG with in-site assets / resources and file uploads,
• that it generates clean HTML for the flexibility the WYSIWYG provides,
• and it’s good at not molesting any custom HTML you throw in.

So I’ve made a Radiant FCKEditor extension and put it on github.

See the readme for install instructions, requirements and other crap.

Features

• In-WYSIWYG file uploads and image placement,
• Spellchecking – provided aspell is installed,
• Radius-tag awareness – I did my best to tell FCKEditor to leave radius tags alone, even customizing the tags it should ignore at the PageType level,
• Works everywhere FCKEditor does,
• Implemented as a “filter”, allowing you to manage arbitrary numbers of page parts with it,
• You can dynamically add / remove it from page parts as you see fit.

The Future

• Create an admin tab to allow for editor toolbar customization,
• Integrate the link browser to allow for dirt-simple in-site linking,
• Offer optional integration with the page_attachments plugin for more logical file organization.

Get involved

Really! Drop me a line – dan @ endpoint dot com to discuss your ideas or make a fork, push your changes and send me a pull request. All reasonable offers accepted!

I have no idea if there’s a term to describe this kind of navigation, but I’ll use “flexmenu” as it’s what the excellent WebGUI CMS calls them, implemented via nested ul / li tags.

I like this method of site navigation as it gives a user the ability to see the entirety of the site along with the ability to zoom in / out easily and bounce between sub-sections.

As you drill down into the page hierarchy, the siblings of each page stay open. I’ll try to illustrate:

At the root, where “1” is the root.

1.1
1.2 <-- User clicks this
1.3
1.4

Next:

1.1
1.2
  1.2.1
  1.2.2
  1.2.3 <-- User clicks this
  1.2.4
  1.2.5
1.3
1.4

That opens up.

1.1
1.2
  1.2.1
  1.2.2
  1.2.3
    1.2.3.1 <-- leaf node
    1.2.3.2 <-- leaf node
    1.2.3.3 <-- leaf node
  1.2.4
  1.2.5
1.3
1.4

User clicks a completely separate part of the tree, and the 1.2 branch closes.

1.1
1.2
1.3 <-- User clicks here
  1.3.1
  1.3.2
  1.3.3
1.4

This is implemented via two snippets- a container and a recursive snippet for each node:

Container Snippet

 <r:if_parent>
 <div id="left-column-nav">
 <r:find url="/">
   <ul>
     <r:snippet name="menu-line" />
   </ul>
 </r:find>
 </div>
 </r:if_parent>

Recursive Snippet, named “menu-line”

 <r:children:each>
   <li<r:if_self> class="active"</r:if_self>><r:link />
       <r:if_ancestor_or_self>
         <r:if_children>
           <ul>
             <r:snippet name="menu-line" />
           </ul>
         </r:if_children>
       </r:if_ancestor_or_self>
   </li>  
 </r:children:each>

To use an example from a real site, when at the page ”/about/people/”, this navigation menu will yield HTML similar to:

<div id="left-column-nav">
  <ul>
    <li><a href="/about/">About</a>
      <ul>
        <li><a href="/about/goals/">Goals</a></li>  
        <li><a href="/about/history/">History</a></li>  
        <li><a href="/about/mission/">Mission</a></li>  
        <li class="active"><a href="/about/people/">People</a>
          <ul>
            <li><a href="/about/people/executive-committee-members/">Executive Committee Members</a></li>  
            <li><a href="/about/people/other-committees/">Other Committees</a></li>  
          </ul>
        </li>  
      </ul>
    </li>  
    <li><a href="/news/">News</a></li>  
    <li><a href="/programs/">Programs</a></li>  
    <li><a href="/publications/">Publications</a></li>  
    <li><a href="/resources/">Resources</a></li>  
    <li><a href="/morville-house/">Morville House</a></li>  
  </ul>
</div>

Nicely nested and easily styled via CSS.

Below is a simple script that saved me some time – for various reasons I had to replace horrid image buttons used on a web site with more compliant-looking image buttons. You could get buttons that look exactly like this via CSS, but in this case swapping out the images was the easiest fix.

In comes RMagick , the ruby interface to the venerable ImageMagick graphics library.

First you create the canvas, then you create the Magick::Draw object that you draw onto the canvas. On linux/unix machines you can directly display the image, too via canvas.display.

The script:

#!/usr/bin/env ruby
require 'RMagick'
[
    ['add to basket','buy.gif',100],
    ['change','change.gif',60],
    ['checkout','checkout.gif',75],
    ['continue','continue.gif',75],
    ['continue shopping','continue_shopping.gif',130],
    ['go','go.gif',30],
    ['next','next.gif',45],
    ['place order','place_order.gif',90],
    ['previous','previous.gif',70],
    ['product list','product_list.gif',90],
    ['update','recalculate.gif',60],
    ['submit','submit.gif',60],
    ['update','update.gif',60],
    ['please wait','wait.gif',90]
].each{|button|
    canvas=Magick::Image.new(button[2],25){
        self.background_color='#BED8F1'
    }
    d=Magick::Draw.new
    d.stroke('transparent')
    d.fill('black')
    d.font='/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/Verdana_Bold.ttf'
    d.pointsize=11
    d.font_weight=Magick::BoldWeight
    d.text(0,0,button[0])
    d.text_antialias(false)
    d.font_style=Magick::NormalStyle
    d.gravity=Magick::CenterGravity
    d.draw(canvas)
    canvas=canvas.raise(3,3)
    # canvas.display
    canvas.write(button[1])
}

The result:

Saved me some time, and I learned a bit out Rmagick in the process.

Get the script here

I can’t say a whole lot about this because it’s very early in the beta, but the dialogues at RedBlueUS.org are underway and going strong.

Here’s what I can say:

RedBlueUS.org matches up folks that are on opposite sides of the political spectrum, guiding them through a one-on-one dialogue with a number of “virtual facilitation” tools built-in. It’s designed to help people have productive dialogues with those they might not otherwise agree with, or talk to at all in a civil manner.

Kudos to my employer for letting me be the lead on such a cool project.

The nerdy stuff

• Built in Rails 1.1.6,
• Backed with a Postgres database,
• Hosted on a Centos linux box,
• Using mongrel and apache 2.2 in a proxied backend/frontend setup,

So far, an apache frontend and mongrel backend is an elegant and high performance Rails deployment option. I’m very happy with it.

Features

1. Moderator-posed “Opening questions”,
2. A more free-form back-and-forth where users get to ask questions and respond to each other,
3. Closing comments and a survey about the experience.

At various points, a user can use a dHTML (via prototype.js) “virtual facilitator” that helps them form productive, non-confrontational responses, sort of like having a mediator in the conversation with them.

User “temperatures” are taken at various points to see how satisfied and/or upset folks are with the dialogue process.

Users get email notifications about actions their partner has taken, to ensure folks keep the dialogue going. Users get to define how long a dialogue continues by mutually agreeing to end it.

There’s a wiki-like content management system that lets the client manage content without touching code.

The application is built to guide users through a facilitated one-on-one dialogue, with each action contingent on a number of other actions and criteria.

Thoughts

I really like rails.

Being able to create a set of inter-related objects (and then configuring Postgres to enforce those relationships) in a clean MVC framework made it very easy to create a pretty complicated application and still keep the complexity in check.

I really like this project.

As far as I’m aware, nothing like this is being done online anywhere – pulling users with disparate political views together into a structured but flexible dialogue process.

Having been a non-partisan political organizer with the PIRGS and then a free software-based web developer for the last 7 years or so, this pulls together a whole bunch of stuff I’m interested in one nice little bundle.

Virtually-facilitated online dialogue is a complicated beast – let’s hope we get some great feedback from the beta. Thanks, testers!

I’ve written a ROR helper (which ended up being relatively similar to this one) based on the “Easy HTML Whitelists” recipe in the Pragmatic Programmers Rails Recipes book.

The big problem with that recipe is that it allows any attributes on whitelisted tags. Not good. I could throw in nasty background images or cookie-stealing onclick/onmouseover events. XSS == teh badness.

Originally, I just stripped all the attributes, but in this post RoR Newbie asks “how can I allow SOME attributes?”

Thus was this helper born. It allows you to define “tag profiles” of allowed tags and attributes, and gives you the ability to allow different levels of sanitizing for different purposes/users. See the Rdoc for a fuller explanation.

Lemme know what you think. Dan at NOSPAMEendpoint dot com

HTMLFilterHelper

Rdoc:

http://www.kookdujour.com/doc/

The helper:

http://www.kookdujour.com/html_filter_helper.rb.txt

Try it out:

http://www.kookdujour.com/filter_test

I can’t stand positional parameters, and I don’t understand why we don’t use named parameters everywhere. For instance:

<%= link_to 'log out', 
    {:controller => '/user/tools', :action => 'logout'},
    {:post => true, :confirm => 'Are you sure you want to log out?'}
%>

Just seems silly to me. You pass in the link text as the first parameter, the URL parameters as a subsequent hash and then the “HTML options” as a hash following that one. Confusing the issue more, you can leave out the {} when you’re only passing in one hash of options.

The problem I have with this is I have to expend the mental energy to remember what order I need to pass things in, and it’s just easier to remember concise, descriptive names.

Example:

<%= link_to :link_text => 'log out', 
    :url_options => {:controller => '/user/tools', :action => 'logout'},
    :html => {:post => true, :confirm => 'Are you sure you want to log out?'}
%>

It’s slightly more typing, but at the advantage of creating self-documenting methods that are just easier to work with.

So – work has pushed me to using Rails. We’ve been wanting to do Rails work for a while, and I helped land a project that is a good fit: it’s big enough and should fit into an MVC paradigm nicely – plus it doesn’t need e-commerce or complicated shipping logic like many other End Point projects seem to.

I was initially hesitant to learn a new framework. . . I don’t know if this was intentional or not, but it was put out to me thusly – “if you don’t do this project in rails, we’ll get someone else to, even if it means hiring an outside consultant.” The surest way to get me to do something is to tell me I can’t. :)

I’m relatively new to rails, but not new to web development generally.

• Mason
• CGI::Application
• Interchange
• WebGUI

And others I have a more-than-passing knowledge of:

• Zope
• Catalyst
• Various PHP apps – phpBB, Moodle, etc.

I was also a longtime MySQL fanatic until I came to End Point and discovered that a database can be more than a glorified storage engine: It can also save you oodles of development time and protect your data. All hail Postgres!

Here’s where I plan to keep track of my Rails process and what quirky things I discover along the way.

¹ Where “web development framework” has a VERY loose definition.