Cobalt Edge

 
Filed under

JavaScript

 

Workaround for jQuery Autocomplete Plugin mustMatch Fail on Commas

The jQuery autocomplete plugin is quite nice, and we use it a fair bit on DealBase.  However, what I found was that if you set the mustMatch option, your text cannot contain commas, colons, and a few other punctuation (and maybe other) characters.  For some reason that I've yet to track down (debugging through many nested anonymous functions and callbacks has yet to yield an answer), it thinks it changes at some point to not think it's a match. A good example of this is if you allow a user to type in a city name, but you want to show them matching cities with the state and/or country included, to disambiguation.  E.g. you may have Portland, Oregon and Portland, Maine (not to mention the few Portlands in Australia :)

What I found fixed it for me was to set the matchSubset option to true.  This allowed it through, retaining the full text of something like "Portland, Oregon".  According to the plugin's docs, matchSubset should only come into play when using the cache, which we don't use (because we limit results to 20 items, and often there are more than 20 matches, e.g. a user types "new" or "las" or something - many cities will match).  

I'd still like to track down the real bug here, but since others have run into this, and I've yet to see any other solutions, I wanted to post that, in hopes it'll help some other person suffering from this.

Update: even setting matchSubset to true, did not solve the problem where you have a dash/hyphen in the string, and the part that matches is to the right of the dash.  Removing the dash is the only thing I've figured out to make it work.

Loading mentions Retweet
Filed under  //   JavaScript   jQuery  

Comments [4]

Front End Rails Developer Job at DealBase.com

At DealBase, we have an opening for a part-time front end Rails developer at DealBase.com. The opening is for US residents only, and for individuals, no agencies or recruiters please. Most likely you'd be working remotely/telecommuting. The job posting, which is posted in several places, such as Rubynow, Working With Rails, and Rubyjobs.in, covers all the details, but I'll relist it here for ease:


DealBase.com, a startup hotel deals site, is looking for a stellar front end web developer who will adapt our current look/feel to new features, leverage JavaScript for useful and fun features, and is eager to apply their skills to enhance the user experience of our site. We're looking for you to share your knowledge and make an impact, be passionate about your work, and up-to-date on the latest technologies. If this is you, and you enjoy working with a small, distributed, agile team, then we'd love to talk with you.

Requirements for this position:



  • Deep knowledge of XHTML and CSS

  • Familiarity with browser capabilities and restrictions for all major browsers

  • Solid JavaScript skills

  • Experience with/demonstrated use of Git

  • You use and demand MacOS X as your primary development environment

  • Comfortable at the command line

  • Basic skills for image editing and optimization for the web

  • Exposure to and basic knowledge of Ruby on Rails

  • Great communication skills

  • Attention to detail

  • Ability to work both independently and on a team

  • Eagerness to share ideas and problem-solve creatively

  • Experience working on consumer oriented web applications/consumer focus

  • Quick learner, and good at digging in to problems

  • Agile development practices

  • You are based in the US.

  • Individuals only (no multi-person firms, agencies, etc.)
  • Nice to have:



    • jQuery experience

    • GitHub experience

    • MySQL experience

    • Use of test frameworks, TDD, and BDD

    • experience with Linux

    • If you'd like to work with us at DealBase.com and think you're a good fit for this position, send us a resume and sample work, or let us know where we can see your resume and work/code, by emailing jobs@dealbase.com. Please note, we are only considering candidates based in the US.


I'm excited to find a great developer to work with. DealBase has been an awesome company and app to work on, and we're already experiencing great success. We have some pretty cool features planned, and it'd be ideal to get some real CSS and JavaScript ninja skills making those features even better. So, if this is you, please do get in touch, making sure to send email to the right email address as outlined in the job description.

Loading mentions Retweet
Filed under  //   DealBase   git   JavaScript   Jobs   jQuery   Rails   RubyOnRails  

Comments [0]

Update on Rails, jQuery, autocomplete

