mysql icontypo iconapache iconlighttpd icon

Birth of a Typo Blog

Posted in , , , Wed, 21 Jun 2006 22:04:00 GMT

I'm giving Typo a shot after hearing some good things about it and having performance problems at a hosted blog service. It's been pretty good so far. Let's see how it runs in action.

I'm currently using the Lucid theme. So far I've played with Azure (the default), Lucid and Phokus. The default font size seems smaller than normal on other sites. Let me know if it's too small or there are other issues.

Up until now, my wiki has been the only app at this domain. I'm leaning towards putting commentary, questions, short summaries and the like in the blog while the wiki would still contain reference type information. To that end, I put up some detailed Typo install instructions covering MySQL, Apache, lighttpd and FastCGI on the wiki. Right now it just covers installation as I'm just getting into customizing the template. Let me know what you think. of a Typo Blog digg:Birth of a Typo Blog reddit:Birth of a Typo Blog spurl:Birth of a Typo Blog wists:Birth of a Typo Blog simpy:Birth of a Typo Blog newsvine:Birth of a Typo Blog blinklist:Birth of a Typo Blog furl:Birth of a Typo Blog fark:Birth of a Typo Blog blogmarks:Birth of a Typo Blog Y!:Birth of a Typo Blog smarking:Birth of a Typo Blog magnolia:Birth of a Typo Blog segnalo:Birth of a Typo Blog

no comments

dojo icon

Dojo - Setting the ComboBox Default Value

Posted in , , Wed, 14 Jun 2006 08:39:00 GMT

Dojo Toolkit's ComboBox doesn't take a default value but one can be written in using JavaScript. The default value in the ComboBox dojoType is lost during onLoad when the dojoType widget is rendered. To get around this we can use JavaScript to fill in the value during dojo.addOnLoad. Here's the relevant JavaScript:

