Dev411 Blog: Category scriptaculous

Online Dojo JavaScript Compressor

John Wang — Fri, 28 Jul 2006 12:14:00 -0500

I just put together an online JavaScript Compressor interface to Dojo Toolkit's JavaScript Compressor, custom_rhino.jar. The JavaScript Compressor is used in the final stage of the Dojo Toolkit build process so gets a lot of use. Although there is already an online version, ShrinkSafe, I put another version together because:

It would be nice to have a web app that makes custom Dojo builds people don't have to install the JDK and ant to get a custom Dojo build. This is the primary reason and the compressor is a first step in that direction.
There have been some reports that the JS produced by ShrinkSafe doesn't work (maybe it's using an outdated custom_rhino.jar?). I want an Dojo-based online system to use myself.
It's nice to have more Dojo, Prototype and Scriptaculous integration tests. I used the client code from ShrinkSafe which uses Dojo to add additional file and do Drag-and-Drop along with the Lucid theme which relies on Prototype and Scriptaculous. I learned that dojo.js 0.3.1 needs to be loaded before scriptaculous.js 1.6.1 or Scriptaculous will break Dojo (I updated the Dojo and Prototype Together article). My minimal use of the Lucid theme actually doesn't need scriptaculous.js so I can get away with loading just dojo.js 0.3.1, prototype.js 1.5.0 rc0, effects.js (part of Scriptaculous 1.6.1) and lucid.js. lucid.js is part of the Lucid theme.

The JavaScript compressor eats its own dogfood and uses prototype.js, effects.js and lucid.js compressed into a single-line, single file. Here are the compression sizes and ratios for the files. Generally you save about 30%.

script	uncompressed	compressed multiline	ratio	compressed single line	ratio
prototype.js	55,149	38,696	70%	37,154	67%
effects.js	32,908	23,244	71%	22,527	68%
lucid.js	7,253	4,917	68%	4,741	65%
All files	95,310	67,570	71%	65,137	68%

A number of people are using JavaScriptCompressor.com which is running Dean Edwards' .NET JavaScript compression code. This can be used after Dojo's compressor for even more compression.

Prototype's future in Rails

John Wang — Thu, 20 Jul 2006 17:22:00 -0500

The future of Prototype (the JavaScript AJAX library), both as a stand-alone library and as a part of Rails, is being discussed by the community on the rails-spinoffs list. The primary concerns appear to be:

Prototype is driven by one person who hasn't been very active on the list. Some patches are integrated but often without communication
it is difficult for others to contribute
there is no visibility into the roadmap for prototype
prototype is "falling behind" relative to other libraries

The one person vs. community aspect of the discussion reminds me of Red Hat rebuilds. When Red Hat stopped distributing free binaries, a number of projects took advantage of GPL and started providing free rebuild binaries. At first, White Box Enterprise Linux (WBEL) was the most popular and wide-spread rebuild but it was maintained by one person who occasionally got busy. It was eventually overtaken by CentOS which is maintained by a community.

For now, Prototype will remain popular because it comes bundled with Rails and is the basis for RJS and Scriptaculous. Thomas Fuchs has come out and said, "script.aculo.us will always depend on Prototype". Still, I wonder if community maintenance isn't a better way to go for something that's relied on by so many people. Some are even concerned that Rails itself will become less viable if it continues to attach itself to Prototype and the project management doesn't change.

You can follow the thread by going to the list archives page and looking for the subject name "Documenting Prototype...". Greg Hill's post seems like a reasonable place to start.

Autocomplete Survey

John Wang — Mon, 17 Jul 2006 23:15:00 -0500

Here are some screen shots of various autocomplete effects in action to show what people are doing. The images and names above the images have links to the relevant sites with the domain name shown. I'll add more screen shots here as I get them. Let me know if there are any other toolkits demos or interesting implementations.

Here are some observations:

All of the screen shots and links are for toolkits except for Google which is just shown as an example.
The jQuery and Scriptaculous demos do not automatically display "autocomplete" text in the input element.
All of the demos, except Dojo, include text that will end up in the input field as well as extra display text that will not.
Where both simple and customized demos are available, the customized one is used for the screen shot.
Del.icio.us also has nice variable horizontal location/width autocomplete for tags that I don't have a screen shot for atm. Gmail also has a nice autocomplete that isn't shown.

The observations are just for the particular demos available. The libraries may have the ability to be configured in additional ways.

Dojo (dojotoolkit.org)

(fullsize screen shot)

