There are a couple of steps, most of which are geared towards having authlogic not produce redirects and instead produce http status codes that are interpretable to the applications. Here’s an example of what I mean from my ApplicationController on an app

  def require_user
    unless current_user
      store_location
      flash[:notice] = "You must be logged in to access this page"
      respond_to do |format|
        format.html { redirect_to new_user_session_url }
        format.xml  { render :text => "you must be logged in to access this page.", :status => :unauthorized }
      end
 
      return false
    end
  end

In the default implementation of this filter, it always returns a redirect. ObjectiveResource can follow the redirect (if you have a recent enough version), but it doesn’t really do it a lot of good. This way, you get a status code that you can use.

Since Authlogic focuses on RESTful creation of things, a lot of operations map naturally. To create an account on the Rails app, create a User object, and to test whether the user can log in, create a user session. My application stores credentials between iPhone App invocations, so it creates a UserSession at startup if you have stored credentials.

- (void)applicationDidFinishLaunching:(UIApplication *)application {
//
// ... blah blah blah all sorts of stuff removed.
//
 
	UserPrefsManager* prefs = [UserPrefsManager sharedInstance];
 
	if ([prefs isLoggedIn]) {
		UserSession * us = [[[UserSession alloc] init] autorelease];
 
		us.login = [prefs username];
		us.password = [prefs password];
 
		NSError * err = nil;
 
		if(![us createRemoteWithResponse:&err])
		{
//
//  ... my actual detection stuff removed and just the default left ...
//
			[AlertHelper showAlertWithError:err];
			[prefs clearLogin];
		}
	}
	[ObjectiveResourceConfig setUser:[prefs username]];
	[ObjectiveResourceConfig setPassword:[prefs password]];
//
// ... and proceed on with your app's normal course of things ...
//	
    [window addSubview:tabBarController.view];
}

You see here that i’m creating an UserSession here and testing to see if it works and setting the ObjectiveResourceConfig properties if it does. I have some logic where if there isn’t saved credentials you will get a dialog asking you to login or create an account (or whatever) later on, which is the point of [prefs clearLogin];. This is matched by a change to the create method of the UserSessionController:

      respond_to do | format |
        format.html do
          flash[:notice] = "Login successful!"
          redirect_back_or_default account_url
        end
        format.xml do
          render :xml => @user_session, :status => :created
        end
      end

(For brevity, I’ve just shown the successful branch)

This should be enough to get people going — all the other changes you have to make can be figured out from these two statements, and when I have some spare time I’m going to create a version of the demo application that works with ObjectiveResource. The only other suggestion I have is to use the withResponse: versions of everything and code defensively, and note that in some versions of ObjectiveResource getting an error from your application will cause the application to throw. In the meantime, feel free to ask me any questions

Complicated general solutions (such as that found in GeoNames for a lot of content information, but it doesn’t federate that with other results and uses a couple of other data sources that aren’t relevant to this.)

Here’s the (relatively trivial) code that does ‘content’ (normally: fulltext but in content management systems called ‘content search’) searching.

module Contentsearch
  module ClassMethods; end
  def self.included(klass)
    klass.extend(ClassMethods)
  end
 
  def ft_index
    logger.debug("[contentsearch::ftindex] submitting #{self.id} #{self.name}")
    Bj.submit "./script/runner jobs/add_to_consearch.rb -t #{self.class.name.downcase} -i #{self.id}"
  end
 
  def ft_deindex
    logger.debug("[contentsearch::ftdeindex] removing #{self.id} #{self.name}")
    Bj.submit "./script/runner jobs/remove_from_consearch.rb -t #{self.class.name.downcase} -i #{self.id}"
  end
 
  module ClassMethods
    def ft_search(kw_string)
      clsname = self.name.downcase + "s"
      return self.find_by_sql(["select distinct #{clsname}.id, lots of stuff i deleted here, MATCH(content) against (?) as relevance FROM #{clsname},consearches WHERE consearches.ftable_id = #{clsname}.id and consearches.ftable_type='#{self.name}' and match(content) against (?) order by relevance limit 6",kw_string,kw_string])
    end
  end
end

This example is written in Ruby (on Rails), and the first part is just a convention for putting class methods into a ruby class. How Ruby (and smalltalk and similar languages) handle methods is a fascinating but different discussion but essentially it’s a metaprogramming party and everyone’s invited.

Ruby makes this relatively simple to add as a module to pretty much any class. The reason that ft_index and ft_deindex run in a background process is because taking a document in or out of a fulltext indexed mysql database is way slower than you would want to present to the user in an interactive process. This is common in web applications and is part of why you see things like “your [whatever] may not appear in searches right away” from a lot of applications. If you leave them to run on their own they’re fast enough but generally would make the user unhappy.

But basically, what’s going on here is that there’s two separate tables (and different table types in mysql — one of which does fulltext searching and the other of which has ACID properties.) By joining these two tables together, you can search against the content tables and get results back from the main table that stores domain objects. This is probably the simplest version of federating two different search types together. It works pretty smoothly and this sort of thing is in a number of different products.

(And for rails people, the relevant string in the model classes for this is has_one :consearch, :as => :ftable)

But this is obviously trivially simple: the objects in the content search table are representations of the objects in the main table, and there are entirely separate semantics between the two tables (and unfortunately i deleted the examples using both the main and consearch table, but it’s a join and you get the idea.) One of the tables does ‘field operator value’ type searching (ie: relational) and the other is the kind referred to these days as ‘google searching.’

Things get progressively more difficult when one of these things aren’t true — that there isn’t a store that has the single unified version of the document or that the semantics are related but not either identical or entirely different. For example, if I’m searching two different instantiations of my own product, it’s fairly easy — all the fields mean the same thing between the two different databases.