function init() {
  var mycombobox = dojo.widget.byId('mycombobox');
  mycombobox.textInputNode.value = 'Seattle';

// method 1
dojo.addOnLoad( init );

// method 2
dojo.addOnLoad( function() {
} )
// won't work b/c you want to send an object
// not call a function
dojo.addOnLoad( init() );


<input dojoType="ComboBox"
  value="this should never be seen - it is replaced!"
  dataUrl="comboBoxData.js" style="width: 300px;" name=""

A more detailed example of this technique is available on the wiki at Dojo Toolkit: Setting the Combobox Default Value. - Setting the ComboBox Default Value digg:Dojo - Setting the ComboBox Default Value reddit:Dojo - Setting the ComboBox Default Value spurl:Dojo - Setting the ComboBox Default Value wists:Dojo - Setting the ComboBox Default Value simpy:Dojo - Setting the ComboBox Default Value newsvine:Dojo - Setting the ComboBox Default Value blinklist:Dojo - Setting the ComboBox Default Value furl:Dojo - Setting the ComboBox Default Value fark:Dojo - Setting the ComboBox Default Value blogmarks:Dojo - Setting the ComboBox Default Value Y!:Dojo - Setting the ComboBox Default Value smarking:Dojo - Setting the ComboBox Default Value magnolia:Dojo - Setting the ComboBox Default Value segnalo:Dojo - Setting the ComboBox Default Value


Localization - Language Fallback?

Posted in Wed, 14 Jun 2006 07:05:00 GMT

Playing around with browser locale settings and the resulting HTTP_ACCEPT_LANGUAGE values, I've started to realize that websites often don't fallback to the language if you are using a two part locale they don't support but they do support the language only. Let's say a browser has the following preferences set up:

1. en-us
2. de

A website that only has en and de will typically fail on en-us and then return German. My intuition tells me the server would be more user friendly if it parsed en-us to try the language portion, en, before moving on to the next locale but there would be situations where the user won't get exactly what s/he wants? What do you think? Should servers fallback from two part locales to a one part language or should it be up to the user to manage it correctly in their browser? - Language Fallback? digg:Localization - Language Fallback? reddit:Localization - Language Fallback? spurl:Localization - Language Fallback? wists:Localization - Language Fallback? simpy:Localization - Language Fallback? newsvine:Localization - Language Fallback? blinklist:Localization - Language Fallback? furl:Localization - Language Fallback? fark:Localization - Language Fallback? blogmarks:Localization - Language Fallback? Y!:Localization - Language Fallback? smarking:Localization - Language Fallback? magnolia:Localization - Language Fallback? segnalo:Localization - Language Fallback?

no comments

YouTube - Financially Viable?

Posted in , Wed, 14 Jun 2006 06:32:00 GMT

YouTube may be the most popular video sharing website but according to a recent article on The Register they've burned through nearly $11.5 million in venture funding without any revenue channels. I've often wondered about this. What is YouTube's business model? It looks suspiciously like chasing eyeballs at the moment but I'm hoping one will emerge soon.

The article's main issue, that people give YouTube a "worldwide, non-exclusive, royalty-free, sublicenseable and transferable" license to use their work is also of interest. I wonder when we'll see them start to use those rights and in what ways. Will there be a backlash? For now it seems people either don't know about it or are trusting YouTube to do no evil. - Financially Viable? digg:YouTube - Financially Viable? reddit:YouTube - Financially Viable? spurl:YouTube - Financially Viable? wists:YouTube - Financially Viable? simpy:YouTube - Financially Viable? newsvine:YouTube - Financially Viable? blinklist:YouTube - Financially Viable? furl:YouTube - Financially Viable? fark:YouTube - Financially Viable? blogmarks:YouTube - Financially Viable? Y!:YouTube - Financially Viable? smarking:YouTube - Financially Viable? magnolia:YouTube - Financially Viable? segnalo:YouTube - Financially Viable?

no comments

catalyst iconperl icon

Localization / Internationalization with Catalyst

Posted in , , Wed, 14 Jun 2006 06:06:00 GMT

I played with Catalyst::Plugin::I18N today to test returning text according to the user's language. This is called internationalization (I18N) or localization (L10N). I prefer the term localization when customizing output for users for this (and internationalization for storing multi-lingual data in the backend) but the definition is subject to debate and both are used. It seems there are two stages to L10N: locale detection and the localization.

C::P::I18N can do dection based on an explicit setting:

$c->languages( ['de'] );

or automatic browser detection based on the browser's HTTP_ACCEPT_LANGUAGE. C::P::I18N does the localization portion using string substitution. To set this up put your string definitions in the your mo/po or Maketext classes and then localize in the View, for example using TT:

[% c.loc('Hello World') %]

Also make sure to set the Vary header to assist with caching:

# Covers one or more Vary headers
    Vary => 'Accept-Language'

# If you only have one Vary header
$c->res->header( Vary => 'Accept-Language' );

The Vary header should theoretically handle proxy caching though these servers are typically out of your control and cannot be guaranteed to recognize and process the header.

The other popular detection option seems to be to put the locale in the URI, either in the domain name (e.g. or in the path / query string, as opposed to reading a HTTP request parameter.

Cal Henderson's Building Scalable Websites O'Reilly book talks about Localization and mentions three methods:

  1. string substitution
  2. multiple template sets
  3. multiple frontends

Cal mentions all three methods are hard and doesn't give an outright recommendation. He does, however, lists problems with string substitution and multple template sets but not multiple frontends so perhaps he's implicitly recommending the latter. He doesn't talk about detection methods. At first I was very excited to get Cal's book because I thought he would make outright recommendations. I'm starting to realize it's more of a primer and you have to tease out the best option.

Do you L10N or I18N? If so, how do you do it? / Internationalization with Catalyst digg:Localization / Internationalization with Catalyst reddit:Localization / Internationalization with Catalyst spurl:Localization / Internationalization with Catalyst wists:Localization / Internationalization with Catalyst simpy:Localization / Internationalization with Catalyst newsvine:Localization / Internationalization with Catalyst blinklist:Localization / Internationalization with Catalyst furl:Localization / Internationalization with Catalyst fark:Localization / Internationalization with Catalyst blogmarks:Localization / Internationalization with Catalyst Y!:Localization / Internationalization with Catalyst smarking:Localization / Internationalization with Catalyst magnolia:Localization / Internationalization with Catalyst segnalo:Localization / Internationalization with Catalyst


python iconplanet icon

Python - First Impressions from Hacking PlanetPlanet

Posted in , , Wed, 14 Jun 2006 02:52:00 GMT

Over the weekend I got to use Python for the first time to add channel categories to Planet which can be seen in action at Planet MVC. My first impressions of Python is that the resulting code looks very clean. The syntax was also easy to pick up primarily due to the excellent docs site and because it reminded me of JavaScript.

The first problem I ran into was using the regex object's re.match which definately does not follow the Python philosophy of "There should be one -- and preferably only one -- obvious way to do it" because there's more than one way and re.match is not obvious because it works different than other languages. Python's re.match automatically starts from the begining of the string unlike regex engines for other languages (grep|sed|awk|perl|ruby). This results in the following behavior:

# matches - pattern is at start of string
m = re.match('b', 'bc')

# does not match - pattern is not at start of string
m = re.match('b', 'abc')

# matches - add the .* to match any leading characters
# but .* isn't needed after '.*b' to match 'c'
m = re.match('.*b', 'abc')

# matches - second .* matches 'c' but isn't needed
m = re.match('.*b.*', 'abc')

I was sticking to re.match because I needed the MatchObject to capture groups but it didn't DWIW. After posting to a forum, I learned that I should use instead which will match anywhere in the string. also returns a MatchObject but I didn't expect this at first because search != match. I get the impression re.match and MatchObject were created first and was added later. Perhaps the MatchObject should be called something generic, like ResultObject, in the docs. I'm sort of curious but when is re.match desired over It seems like re.match is useful only in a limited number of situations and then it's always easy to implement it with

The open issue for me is Python's dependency on indenting. Lately I've been using tabs exclusively for indentation because I like to see the tickmarks may editors show for tabs. This lets me quickly know what level I'm at. This python-list thread was titled Tab Wars and argued in favor of spaces over tabs. Planet is indented with spaces and that's what I used for my hacking. Given my preference for tabs, the more time I spend with Python the more likely I'll switch to tabs. Do I need to convert the entire script to tabs or can I mix tabs with spaces? What do people with a preference for tabs do with Python code that uses spaces?

I've been thinking about releasing my enhanced version of PlanetPlanet which allows one planet site to run multiple planets but now I'm thinking I want to do more enhancements to make it even more user friendly. Let me know how Planet MVC is working for you or if I can add any additional blogs. I've already found it pretty useful to find out about things I otherwise wouldn't have.

Here are some notes on getting Planet running. - First Impressions from Hacking PlanetPlanet digg:Python - First Impressions from Hacking PlanetPlanet reddit:Python - First Impressions from Hacking PlanetPlanet spurl:Python - First Impressions from Hacking PlanetPlanet wists:Python - First Impressions from Hacking PlanetPlanet simpy:Python - First Impressions from Hacking PlanetPlanet newsvine:Python - First Impressions from Hacking PlanetPlanet blinklist:Python - First Impressions from Hacking PlanetPlanet furl:Python - First Impressions from Hacking PlanetPlanet fark:Python - First Impressions from Hacking PlanetPlanet blogmarks:Python - First Impressions from Hacking PlanetPlanet Y!:Python - First Impressions from Hacking PlanetPlanet smarking:Python - First Impressions from Hacking PlanetPlanet magnolia:Python - First Impressions from Hacking PlanetPlanet segnalo:Python - First Impressions from Hacking PlanetPlanet

no comments

dojo iconprototype iconscriptaculous icon

Dojo and Prototype Together

Posted in , , , , Wed, 14 Jun 2006 02:31:00 GMT

I just wanted to report and let everyone know with Prototype 1.5.x, Dojo Toolkit and Prototype should now be interoperable. Earlier versions of prototype.js extended the JavaScript Object prototype that would break third-party JavaScript but this is no longer being done. A few people, including myself, have been using them together without any problems. The prototype website still offers 1.4.0 as the current version, however 1.5.0 rc0 is included with Scriptaculous 1.6.1. I'm currently using prototype 1.5.0 rc0 with Dojo 0.3.1 and Scriptaculous 1.5 rc4. Although Scriptaculous 1.6.1 is available, it breaks autocomplete for me and I haven't had time to track down what changed yet. Hopefully soon.

UPDATE: The Scriptaculous 1.6.1 issue has been reported to RoR as ticket #5673. This has since been fixed with Scriptaculous 1.6.2. I'm now using Dojo 0.3.1, Prototype 1.5.0 rc0 and Scriptaculous 1.6.2.

UPDATE 2: When running dojo.js and scriptaculous.js together, make sure you load dojo.js first. Loading scriptaculous.js first will cause Dojo to fail. and Prototype Together digg:Dojo and Prototype Together reddit:Dojo and Prototype Together spurl:Dojo and Prototype Together wists:Dojo and Prototype Together simpy:Dojo and Prototype Together newsvine:Dojo and Prototype Together blinklist:Dojo and Prototype Together furl:Dojo and Prototype Together fark:Dojo and Prototype Together blogmarks:Dojo and Prototype Together Y!:Dojo and Prototype Together smarking:Dojo and Prototype Together magnolia:Dojo and Prototype Together segnalo:Dojo and Prototype Together


prototype iconcatalyst iconperl icontemplatetoolkit iconscriptaculous icon

HTML::Prototype - AJAX Without JavaScript

Posted in , , , , , Tue, 06 Jun 2006 01:52:00 GMT

HTML::Prototype is by far the most painless way to get started with AJAX that I've found. Simply put, you do not need to know or write any JavaScript! HTML::Prototype is a Perl module on CPAN that wraps the prototype AJAX library and effects library with Perl helper methods so you don't need to write a single line of JavaScript to get some great effects. There are also a number of modules that wrap HTML::Prototype for integration with Catalyst, CGI::Application, Template Toolkit and others.

There are a number of convenient methods such as link_to_remote() and submit_to_remote() that create a link and form button to make an AJAX call and populate the innerHTML of a specified DOM element with the response body. Syntactic sugar to be sure as the JS generated by HTML::Prototype is very simple once you look at it, but the beauty is that you never have to.

To truly appreciate HTML::Prototype you need to use some of Scriptaculous' more advanced widgets such as autocomplete. Sebastian Riedel put together a screencast using Catalyst that demonstrates how easy it is to use. Links to the screencast are available on the Catalyst wiki movies page:

Another great thing about having HTML::Prototype generate the JS syntax for you is that you can learn prototype syntax just by View Source. I picked up enough of prototype's JS syntax this way that I haven't looked at the docs yet.

I've recently removed HTML::Prototype from a project in favor of using prototype.js and scriptaculous.js directly and I'm evaluating the Dojo Toolkit but HTML::Prototype let me get started with very effective, painless AJAX functionality. I used it with Catalyst::Plugin::Prototype and thought 'this is how frameworks make you productive.' Thanks to all the contributors. - AJAX Without JavaScript digg:HTML::Prototype - AJAX Without JavaScript reddit:HTML::Prototype - AJAX Without JavaScript spurl:HTML::Prototype - AJAX Without JavaScript wists:HTML::Prototype - AJAX Without JavaScript simpy:HTML::Prototype - AJAX Without JavaScript newsvine:HTML::Prototype - AJAX Without JavaScript blinklist:HTML::Prototype - AJAX Without JavaScript furl:HTML::Prototype - AJAX Without JavaScript fark:HTML::Prototype - AJAX Without JavaScript blogmarks:HTML::Prototype - AJAX Without JavaScript Y!:HTML::Prototype - AJAX Without JavaScript smarking:HTML::Prototype - AJAX Without JavaScript magnolia:HTML::Prototype - AJAX Without JavaScript segnalo:HTML::Prototype - AJAX Without JavaScript

no comments

rails icon

ActiveRecord - Achilles Heel of Ruby on Rails?

Posted in , , Sun, 04 Jun 2006 16:12:00 GMT

IMO, one of the major limitations of Ruby on Rails compared to other frameworks is its ORM, ActiveRecord. ActiveRecord is a fairly early ORM (object-relational mapper) that has made some questionable design decisions and doesn't support some very basic relational database concepts. These issues have been discussed on Joel on Software and elsewhere. Here are some limitations I wish were fixed:

Read more... - Achilles Heel of Ruby on Rails? digg:ActiveRecord - Achilles Heel of Ruby on Rails? reddit:ActiveRecord - Achilles Heel of Ruby on Rails? spurl:ActiveRecord - Achilles Heel of Ruby on Rails? wists:ActiveRecord - Achilles Heel of Ruby on Rails? simpy:ActiveRecord - Achilles Heel of Ruby on Rails? newsvine:ActiveRecord - Achilles Heel of Ruby on Rails? blinklist:ActiveRecord - Achilles Heel of Ruby on Rails? furl:ActiveRecord - Achilles Heel of Ruby on Rails? fark:ActiveRecord - Achilles Heel of Ruby on Rails? blogmarks:ActiveRecord - Achilles Heel of Ruby on Rails? Y!:ActiveRecord - Achilles Heel of Ruby on Rails? smarking:ActiveRecord - Achilles Heel of Ruby on Rails? magnolia:ActiveRecord - Achilles Heel of Ruby on Rails? segnalo:ActiveRecord - Achilles Heel of Ruby on Rails?


dojo iconscriptaculous icon

Dojo's ComboBox Not Ready for Prime Time?

Posted in , , , Sun, 04 Jun 2006 06:21:00 GMT

I've been happily developing with Prototype and Scriptaculous for a while now but was recently convinced to look at Dojo. To start, I was pretty happy with but disappointed that I wasn't able to get the Dojo scripts to load from a remote server. Having gotten to work, I was off to test my first widget, Dojo's ComboBox, which offers functionality similar to the Scriptaculous autocomplete widget. I've been using Dojo 0.3.0. The Dojo ComboBox Nightly Test is often mentioned as a good place to start so I went there first. Eventually I also spent some time reading and implementing the code at's AJAX with Dojo and JSON page. In the end I came away disappointed due to several bugs and strange behaviors listed below:

  1. Default value: Dojo does not let you set a default value via the HTML or any other way. To get a default value to show up, I've heard you can write it in with JavaScript but I'm not sure where or when yet due to the DOM onLoad transform issue described below.
  2. Single option bug: when the a resulting list only has one item, hitting the 'enter' key will not close the list. With autocomplete, the single entry will already be populated in the box but not selectable with 'enter'. You need to select the single option in the list with the down key and then hit the 'enter' key. To try this out, type in 'am' for American Samoa in the first input on the nightly test and click 'enter' to continue. I haven't found out whether this is being worked on or not.
  3. DOM onLoad transform: Unlike other libraries, after the page has been rendered Dojo will go back and transform the DOM, replacing dojoTypes with HTML templates. This can cause some timing problems when one wants to use DOM to modify the resulting HTML templates. Dojo provides a dojo.addOnLoad capability to specify a callback function however the new DOM elements don't seem to be available yet. Perhaps something to the effect of dojo.afterDojoOnLoad is needed? This issue can be seen when trying to remove the ComboBox downArrowNode. The ComboBox comes with a down arrow graphic by default and is assigned dojoattachpoint="downArrowNode". With some lists, the reply possibilities are enormous and a default list isn't desirable. When nothing has been typed, it may also give the impression that the list provided is a complete list like a standard select element. I haven't found a good way to disable this yet. Setting the display property on the downArrowNode isn't a good solution because it only works after the page has been rendered. It can't be set immediately rendering the ComboBox input tag because Dojo hasn't been run yet. Setting the display property in the dojo.addOnLoad callback is also too early, i.e. the widget doesn't exist yet. Here's the JS I've been working with:
    var ac = dojo.widget.byId("ac");"none";
    I've also tried setting downArrow and downArrowNode attributes to 0, -1 and false. So far, the only solution I found that works is to delete or comment out the downArrowNode HTML in the following file:
    Not exactly a great solution. Is there a better way to remove the arrow?
  4. Client-side result filtering: It seems like the Dojo javascript does it's own filtering. You give it a list in the format of an Array of Arrays where each inner array has two elements. Dojo then applies it's own filtering. This is nice if you are working off a local list such as a JS file in the Nightly Test example but if you are retrieving a list from a server, the server should have filtered the list already so there's no reason to filter it a second time. This may be partially at fault for the choppy rendering. Is there any way to disable this?
  5. Aribitrary location match: Because Dojo does client-side result filtering, the user isn't guaranteed to see what your server delivers. One area this shows up is that it's not clear how to match any part of the string instead of just the beginning. On the nightly test page, the only results presented are ones where the input matches the start of the string so if someone types a last name and the strings have the format "$first_name $last_name" there would not be a match. The DocTool on will match inside the string but the rendering seems choppy and I can't seem to locate it any more. I haven't gotten around to seeing how the DocTool does it. The SVN copy of the doctool.html file shows the following which does not result in the desired non-start match for me:
        style="width: 300px;"
  6. HTML result rendering: Often it's nice to show the user which part of the string matched, especially if the match is not at the beginning of the string. This is done by bolding the matching letters a la Gmail. If HTML is included in the array, it is rendered literally instead of interpreted as HTML. Because Dojo does client-side filtering, HTML mark up will also cause matching to fail. With Scriptaculous, you can add HTML mark-up to the results and it will render properly. Perhaps with Dojo, the HTML needs to be added by client-side JavaScript?

These are my initial observations of Dojo's ComboBox. It seems very difficult to get it to DWIW and very different than the Scriptaculous Autocomplete which just works and has been working. Scriptaculous autocomplete has been working like champ for me since prototype 1.3.1 and it's now on 1.5.0 rc0. Please let me know of any ways to accomplish the above Dojo ComboBox issues. Also let me know if you're using Dojo's ComboBox in production and / or your experiences with it.'s ComboBox Not Ready for Prime Time? digg:Dojo's ComboBox Not Ready for Prime Time? reddit:Dojo's ComboBox Not Ready for Prime Time? spurl:Dojo's ComboBox Not Ready for Prime Time? wists:Dojo's ComboBox Not Ready for Prime Time? simpy:Dojo's ComboBox Not Ready for Prime Time? newsvine:Dojo's ComboBox Not Ready for Prime Time? blinklist:Dojo's ComboBox Not Ready for Prime Time? furl:Dojo's ComboBox Not Ready for Prime Time? fark:Dojo's ComboBox Not Ready for Prime Time? blogmarks:Dojo's ComboBox Not Ready for Prime Time? Y!:Dojo's ComboBox Not Ready for Prime Time? smarking:Dojo's ComboBox Not Ready for Prime Time? magnolia:Dojo's ComboBox Not Ready for Prime Time? segnalo:Dojo's ComboBox Not Ready for Prime Time?


Older posts: 1 ... 7 8 9 10