jQuery (jquery.com)

(fullsize screen shot)

Yahoo UI (yahoo.com)

(fullsize screen shot)

Google (google.com)

(fullsize screen shot)

Scriptaculous (script.aculo.us)

(fullsize screen shot)

NOTE: The jQuery screen shot has been edited to size it better from the demo page: (a) the number of results was reduced and (b) the width has been reduced because there's a lot of blank space in the demo. The original jQuery screen shot is also available.

UPDATE: CAPXOUS has an interesting paged autocomplete variation which adds Next and Prev links when applicable. The one minor issue I ran into when using this is that it would switch location (above/below the input) if it was near a browser edge and the number of items changed as shown below. I found this a bit disconcerting. I wonder if there's a way to making it always used the side for the larger list? CAPXOUS can also show info that's searched on but not shown but this was less interesting than the paging. One final note, unlike the other JS libraries listed above which are free open source software (FOSS), CAPXOUS is commecial requires a license fee. Pretty interesting idea.

CAPXOUS (capxious.com)

(fullsize screen shot)

Scriptaculous article slider for Typo themes

John Wang — Wed, 12 Jul 2006 01:48:00 -0500

Several Typo themes have nice DHTML effects and I thought it would be useful to extract some of these for use in other themes. In particular I am interested in adding Modernist's DHTML Scriptaculous ScrollTo article slider to my modded Azure theme. You can see this in action at poocs.net which is currently running Modernist. This article covers the steps necessary to repurpose the DHTML article slider and involves templates, CSS and images. I've shown how Modernist does it and, where applicable, how I prefer to do it. It turns out to be pretty easy.

I've added this feature to my test system, however it's not here yet because I've decided to create a custom Dev411_Azure theme to handle the views (and controller/helper patches) for the growing number of mods I'm using rather than to continue manually hacking files under themes/azure and app. This should be here before long.

The things discussed here are the changes necessary to add the DHTML slider to a theme of your choice. For the files below the path part ... should be along the lines of "themes/#{mytheme}" but can be simply app if you don't mind losing your changes when the admin console is used to change themes.

I'll show where my preferences deviate from Modernist's implementation. My pet peeve is the use of the extra @ta instance varaible since it's unnecessary and the name isn't self-explanatory. I'll use each_with_index with article_index as the index name.

.../views/articles/index.rhtml: in order to know the which article is next, Modernist introduces a counter called @ta in the index.rhtml file. I'll probably name this something more intuitive like @article_index but here's the code from: themes/modernist/views/articles/index.rhtml

Modernist:
```
<% @ta=0 %>
<% for article in @articles -%>
  <%= render_partial "article", article %>
  <% @ta+=1 %>
<% end -%>
```
My preference:
```
<% @articles.each_with_index do |article,article_index| -%>
  <%= render :partial => "article",
             :object  => article,
             :locals  => { :article_index => article_index }
  %>
<% end -%>
```
- use each_with_index instead of creating an extra counter since the index is already available
- use render instead of render_partial just because the former was indicated as preferred on the #typo channel
- use self-explanatory variable names: article_index instead of ta
- I would actually prefer to send the article object to the render method as a local variable since that's what it seems to be and I don't see a reason to treat it differently.
```
:locals => {
    :article => article
    :article_index => article_index
}
```
  instead of as :object but I can't be sure that will always work since article is also the name of the template and there's some magic there.
.../views/articles/_article.rhtml: there are two pertinent changes in this file: (a) the Scriptaculous ScrollTo controls and (b) adding a DOM id to the article header that can be navigated to.
- ScrollTo controls: In the Modernist theme, the Scriptaculous controls are embedded directly in _article.rhtml as follows. Another option is to put it in a separate _article_flip.rhtml template include but I'm not sure if this will be automatically copied in by Typo's theme admin manager. In any event, the following should be added to the top of _article.rhtml either directly or as an include. Notice the innerHTML of the links below is a space. The links will be rendered as graphics once the CSS is enabled.
  
  Modernist:
```
<div class="flip">
<a href="#header" onclick="new Effect.ScrollTo('header'); 
  return false" class="flip-top"
  title="Scroll to the top"> </a>
<% if @ta < (@articles.size-1) %>
<a href="#post-<%= @ta+1 %>"
  onclick="new Effect.ScrollTo('post-<%= @ta+1 %>');
  return false" class="flip-next"
  title="Scroll to the next post"> </a>
<% end %>
<a href="#menu" onclick="new Effect.ScrollTo('menu');
  return false" class="flip-menu"
  title="Scroll to the menu"> </a>
</div>
```
  The Modernist theme places the menu at the bottom of the page so having a control go to menu makes sense. For a more traditional theme like Azure, I added a <div id="bottom"> around <p id="pagination" to indicate the bottom and changed the last link above accordingly.
  
  My preference:
  - Change the @ta references to article_index as above