If the products differ by schema or meaning of the schema, you have to make a (semantic) translation between the two to make the search work, and also you have to make some sort of translation on the search results to have the results displayed to the user in a way that makes sense. This might be as simple as ‘one repository has names and one things have titles’ or it might be more complex (names versus ids, names in particular formats, URLs versus descriptive strings, date formats that give seconds versus those that are accurate to the day, etc…)

It’s when you start combining these sorts of things that stuff starts getting more complex. (This is also leaving aside the issue that the protocols to access all of this information is different (although these days more and more of this becomes an adventure in XML parsing and not DLL hell.) Let’s take a simple example, sorting.

Say I have three different datastores Repo1 – Repo3, and they both return objects with titles on them, and I’m sorting the titles:

Repo1: [Alpha, Bravo, Charlie, Delta, Echo, Foxtrot ]
Repo2: [Able, Baker, Charlie, Dog, Easy, Fox]
Repo3: [Alligator, Crocodile, Pterosaur]

It’s fairly easy to implement this sort, there are a few small issues (like paging results versus the page sizes of the underlying repositories, but regardless alphabetic sorts are well-understood in most locales.

However, if you’re searching by something more like ‘relevance‘, you get back a number associated with each result (so the document that had the ‘Alpha’ before might have a score of ’0.91′). It’s simple to order numbers as well, but how do you tell that a number in one datastore corresponds to a number in another? For one thing, those numbers are calculated (mostly) with regards to the particular collection of documents on a given datastore and for another, one repository may just tend to return a higher number for documents that are theoretically as relevant (because there isn’t any agreement about what 0.91 means, it’s just what a function returns.)

So those two things are where it starts to get more complex and needing actual customization and specialization.

In conclusion, this is way too (f) long for the blog, but I was typing it up to explain things that I was talking about yesterday anyway. HTH. Feel free to comment, but if you’re the person I’m proximately writing this for, you should probably send email.

I actually have another version of the same code that puts a URL in the debug log that can be used to click directly to google maps. Why? I don’t know. I’m beginning to value Aptana Studio’s remix of Eclipse more and more as time goes on though because I now have Java, PHP, and Ruby/Rails all in the same highly (mostly) performing IDE. The alleged iPhone mode doesn’t work on my computer but I have CRAZY LIBERRIES installed at the moment and I suspect that that’s in large part my own fault — the apple tools still work.

  def geo_desc ( geo_loc, extended = false)
     #
     #  specialized pretty printer for address types.
     #  note that there is pretty much a standard mixin for geo stuff and
     #  this works across all the geocoding packages and model types.
     #
     return "[nil location]" if geo_loc.nil?
     desc = "[" 
     desc < < geo_loc.country_code.downcase unless geo_loc.country_code.nil?
     desc << "." + geo_loc.state.downcase unless geo_loc.state.nil?
     desc << "." + geo_loc.city.downcase unless geo_loc.city.nil?
     desc << "." + geo_loc.zip unless geo_loc.zip.nil?
     desc << "] "
     desc << "["
     desc << geo_loc.lat.to_s unless geo_loc.lat.nil?
     desc << ","
     desc << geo_loc.lng.to_s unless geo_loc.lng.nil?
     unless geo_loc.precision.nil? or geo_loc.precision == "unknown"
       desc << " (" + geo_loc.precision + ")" 
     else
       desc << " ?"
     end
     desc << "]"
     if extended
       desc << " " + geo_loc.full_address unless geo_loc.full_address.nil?
     end
     return desc
  end

So, the key method of invitation to a private beta is that you mail someone a code allowing them access to the system, for these purposes, let’s just assume that the code is some reasonably long unique string (in my code, it’s actually a uuid.) So, set up a migration something like this to manage them:

  def self.up
    create_table :invites do |t|
# deleted stuff
      t.string :guid
      t.integer :used_yet
# deleted stuff
    end
  end

used_yet isn’t a boolean for reasons that are too laborious to go into here, but reflect some functionality in the code that I’m not going to display. Assuming that you’re using acts_as_authentication and are redirecting anyone who tries to access your app to the default welcome page according to the usual methods, set up something like this in your routes.rb:

  map.root :controller => "welcome"

This is probably the case in like half the rails apps out there. Have the index method of the welcome controller put up a form with a field like:

#let's see if the formatter can handle rails erb without exploding.
< % form_tag('welcome/checkinvite', :method=>:get) do -%>
  < %= text_field_tag 'invite' %>
  < %= submit_tag 'begin' %>
< % end -%>

This lets the user enter their invite in more or less the normal method. Now in your ‘welcome’ controller, you’ll need a ‘checkinvite’ method that looks something like the following:

 def checkinvite
    @inviteguid = params[:invite]
    @invite = Invite.find_by_guid(@inviteguid)
    if(@invite == nil)
      flash[:notice] = "Your invite was invalid"
      redirect_to root_url
      return
    end
    if(@invite.used_yet == 1)
      flash[:notice] = "Your invite had already been used"
      redirect_to root_url
      return
    end
  end

After this, you’ll need to have some code in your HTML page that links you to the account/signup functionality of acts_as_authenticated. I’m not going to include that because I’m too lazy to fish it out of my app functionality, but you can do that pretty much with a link_to using :invite=%gt;@invite_guid as an extra parameter.

You need to put the same invite detection code in account/signup, and then when you’ve created the account, set invite.used_yet = 1. This is about as simple as a method that I can think of for doing the private beta functionality that seems to be so much in vogue these days. Enjoy.