I am a complete Perl novice. But there are occasions when I need to install perl modules. I have learned that
perl -MCPAN -e ‘install (module-name)’
will allow you to install a perl module from the CPAN respository.
So I have been developing MemoryMiner (as my introduction to Rails) for almost six months now, and performance issues are starting to become recognizable. In a desperate attempt to kill two birds with one stone, I upgraded my Linux server (bmw) to Fedora Core 5 this past weekend. It was not uneventful but I finished with MySQL 5.0.22 installed and running for my Rails apps. I also now have ruby 1.8.5 and Edge Rails. Â Unfortunately, the performance is still inadequate, and while I’m perfectly willing to suffer due to limited hardware, I’m pretty sure there is some bloat that needs to be trimmed -particularly in the area of database query tuning.
The first order of business was to get a handle on where my application was spending time. The classic solution, a profiler, applies to Rails as well. I tried the built-in profiler (script/performance/profiler) but was not blown away. Then I found ruby-prof and its graph profiles. I installed the gem and added a real simple around filter in the controller to generate an HTML Graph Profile. Cool -I could exercise a method/URL in a controller and immediately (in another browser) see the results in an easy-to-digest format.
Unfortunately, I could not find a smoking gun.
References:
I’m pretty new to Macintosh development but I’ve been working in Ruby for a couple of years under Win32 and Linux. I was excited by the concept of Ruby and Rails being supported “out-of-the-box” on Leopard with the installation of XCode 3.0. But it didn’t take long for the luster to wear off.I first knew things were not going to be easy when I tried to install MySQL. Since I have a recent MacBook Pro with a Core 2 Duo processor, I went for the x86_64 disk image package (ominous background music starts now). It installed without too many difficulties (but not painless w.r.t the system preference pane). I then went to install the C-based ruby mysql bindings gem:
bimota:lib cch1$ sudo gem install mysql
Building native extensions. This could take a while...
ERROR: Error installing mysql: ERROR: Failed to build gem native extension.
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb install mysql
checking for mysql_query() in -lmysqlclient... nochecking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... nochecking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... nochecking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... nochecking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no
Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /Library/Ruby/Gems/1.8/gems/mysql-2.7/gem_make.out
…and thus began the disenchantment.The failure above is caused by the gem command attempting to compile the native MySQL extensions but not being able to find the necessary library and header files. This can be caused by several more fundamental problems:
Both of the above problems can apparently be solved nicely with one command line option that helps the configurator learn the appropriate build options directly from the MySQL installation:
bimota:mysql cch1$ sudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
Building native extensions. This could take a while...
Successfully installed mysql-2.7
1 gem installed
But you would be foolish to believe that it actually works. Run the same command with the verbose option enabled, and you can see that there is trouble on the horizon despite the apparent success:
bimota:mysql cch1$ sudo gem install -V mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
Installing gem mysql-2.7/Library/Ruby/Gems/1.8/gems/mysql-2.7/COPYING/Library/Ruby/Gems/1.8/gems/mysql-2.7/COPYING.ja/Library/Ruby/Gems/1.8/gems/mysql-2.7/README.html/Library/Ruby/Gems/1.8/gems/mysql-2.7/README_ja.html/Library/Ruby/Gems/1.8/gems/mysql-2.7/extconf.rb/Library/Ruby/Gems/1.8/gems/mysql-2.7/mysql.c.in/Library/Ruby/Gems/1.8/gems/mysql-2.7/test.rb/Library/Ruby/Gems/1.8/gems/mysql-2.7/tommy.css/Library/Ruby/Gems/1.8/gems/mysql-2.7/mysql.gemspec
Building native extensions. This could take a while...
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb install -V mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
checking for mysql_ssl_set()... no
checking for mysql.h... yes
creating Makefile
makegcc -I. -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -DHAVE_MYSQL_H -I/usr/local/mysql/include -Os -arch x86_64 -fno-common -fno-common -arch ppc -arch i386 -Os -pipe -fno-common -c mysql.ccc -arch ppc -arch i386 -pipe -bundle -undefined dynamic_lookup -o mysql.bundle mysql.o -L"." -L"/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib" -L. -arch ppc -arch i386 -lruby -L/usr/local/mysql/lib -lmysqlclient -lz -lm -lpthread -ldl -lm
ld: warning in /usr/local/mysql/lib/libmysqlclient.dylib, file is not of required architecture
ld: warning in /usr/local/mysql/lib/libmysqlclient.dylib, file is not of required architecture
make install/usr/bin/install -c -m 0755 mysql.bundle /Library/Ruby/Gems/1.8/gems/mysql-2.7/libSuccessfully installed mysql-2.71 gem installed
Indeed, when you go to use (not just ‘require’) the gem, you are likely to see this nasty error:
bimota:mmweb cch1$ rake db:version(in /Users/cch1/Documents/Development/mmweb)dyld: lazy symbol binding failed: Symbol not found: _mysql_init Referenced from: /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle Expected in: dynamic lookup
dyld: Symbol not found: _mysql_init Referenced from: /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle Expected in: dynamic lookup
Trace/BPT trap
I’m still have no idea what causes this specific failure, but I suspect it’s related to the compiler options suggested by mysql_config being ignored/munged by the configurator. The gcc command above tries to build for three different architectures (ppc, i386, x86_64) despite mysql_config’s “recommendation” of just x86_64:
bimota:mysql cch1$ /usr/local/mysql/bin/mysql_config
Usage: /usr/local/mysql/bin/mysql_config [OPTIONS]
Options:
--cflags [-I/usr/local/mysql/include -Os -arch x86_64 -fno-common]
--include [-I/usr/local/mysql/include]
--libs [-L/usr/local/mysql/lib -lmysqlclient -lz -lm]
--libs_r [-L/usr/local/mysql/lib -lmysqlclient_r -lz -lm]
--socket [/tmp/mysql.sock]
--port [3306]
--version [5.0.51a]
--libmysqld-libs [-L/usr/local/mysql/lib -lmysqld -lz -lm]
I then try forcing the issue by setting the environment variable as well:
bimota:lib cch1$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_configBuilding native extensions. This could take a while...Successfully installed mysql-2.71 gem installed
Again, it looks promising. But now when Rails asks Ruby (1.8.6 from the default XCode 3.0 install) to load the mysql gem, the OS generates a load error due to some kind of a mismatch:
bimota:mmweb cch1$ script/console
Loading development environment (Rails 2.0.2)
>> require_library_or_gem 'mysql'
LoadError: dlopen(/Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle, 9): no suitable image found. Did find:
/Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle: mach-o, but wrong architecture - /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle
from /Library/Ruby/Gems/1.8/gems/mysql-2.7/lib/mysql.bundle
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:32:in `require'
from /Users/cch1/Documents/Development/mmweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require'
from /Users/cch1/Documents/Development/mmweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in'
from /Users/cch1/Documents/Development/mmweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require'
from /Users/cch1/Documents/Development/mmweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/kernel/requires.rb:7:in `require_library_or_gem'
from /Users/cch1/Documents/Development/mmweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/kernel/reporting.rb:11:in `silence_warnings'
from /Users/cch1/Documents/Development/mmweb/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/kernel/requires.rb:5:in `require_library_or_gem'
from (irb):1
>> ^Dbimota:mmweb cch1$
Why the mismatch? Some googling led me to this post that notes that the Ruby interpreter bundled in XCode 3.0 is in fact only compiled as a 32-bit i386 executable. That’s right: the latest and greatest Macs (with Intel Core 2 Duo processors) running the latest and greatest OS (Leopard 10.5.2) are shipping with a neutered Ruby interpreter.At this point, I see two solutions:1. Install the i386/32-bit only version of MySQL (boo!). I’ve confirmed that this allows a nice working mysql binding to be built with the following command:
bimota:mysql cch1$ sudo env ARCHFLAGS="-arch i386" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
Building native extensions. This could take a while...Successfully installed mysql-2.71 gem installedbimota:mysql cch1$
And not only does it compile, it actually works.2. Recompile Ruby with x86_64 support. That sounds like a bigger job -but there are web sites that show you how to get started. For now though, I’m leaving XCode alone until I know what works -that way, when it breaks, I can assign the failure to the 64-bit ruby interpreter.
The support that Rails has provided for developing RESTful applications is nothing short of amazing considering it was added on long after Rails had an established URL-mapping mechanism (Routes.draw).? But I want more.? Specifically, I want my resources to have a more complete life.
Warning: I am not an expert in Rails or REST.
Background: in the current (late summer 2007) Edge Rails, RESTful resources (ActionController::Resources) are defined primarily for the purpose of creating named routes with a DSL (map.resource …).? A very important by-product of generating named routes is the helper methods available to generate routes in views and controllers.? The net result is a tidy means of generating and recognizing RESTful URIs.? A typical exploitation of these features looks like this:
Repeat steps 2 through 4 as required.
In step one, the Rails programmer does the hard work: modeling the resources, the interface to those resources, the mapping of resources to controllers, etc.? Rails honors our work and uses these abstract resources to recognize routes (in step two) and to help up generate routes (in step four).? But what about step three?? Can we exploit our abstract resource model here?? Let’s recast the typical methods in a controller that backs a resource:
def index
? identify resource
? manipulate resource
enddef destroy
? identify resource
? manipulate resource
enddef create
? identify resource
? manipulate resource
end
For the index action, the identified resource is a collection represented by a Class or an association.? For the destroy (and show and edit) actions, the identified resource is a member represented by an ActiveRecord model instance.? For the create (and new) actions, the resource is a new, unsaved, AR model instance.? Every controller action that handles a REST request starts with the identification of the resource.? For the following examples, let’s define some resources:
map.resources users do |user|
? user.resources groups, :controller => ‘groups’ do |group|
??? group.resources tags, :controller => ‘tags’
? end
endmap.resources groups do |group|
? group.resources users, :controller => ‘users’ do |user|
??? user.resources tags, :controller => ‘tags’
? end
endmap.resources vehicles do |vehicle|
? vehicle.resources wheels, :controller => ‘wheels’
endmap.resources unicycles do |unicycle|
? vehicle.resource wheel, :controller => ‘wheels’
end
As these resource definitions show, sometimes resource identification is trivial and sometimes it’s not…
- /vehicles/567/wheels
- /unicycle/234/wheel
- /users/17/groups/2/tags
- /groups/2/users/17/tags
In example #1, wheels is a has_many association of a vehicle instance.? It would be nice if Rails helped us find the vehicle instance and pointed us towards its has_many association.? What we get is the params hash, which indicates the vehicle instance, and the invocation of WheelsController.index, which implies the wheels collection association.? Indirect, but adequate.
In example #2, wheel is a has_one association of a unicycle instance.? Rails should help us find the vehicle instance and point us towards the association.? Much as in the first example, Rails gives us a params hash and invokes the WheelsController.show method.? Again, indirect but adequate.?
Examples one and two together illustrate the first ugly problem with resource identification:
Problem One: The arity of resources is implied by the invoked controller method instead of being explicit.
In example #3, tags is a has_many association of a Group instance.? In example #4, tags is a has_many association of a User instance.? The params hash and invoked method? are identical for these two requests.? Rails really lets us down here: short of parsing the request path, there is nothing to distinguish these two requests.
Problem Two: The hierarchy of the request’s resource chain is not preserved.
I believe these two problems stem from the outdated perception of the URL only as a means of triggering a specific controller action and providing some unordered key-value parameters.? In the RESTful world, however, the URL has become a resource specifier.? And that means hierarchy matters and parameters are not limited to key-value pairs.? In a nutshell, Rails needs to help us match a concrete request with our abstract resource model.? Until it does, identification of RESTful resources will continue to be a pain in the ass.
In the meantime, I have taken two steps to help the programmer match an abstract resource to the concrete request by providing some extra information to the controller.? First, I have made the matched route available to the controller as an attribute of the request by monkey patching ActionController::Routing::RouteSet and ActionController::AbstractRequest.? Now I can see the specific components of the request in an abstract way instead of as a string.
But once I had made that change, I realized I was getting very close to the holy grail of the actual abstract resource definition (from routes.rb) used to generate the route.? It was only a couple of more monkey patches before I had the source ActionController::Resources::Resource instance available to the controller as well.
Now in my controllers I can see which of my abstract resources (as defined in routes.rb) matches the incoming request.? That goes a long way towards getting the matching AR model instances instantiated.?
My only remaining beef is that the abstract route definitions (in routes.rb) do not store any meaningful hierarchy information.? In my example above, the subordinate collection resource beneath a group and called ‘users’ is only aware of its parent resource (a group) though a couple of strings (name_prefix and one other).? That means that even when I know the abstract resource that matches the incoming request, I can’t really see its enclosing resources with inferring them from string pattern matching.? Rails should store the parent resource for any nested resources.
Resources
??? Jamis Buck’s awesome tutorial on Rails Routing
??? Discussion of some of these issues from a different angle
The support that Rails has provided for developing RESTful applications is nothing short of amazing considering it was added on long after Rails had an established URL-mapping mechanism (Routes.draw).? But I want more.? Specifically, I want my resources to have a more complete life.
Warning: I am not an expert in Rails or REST.
Background: in the current (late summer 2007) Edge Rails, RESTful resources (ActionController::Resources) are defined primarily for the purpose of creating named routes with a DSL (map.resource …).? A very important by-product of generating named routes is the helper methods available to generate routes in views and controllers.? The net result is a tidy means of generating and recognizing RESTful URIs.? A typical exploitation of these features looks like this:
Repeat steps 2 through 4 as required.
In step one, the Rails programmer does the hard work: modeling the resources, the interface to those resources, the mapping of resources to controllers, etc.? Rails honors our work and uses it to recognize routes (in step two) and to help up generate routes (in step four).? But what about step three?? Can we exploit our resource model here?? Let’s recast the typical methods in a controller that backs a resource:
def index
? identify resource
? manipulate resource
enddef destroy
? identify resource
? manipulate resource
enddef create
? identify resource
? manipulate resource
end
For the index action, the identified resource is a collection represented by a Class or an association.? For the destroy (and show and edit) actions, the identified resource is a member represented by an ActiveRecord model instance.? For the create (and new) actions, the resource is a new, unsaved, AR model instance.? Every controller action that handles a REST request starts with the identification of the resource.? For the following examples, let’s define some resources:
map.resources users do |user|
? user.resources groups, :controller => ‘groups’ do |group|
??? group.resources tags, :controller => ‘tags’
? end
endmap.resources groups do |group|
? group.resources users, :controller => ‘users’ do |user|
??? user.resources tags, :controller => ‘tags’
? end
endmap.resources vehicles do |vehicle|
? vehicle.resources wheels, :controller => ‘wheels’
endmap.resources unicycles do |unicycle|
? vehicle.resource wheel, :controller => ‘wheels’
end
As these resource definitions show, sometimes resource identification is trivial and sometimes it’s not…
- /vehicles/567/wheels
- /unicycle/234/wheel
- /users/17/groups/2/tags
- /groups/2/users/17/tags
In example #1, wheels is a has_many association of a vehicle instance.? It would be nice if Rails helped us find the vehicle instance and pointed us towards its has_many association.? What we get is the params hash, which indicates the vehicle instance, and the invocation of WheelsController.index, which implies the wheels collection association.? Indirect, but adequate.
In example #2, wheel is a has_one association of a unicycle instance.? Rails should help us find the vehicle instance and point us towards the association.? Much as in the first example, Rails gives us a params hash and invokes the WheelsController.show method.? Again, indirect but adequate.?
Examples one and two together illustrate the first ugly problem with resource identification:
Problem One: The arity of resources is implied by the invoked controller method instead of being explicit.
In example #3, tags is a has_many association of a Group instance.? In example #4, tags is a has_many association of a User instance.? The params hash and invoked method? are identical for these two requests.? Rails really lets us down here: short of parsing the request path, there is nothing to distinguish these two requests.
Problem Two: The hierarchy of the request’s resource chain is not preserved.
I believe these two problems stem from a common failing in Rails: the outdated perception of the URL as a means of triggering a specific controller action and providing some unordered key-value parameters.? In the RESTful world, however, the URL has become a resource specifier.? And that means hierarchy counts and parameters are not limited to key-value pairs.? Until Rails embraces those realities, identification of RESTful resources will continue to be a pain in the ass.
I
Resources
??? Jamis Buck’s awesome tutorial on Rails Routing
??? Discussion of some of these issues from a different angle
The support that Rails has provided for developing RESTful applications is nothing short of amazing considering it was added on long after Rails had an established URL-mapping mechanism (Routes.draw).? But I want more.? Specifically, I want my resources to have a more complete life.
Warning: I am not an expert in Rails or REST.
Background: in the current (late summer 2007) Edge Rails, RESTful resources (ActionController::Resources) are defined primarily for the purpose of creating named routes with a DSL (map.resource …).? A very important by-product of generating named routes is the helper methods available to generate routes in views and controllers.? The net result is a tidy means of generating and recognizing RESTful URIs.? A typical exploitation of these features looks like this:
Repeat steps 2 through 4 as required.
In step one, the Rails programmer does the hard work: modeling the resources, the interface to those resources, the mapping of resources to controllers, etc.? Rails honors our work and uses it to recognize routes (in step two) and to help up generate routes (in step four).? But what about step three?? Can we exploit our resource model here?? Let’s recast the typical methods in a controller that backs a resource:
def index
? identify resource
? manipulate resource
enddef destroy
? identify resource
? manipulate resource
enddef create
? identify resource
? manipulate resource
end
For the index action, the identified resource is a collection represented by a Class or an association.? For the destroy (and show and edit) actions, the identified resource is a member represented by an ActiveRecord model instance.? For the create (and new) actions, the resource is a new, unsaved, AR model instance.? Every controller action that handles a REST request starts with the identification of the resource.? For the following examples, let’s define some resources:
map.resource account do |account|
? account.resource vehicle, :controller => ‘vehicles’
endmap.resources users do |user|
? user.resources groups, :controller => ‘groups’ do |group|
??? group.resources tags, :controller => ‘tags’
? end
endmap.resources groups do |group|
? group.resources users, :controller => ‘users’ do |user|
??? user.resources tags, :controller => ‘tags’
? end
endmap.resources vehicles do |vehicle|
? vehicle.resources wheels, :controller => ‘wheels’
endmap.resources unicycles do |unicycle|
? vehicle.resource wheel, :controller => ‘wheels’
end
As these resource definitions show, sometimes resource identification is trivial and sometimes it’s not…
- /vehicles/567/wheels
- /unicycle/234/wheel
- /users/17/groups/2/tags
- /groups/2/users/17/tags
In example #1, wheels is a has_many association of a vehicle instance.? It would be nice if Rails helped us find the vehicle instance and pointed us towards its has_many association.? What we get is the params hash, which indicates the vehicle instance, and the invocation of WheelsController.index, which implies the wheels collection association.? Indirect, but adequate.
In example #2, wheel is a has_one association of a unicycle instance.? Rails should help us find the vehicle instance and point us towards the association.? Much as in the first example, Rails gives us a params hash and invokes the WheelsController.show method.? Again, indirect but adequate.?
Examples one and two together illustrate the first ugly problem with resource identification:
Problem One: The arity of child resources is implied by the invoked controller method instead of being explicit.
In example #3, tags is a has_many association of a Group instance.? In example #4, tags is a has_many association of a User instance.? The params hash and invoked method? are identical for these two requests.? Rails really lets us down here: short of parsing the request path, there is nothing to distinguish these two requests.
Problem Two: The hierarchy of the request’s resource chain is not preserved.
a relationship between a parent resource (vehicle or unicycle instance
in this example) and a child resource (wheels or wheel) is not
available.? relationship of resources is .? To do so will require a
more explicit representation of the parent resource (unicycle instance
or vehicle instance) and the child resource (wheel or wheels).
Does Rails exploit our resource modelling effort to help us identify the request’s resource?? No!? Are going to take that insult lying down?? No!? We’re going to carp and bitch!? Okay, I got a bit ahead of myself…but I maintain that Rails does a poor job of helping the programmer identify the resources in
Resources
??? Jamis Buck’s awesome tutorial on Rails Routing
The support that Rails has provided for developing RESTful applications is nothing short of amazing considering it was added on long after Rails had an established URL-mapping mechanism (Routes.draw).? But I want more.? Specifically, I want my resources to have a more complete life.
Warning: I am not an expert in Rails or REST.
Background: in the current (late summer 2007) Edge Rails, RESTful resources (ActionController::Resources) are defined primarily for the purpose of creating named routes with a DSL (map.resource …).? A very important by-product of generating named routes are the helper methods available to generate routes in views and controllers.? The net result is a tidy means of generating and recognizing RESTful URIs.? A typical exploitation of these features looks like this:
Repeat steps 2 through 4 as required.
In step one, the Rails programmer does the hard work: modeling the resources, the interface to those resources, the mapping of resources to controllers, etc.? Rails honors our work and uses it to recognize routes (in step two) and to help up generate routes (in step four).? But what about step three?? Can we exploit our resource model here?? Let’s recast the typical methods in a controller that backs a resource:
def index
? identify resource
? manipulate resource
enddef destroy
? identify resource
? manipulate resource
enddef create
? identify resource
? manipulate resource
end
For the index action, the identified resource is a collection represented by a Class or an association.? For the destroy (and show and edit) actions, the identified resource is a member represented by an ActiveRecord model instance.? For the create (and new) actions, the resource is an unsaved AR model instance.? Every controller action that handles a REST request must start with the identification of the resource.? Sometimes the resource identification is trivial…
/vehicles/234
sometimes it’s not…
/vehicles/567/wheels
/vehicles/234/wheel
/account/vehicle
Does Rails exploit our resource modelling effort to help us identify the request’s resource?
Resources
??? Jamis Buck’s awesome tutorial on Rails Routing
I have been converting a small Rails application to REST this past week and several issues have come to light surrounding HTML forms.? I can’t seem to find a good solution to these problems.? In my last entry, I tackled the issue of delivering of arbitrary forms to HTML clients.? This entry focuses on the annoyances with using GET and Forms.
Unless you have been living in a cave for the past couple of years (Osama?), you have heard of REST.? It encourages exploitation of the full spectrum of inherent capabilities of the HTTP protocol to provide resource-centric services over the web.? Part of this exploitation centers on the HTTP verbs PUT, DELETE et. al. that are under-used.? Another focus is on the use of GET in non-traditional contexts like HTML forms.? The essence of this last recommendation is that GET should be used whenever there are no side-effects from the request.? And querying usually falls into this category, so we should be using HTTP GET to submit HTML forms that are used to build queries.? Sounds good, and it is trivial in Rails to implement.
I have been converting a small Rails application to REST this past week and several issues have come to light surrounding HTML forms.? I can’t seem to find a good solution to these problems.? First, I want to tackle delivering of arbitrary forms to HTML clients.
In a simple application revolving around one resource, delivering a form to an HTML client (to query against that resource, for example) is a “classic” task.? With REST, the single resource has straightforward URIs for all the classic CRUD operations.? But the forms that facilitate the CRUD operations are much less clear.? For example, if I wish to fetch the clown with ID 1, I can issue an HTTP request like this:
??? http://example.domain/clowns/1?? (HTTP verb GET)
And to update the clown:
??? http://example.domain/clowns/1?? (HTTP verb PUT, with form-encoded attributes)
But how do I deliver the editing form to the client?? The first URL in the example only delivers the clown resource itself, not the form to edit the clown.? One approach is to treat the form itself as a resource (see reference 2) and allow it to be RESTfully manipulated:
??? http://example.domain/clownEditForm?? (HTTP verb GET)
As clean as this looks from the URL perspective, it is ugly in Rails.? The resource route mapping available in the recent Simply RESTful Edge Rails enhancements does not permit a second named resource using the same HTTP verb (GET) to use the same controller -so the ClownController couldn’t serve up this form and you would need an additional controller -yech.? Another approach is to use a representational tweak via a view parameter:
??? http://example.domain/clowns/1?view=edit ? (HTTP verb GET)
In a similar vein, Rails supports view tweaks to the URL with an abbreviated syntax.? So to fetch clown ID 1 represented for editing, I would use a URL like this:
??? http://example.domain/clowns/1;edit ? (HTTP verb GET)
OK, I can grasp what is going on here.? But extending this model is not so easy.? For example, what URL would I use for delivering an HTML form to find the closest clowns to a given address?? The problem is that I am not delivering a special representation of a clown.? In fact, there is no clown at all in this form -just an address field.? And I’ll be damned if I am going to create a one-shot address resource (and controller) for this purpose.? So where does this leave me?? I’ve opted for representational tweaks to the collection resource:
??? http://example.domain/clowns;queryByAddressForm ? (HTTP verb GET)
And the corresponding routes.rb declaration:
??? map.resources :clowns, :collection => {:queryByAddressForm => :get}
Not very satisfactory, but workable.?
A twist: what if I want to use this same HTML page for displaying the results of the query (without AJAX) and the query form itself?? Now the concept of getting the form and getting the query results have blended into one.? This construct is useful in HTML even if it is absurd for a web service or JSON/XML delivery.? What to do?? I went to this intentionally vague representation:
??? http://example.domain/clowns;queryByAddress ? (HTTP verb GET)
This HTTP request will return a page with the empty form at the top and the results (initially empty) at the bottom.? The form submits with a GET to the same URL -but this time with a address parameter that causes results (and previous form values) to be included in the returned page:
??? http://example.domain/clowns;queryByAddress?address=3100+Edgewater+27514 ? (HTTP verb GET)
In a more general sense, this may be an acceptable paradigm: a GET to a query URL requesting HTML but without the necessary parameters is interpreted as a request for the form.? Can I get an “Amen, Brother!” on that?? Can I get some built-in Rails support?
At this point I am willing to settle.? But I’m still not happy.? Part of my problem may be that Rails has not yet made it truly easy to do REST 100% right.? A more strictly RESTful approach could be implemented, but for now Edge Rails is using the KISS approach.