Today I changed my auto_complete_jquery plugin (which I blogged about previously) to work with a different jQuery autocomplete plugin (that's not confusing is it?!). Previously, I'd been using the "jquery-autocomplete" plugin, but had been having problems with it always being case sensitive, and with it being pretty darn slow. To solve that, I wound up switching to Dylan Verheul's jquery autocomplete plugin, which is fantastic! So, I had to update my plugin (literally changed two lines, along with the readme and some comments).

So, what does it all mean? First, things are no longer case-sensitive (although you can tweak that if you need it, see the docs for DV's jquery plugin). Second, the speed is near instant, and if it's taking any time at all, there's now a CSS style you can set to show an indicator while the AJAX call is running (nice!). Further, there are a slew of options you can set, but one of the coolest things is the ability to set a formatter JavaScript function to adjust the display of the returned results, but without affecting the actual value that is placed in your text field. This is really cool for providing further information about a given matched item. For example, I use it to display, on a line below the matched name, the location of the item. There's an interactive example of this on Dylan Verheul's site.

I highly recommend updating all around on this. For those that might be using my prior version, the changes you'd need to make are:


  • Change your JavaScript calls that make a HTML input into an auto-complete from this format:

    $("input#post_title").autocomplete({ ajax: "auto_complete_for_post_title" })

    to this:

    $("input#post_title").autocomplete("auto_complete_for_post_title")


  • Update to the HEAD of my plugin.

  • Remove the old jquery.ui.autocomplete*.js files, and install Dylan's single jquery.autocomplete.js file, updating your JS includes accordingly. Same goes for the stylesheet.

Note, to do the cool 2nd line output of auto-complete items, you will need to write your own auto-complete Rails action, which means you don't need my plugin :) I may update my plugin at some point so you can pass a block in to the autocomplete function to create this same scenario, but this is pretty specific stuff, so we'll see. As a very brief set of instructions to do this, you can essentially copy-paste the auto-complete method that gets defined by my plugin, and then update what you return as text. To do the 2nd line bit, you want to return items in the format, "item|2nd line stuff", (so use the pipe symbol to separate the two lines). Then, you can use a simple JavaScript formatter function like:


function formatAutocompleteItem(row) {
return row[0] + "<br><i>" + row[1] + "</i>";
}

Then, update your call to the jQuery autocomplete that sets up a field as autocomplete to be:


$("input#post_title").autocomplete("auto_complete_for_post_title", { formatItem:formatAutocompleteItem })

Enjoy!

Loading mentions Retweet
Filed under  //   JavaScript   jQuery   Rails   RubyOnRails  

Comments [3]

Rails, jQuery, auto-complete, and a New Plugin

Update: I've switched which jQuery autocomplete plugin I use for this, see my newer blog entry.

The other day, I made a whole switch from Prototype & Scriptaculous to jQuery. I've had the bug to do this for a while, and this is a new project, so I went for it. I don't have anything against Prototype, so my main impetus for this was a move towards Unobtrusive JavaScript, and also the speed aspect (the site I'm currently working on, if things go accordingly to plan, will do some pretty serious traffic). But, the unobtrusive JavaScript was the key, and really, my switch is more of a philosophy of approach rather than say a dislike for Prototype, etc. And, of course, it's something new to play with :)

Before I go any further, I'll state right now, I am not a JavaScript expert, and I've been using jQuery now for all of a couple hours.

One of the results of my switch however, was that I hacked DHH's auto_complete Rails plugin, to work for jQuery. Simple change. I tweaked the controller macro, and then gutted the JS helpers, as you just don't need those when using jQuery in this way. It does require the jquery-autocomplete plugin for jQuery. I've published my Rails plugin for this on GitHub as auto_complete_jquery.

Circling back around, here's what I did to get all this going. I did run into one issue (see step 10 below) that I'm still tracking down (easy solution in the interim, but I'd like to understand what's happening, so if you have comments, please let me know):


  1. Removed the Prototype and Scriptaculous JS files from the public/javascripts dir of my Rails app. You don't have to do this, but I am no longer using them, so saw no need to keep them there, and it helps ensure I don't mistakenly use something from them or include them in the view. This includes: prototype.js, controls.js, dragdrop.js, and effects.js.

  2. Removed the prototype-based Rails auto_complete plugin from vendor/plugins.

  3. Installed the latest minified jQuery file in public/javascripts/jquery.

  4. Installed the JS files for the jquery-autocomplete plugin, and its dependencies: jquery.templating.js, and jquery.ui.autocomplete.js. (see the jquery-autocomplete plugin for these files).

  5. Added the jquery.ui.autocomplete.css file to public/stylesheets.

  6. Installed my auto_complete_jquery plugin.

  7. Put the proper includes for the CSS file and the JS files in my application layout file:


    <%= stylesheet_link_tag 'jquery.ui.autocomplete' %>
    <%= javascript_include_tag 'jquery/jquery.min', 'jquery/jquery.templating', 'jquery/jquery.ui.autocomplete.ext', 'jquery/jquery.ui.autocomplete', :cache => 'jquery' %>

    Note that I keep my jQuery JS files in a subdir for organizational purposes, but you can modify as needed.

  8. Changed my existing auto-complete text fields that used the Rails Prototype based auto_complete plugin's helpers to just be plain old text fields, such as:
    <%= coffee.text_field :drink, :autocomplete =>"off" %>
    This is doing an auto-complete for the "drink" attribute of the Coffee model.

  9. I can simply leave any auto_complete_for calls that existed in my controller, as that works the same. If you had custom versions that were based on the code from the Prototype-based Rails plugin, just go look at the code in my plugin to see the differences, it's a simple change.

  10. Add the JavaScript that sets up the auto-complete for the given text field. This will typically look like:

    $(document).ready(function() {
    $("input#coffee_drink").autocomplete({ ajax: "auto_complete_for_coffee_drink" })
    });

    Where does this go? It depends. What I've been liking is using the JavaScript auto-include plugin, which creates a Rails-style convention for JavaScript files that pertain to individual actions, or are controller-wide. So in my case, this code would get placed in public/javascripts/views/coffees/new.js, or likely one directory up, as simply coffees.js (so that I can use it in any CoffeesController action that needs to auto-complete on coffee.drink. Without that plugin, you just put it in whatever JS file is appropriately included for the view you're using it in, etc. You can of course put it directly into the view in a script block, but then you aren't doing the whole Unobtrusive JavaScript thing as rigidly.
  11. Finally, what I found is that I had to add a route for this. This is the issue I mentioned above. It sort of makes sense, but what I'm unclear on is, why the prior standard/Prototype-based Rails auto_complete plugin didn't require a route. They both seem to use a GET, define the action the same way, and so on. I'm hoping I'm just missing something obvious. So, the route I added is:
    map.connect ':controller/auto_complete_for_coffee_drink', :action => 'auto_complete_for_coffee_drink', :format => 'json'

A bunch of steps, but pretty simple work. The app I'm doing this on is all of a few days old, so I hadn't gotten into use of much else in Prototype and so on, thus making the wholesale switch easy.

If you'd like to learn more about any of these things, and as a comprehensive set of links:

Enjoy!

Update: I removed the jQuery Dimensions JS file and include for it in my layout, as this is now included in the latest jQuery JS file itself.

Update 2: I don't know how the standard auto_complete plugin manages to do without routes, but here is a generic route for all auto-complete actions across controllers:


map.auto_complete ':controller/:action',
:requirements => { :action => /auto_complete_for_\S+/ },
:conditions => { :method => :get }

I hesitate to put this into the plugin, as routes can be quite tricky in more complex apps, and I wouldn't want to auto-hose someone :)

Loading mentions Retweet
Filed under  //   JavaScript   jQuery   Rails   RubyOnRails  

Comments [0]

Auto-Complete Text Fields in Rails 2

[Note: this entry updated to include required routing, as I failed to mention that the first time.]

In Rails 2, the PrototypeHelper and ScriptaculousHelper code was removed to plugins. This means that doing auto-complete for various fields was no longer part of the base Rails. I didn't find any great, straight-forward docs on how to do this for Rails 2.x, so am sharing what I've done to hopefully help others. Further, the README for this tells you how to do it for standard string fields on a given object, but I needed to do it for an associated object field, so I'll cover that here as well. As you can guess, this only pertains to Rails 2.x...

First you'll need to install the auto_complete plugin:

script/plugin install auto_complete

This plugin will give you the text_field_with_auto_complete view helper method amongst others. It also provides a controller hook ( auto_complete_for) to implement the auto-complete action/method in your controller for you, if that works for the field you need. As per the auto_complete README, it looks like:
class BlogController   auto_complete_for :post, :title
end

auto_complete_for, as used above, would implement a auto_complete_for_post_title method in your controller class. The parameters are the object and field/method of that object. The method it implements will dig through all the Post records in your database and do a LIKE comparison on the title column, comparing the title to the contents of the post[title] form field. With the results, it will generate the HTML for an unordered list (ul), and return that to the view.

This is pretty slick: you can essentially get auto-complete with a view method name change in your HTML (from calling text_field, to text_filed_with_auto_complete), and a single line added to your controller. Now, what happens if the field you want to auto-complete on doesn't directly correlate to a field on your model object? For example, in my case, I wanted to auto-complete on a field from a belongs_to association, so I couldn't use the pre-built auto-completion method that does a direct SQL query on the field.

This is actually easy to solve. You can just implement the auto_complete_for_object_field method yourlself. And, while you're at it, you might as well leverage some of the other helpful methods in the auto_complete plugin. Or, if you need custom view/HTML output, you can just render as you need within that method. When you do this, do not call the controller hook, simply implement the method yourself. Here's mine for example:

def auto_complete_for_doctor_organization
re = Regexp.new("^#{params[:doctor][:organization]}", "i")
find_options = { :order => "name ASC" }
@organizations = Organization.find(:all, find_options).collect(&:name).select { |org| org.match re }

render :inline => "<%= content_tag(:ul, @organizations.map { |org| content_tag(:li, h(org)) }) %>"
end


Finally, for completeness, here's the field's definition in my view template (Erb):
<label for="organization">Group/Practice/Hospital Affiliation</label>
<%= text_field_with_auto_complete :doctor, :organization, :autocomplete => "off" %>

The one counter-intuitive looking thing there is the :autocomplete => "off" bit. Uh, aren't we doing autocomplete? Well, this particular attribute tells the browser to not do it's auto form completion stuff (so that our code can do it instead). Oh, and of course you need to ensure you are including Prototype and Scriptaculous JavaScript libraries in your views, which you can achieve, rather bluntly, with:

<%= javascript_include_tag :all, :cache => true %>

Finally, you will need to add route(s) to your routing file. I use a sort of wild-card route to cover all my auto-completes:


map.auto_complete ':controller/:action',
:requirements => { :action => /auto_complete_for_\S+/ },
:conditions => { :method => :get }

This will resolve any routes that match an action starting with "auto_complete_for_".

With that, we have auto-completing text fields in Rails 2.x! Cool stuff.

Loading mentions Retweet
Filed under  //   ajax   JavaScript   Rails  

Comments [0]