erratic

<%= link_to_function( "insert it", :id => 'foo') do |page| 
      partial = escape_javascript(render :partial => "my_partial", :object => Object.new)
      page <<  "$('#my_div').append('#{partial}')"
    end %>

Sweetness.

all lies – less pain to just use current_user and accept the inaccurate naming of the models intent in the instance variable.

fuckin’ fuck, man.

I use restful_acl gem and the restful_auth plugin – restful_auth has generators so that when you create the restful authorization model it will take your class name and fill in the places where it needs to go I have an account model instead of a user model so it filled in all of the instance variables for authenticated user methods with current_account. The restful_acl gem is hardcoded to the current_user instance variable. So I opened the module and method in a file in /lib called restful_acl_controller_hacks.rb so I could alias current_account to current_user.

module RestfulAclController
  module ClassMethods
    def has_permission?
      alias current_user current_account
    end
  end
end

  require 'restful_acl_controller_hacks'

Now has_permission? works and my specs pass and all is right with the world. For about 2 minutes until I smash into another coding wall due to my lack of experience and inability to remember most things of importance related to OOP.

In a feature file you CANNOT comment out text on the end of a line - it will say your shit isn't implemented.

'test.local' is the URL rspec uses when running specs for controllers - so 'test.local' is the URL webrat/cucumber uses. Making possible testing of subdomain handling.

Single quotes are treated differently than double quotes - have no fucking idea why

Sometimes running features works - sometimes not. Putting the following in features/support/env.rb helped when some steps would pass when others wouldn't:

#Seed the DB
Fixtures.reset_cache  
fixtures_folder = File.join(RAILS_ROOT, 'spec', 'fixtures')
fixtures = Dir[File.join(fixtures_folder, '*.yml')].map {|f| File.basename(f, '.yml') }
Fixtures.create_fixtures(fixtures_folder, fixtures)

replace in config/environment.rb:

config.gem 'will_paginate', :version => '>= 2.2.2'

config.gem 'mislav-will_paginate', :version => '>= 2.3.2', :lib => 'will_paginate', :source => 'http://gems.github.com'

comment out in config/environment.rb:

config.gem 'tzinfo', :version => '>= 0.3.12'

I had to add:

require 'liquid'
require 'will_paginate'

change line 17 in the index action in app/controllers/admin/articles_controller.rb to this:

    @articles = Article.paginate :page => params[:page], :per_page => params[:per_page], :conditions => ['site_id = ?', site.id], :order => 'contents.published_at DESC', :select => 'contents.*'

remove tzinfo from vendor/gems/

commented out erb tags on line 32 and 37 of app/views/admin/settings/index.html.erb.

32     <dd><%#= time_zone_select 'site', 'timezone_name', TZInfo::Timezone.all.sort, :model => TZInfo::Timezone %></dd>
33     <dt>
34       <label for="site_lang">Site language</label>
35       <span class="hint">Used to specify language in your site feeds</span>
36     </dt>
37     <dd><%#= f.text_field :lang %></dd>

Error handling in rails is very technical. The TextMate Backtracer Plugin has been invaluable to me in my development in recent days, yet it only gets me to the file(s) when something is amiss in the code.

Building and running tests is one way of confirming the functionality of your application, and I’m learning the power of good testing, be it quite slowly and with a lot of errors.I’ll get there.

Here is a short list of things I had to consider when flopping from code to browser during development and things kept blowing up in my face:

• Ruby/Rails has RESERVED WORDS. If you have a class/table that isn’t playing nice make sure you aren’t naming it with one of these. This is tantamount to pouring sugar in your gas tank. And then driving in reverse at full speed. While wearing a blindfold. With your hair on fire.

• Column names in your tables need to change with alterations to any class/model names, as well as any has_many/belongs_to associations along with any model inclusions in your controllers. If you’re not to invested in the code it’d probably be easier to regenerate a fresh app with the correct model/controller name. Running ./script/destroy (the arch nemesis of ./script/generate) can help in crime scene clean up, but you still have all those pesky symbols/variables/methods with the poison name throughout your app patiently waiting to spurt their demonic ire. Exterminate them with aggression.

• An objects information will carry from request to request in the session but you still have to stuff it into an instance variable inside whatever controller method is being called upon. I have a tingling sensation in my unmentionables that suggests session customization and databases can smooth out this bumpy road, but this strains the withering tethers of my sanity upon contemplation. I can only learn so much each day.

• Getting compile errors means you’re trying to bake a duck with a hammer on a string in a pail of kittens. It won’t work. Ruby/Rails doesn’t know or particularly care what you are trying to do, but how you are going about doing whatever it is you are trying to do will never, ever work no matter what. Get rid of whatever you added since the last time it worked and try again. Remember when you went to grandmas house and you had to take off your shoes and you weren’t supposed to go out into the field because you’d get muddy? Yeah, Rails has grandma rules that sometimes take all the fun out of life and make your feet cold.

Throwing away code is a part of development, just as throwing away designs is a part of being a designer. Having the willingness to let go of what’s not working makes room for what will. Even if what that is is nowhere to be seen at the moment.