- article anchor: The next change is to add a DOM id with the article index to each article's title:
  
  Modernist:
```
<h3 id="post-<%= @ta %>">
  <%= article_link article.title, article %>
  <%= author_link(article) %>
```
  My preference:
```
<h3 id="post-<%= article_index %>">
```

CSS: Copy the CSS definitions that begin with .flip to one of your CSS files:

.flip {
        float: left;
        position: absolute;
        opacity: 0.9;
        margin: 0 0 0 -65px;
}

.flip a {
        display: block;
        width: 25px;
        height: 16px;
        padding: 4px;
        background-position: center center;
        background-repeat: no-repeat;
}

.flip-menu { background-image:
  url('/images/theme/flip-bottom-0.gif'); }
.flip-next { background-image:
  url('/images/theme/flip-down-0.gif'); }
.flip-top { background-image:
  url('/images/theme/flip-top-0.gif'); }
.flip-comments { background-image:
  url('/images/theme/flip-comments-0.gif'); }
.flip-post { background-image:
  url('/images/theme/flip-post-0.gif'); }
.flip-menu:hover { background-image:
  url('/images/theme/flip-bottom-1.gif'); }
.flip-next:hover { background-image:
  url('/images/theme/flip-down-1.gif'); }
.flip-top:hover { background-image:
  url('/images/theme/flip-top-1.gif'); }
.flip-comments:hover { background-image:
  url('/images/theme/flip-comments-1.gif'); }
.flip-post:hover { background-image:
  url('/images/theme/flip-post-1.gif'); }

control images: the last step is to copy the control images to the right location. These are the flip-post-[01].gif images referenced in the CSS. Copy these to the correct directory.

That's it, you should be able to get up and running.

Typo Themes Viewer 0.2

John Wang — Sat, 01 Jul 2006 18:41:00 -0500

I updated the Typo Themes Viewer with the following features:

Lucid theme: No longer a drab gray :) The theme viewer currently uses a fluid layout for non-IE browsers and a fixed layout for IE since I ran into some issues using the fluid layout on IE. Even with the wider left and right margins, I can still get 6 thumbnails across on my 1400x1050 screen for easy viewing.
Lightbox image viewer: The Scriptaculous Sortable effect has been removed and replaced with Lightbox (which relies on Scriptaculous). When you click on the thumbnail now a medium sized graphic will appear. Let me know how it works for you.

As before, I'm more than happy to add new themes as they become available. Just post a comment here with the uri(s).

The new look:

Using Lightbox:

On a final note, Lightbox 1.x allowed you to close the lightboxed image by clicking on it. In Lightbox 2.x, this has been disbled to allow the group feature to function. If you are only using single images or run separate copies of lightbox.js for singles and groups you can make the following mod to allow closing by clicking on the single lightboxed image:

// look for the following line:
objImageContainer.appendChild(objLightboxImage);
// then add this after:
objImageContainer.onclick
  = function() { myLightbox.end(); return false; };

Thanks to Tyler Mulligan for this solution.

Dojo and Prototype Together

John Wang — Tue, 13 Jun 2006 21:31:00 -0500

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.

HTML::Prototype - AJAX Without JavaScript

John Wang — Mon, 05 Jun 2006 20:52:00 -0500

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 Script.aculo.us 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:

http://dev.catalyst.perl.org/wiki/Movies

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.

Dojo's ComboBox Not Ready for Prime Time?

John Wang — Sun, 04 Jun 2006 01:21:00 -0500

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 dojo.io.bind but disappointed that I wasn't able to get the Dojo scripts to load from a remote server. Having gotten dojo.io.bind 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 Java.net's AJAX with Dojo and JSON page. In the end I came away disappointed due to several bugs and strange behaviors listed below:

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.
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.
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");
ac.downArrowNode.style.display="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:
```
dojo/src/widget/templates/HtmlComboBox.html
```
Not exactly a great solution. Is there a better way to remove the arrow?
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?
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 dojo.org 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:
```
<input
    dojoType="combobox"
    id="search"
    autoComplete="false"
    value=""
    style="width: 300px;"
>
```
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.