I’ve been (mis)using similar behaviour in javascript for years.

I suppose that the reason it works is exactly the same reason it works in Ruby ... but in this case I think the code is actually very easy to read.

As for whether these benchmarks are misleading… I don’t think they are. For the case I set here (a very simple one, to be sure), I think the performance numbers hold. I don’t think at all that this is the end of the discussion, however; clearly, many scenarios remain to be tested (adding caching, doing more complicated things in the reused markup, block-accepting helpers vs. partials, etc.), but this is just a place to start.

Thanks for the comment!

Excellent post; performance is an excellent issue to highlight between partials and helpers… there’s just a lot more code at work. 

In general, I recommend that people move as much code as possible into helpers vs partials for other reasons; it’s easier to document, reuse, and extend Ruby code, and in the case of small partials there’s very little pain involved.

Of course this falls flat on its face when you need to work in HTML to support designers on staff that struggle with anything outside a template… which is why I try to work with designers who don’t have that problem ;-)

PS. For more info about Moose see moose.perl.org.

thanks much for this writeup, I tried installing sphinx and ran into some compile errors as well… Not sure they were these exact ones, but from what I remember this looks familiar.
Also, once you ran into your initial compile errors, did you just simply wipe out your /usr/local/sphinx directory and then re-compile (following the steps mentioned)?

cheers

There will be a blog post in the coming days that will have more information.

Thanks.

btw, do you use the default captcha on your site or is it a plugin?

I can’t thank you enough for this blog post ... The amount of time you have saved me is immeasurable!  Also, for the sake of sharing my experience with linode as opposed to SliceHost, one has to apt-get wget before the script works at the point where it goes out to get rubygems ... It was an easy fix, but I thought I would mention it.  For the sake of clarity, I was installing to a Ubuntu 8.04 Hardy AMD64 on my linode.com account - which apparently doesn’t come w/ wget installed when you drop their image onto your host.  Thanks again for this contribution ...

grantmichaels

I tried the code above in Rails 2.1.0, but I’m getting the following error: ./test/unit/application_helper_test.rb:1: uninitialized constant ActionView (NameError)

Here’s the code I’m using:
/app/helpers/application.rb
module ApplicationHelper
def title(page_title)
content_for(:title) { page_title }
end
end

/test/unit/application_helper_test.rb
class ApplicationHelperTest < ActionView::TestCase
assert true
end

Any ideas on why this isn’t working for me?

git reset --hard remotes/trunk

If you don’t do this, your dcommits will go to whereever the master branch is pointing.  For me it was a tag in the tags directory.

On equestion - do you know how to get mysql to install via capistrano?  It always uses curses when I try and so I can’t /completely/ automate our slicebuild.  I have to manually install mysql at present.

-Josh

Thanks for this post… really valuable and a great way to minimize slice setup using Capistrano.

Its not particularly pretty but if you don’t want action controller its the only option.

I am an Rspec user and when doing view helper plugins I use the rspec_on_rails have_tag matcher by just including the file from rspec in the plugin spec directory. To see what I mean look here http://github.com/adzap/date_time_text_field_helpers/tree/master/spec

Adam

One slight problem though.  I set the blog up fine but when I tell it to Fetch Posts it returns the list of headers as expected but when I select one only the header information is shown and not the article text.  Any idea why this is happening?

Thanks Patrick.

Oh, and which version are you using - the one from SVN (mentioned in this post) or from GitHub?

== 21 CreatePages: migrating ==================================================
-- create_table(:pages)
-> 0.0620s
-- add_index(:pages, :path, {:unique=>true})
-> 0.1560s
-- add_index(:pages, :parent_id)
-> 0.1410s
-- add_index(:pages, :editor_id)
-> 0.1560s
-- add_index(:pages, :status)
-> 0.2500s
rake aborted!
Expected D:/Work/Prototypes/TubeCaption/trunk/vendor/plugins/sandstone/lib/sands
tone/models/page.rb to define Sandstone::Models::Page
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependenci
es.rb:249:in `load_missing_constant’
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependenci
es.rb:453:in `const_missing’

Any idea?

You may find this video presentation “Your Doing OO Wrong” at recent YAPC::Asia of interest....  http://conferences.yapcasia.org/ya2008/talk/1134

NB.  Don’t be put off because its Perl.  Uses Moose which makes it very easy to understand.

>You should be shooting for one or two methods.

Currently I’m writing my own openid-wrapper module (going to publish it at gitorious soon :-) and I got confused from your blogpost right now: do you mean I should keep module public methods low (say max 1-2)? Or you were talking about methods which serve the initialize part?

module Wizard
def initialize
puts “wiz”
super
end
end

module Pong
def initialize
puts “ping”
super
end
end

class Scarf
include Wizard

def initialize
super
end
end


irb(main):022:0> s = Scarf.new
wiz
=> #<Scarf:0x335108>
irb(main):025:0> # Wait, all Scarves should Pong, too:
irb(main):026:0* Scarf.send( :include, Pong )
=> Scarf
irb(main):027:0> s2 = Scarf.new
ping
wiz
=> #<Scarf:0x32ebf0>

As to your assertion that “it isn’t immediately clear what is going to happen” when you call ‘super’ from #initialize: you’re making the case against yourself. Any specifics you add to the including class that would express what the including module is doing is coupling that class to the module. The class shouldn’t have to know what initialization is needed (if any) by the modules it includes, as that knowledge more properly inheres in the module itself.

TMTOWTDI even in Ruby, I guess. :)

module Wizard
def initialize
puts “wiz”
end
end

module Pong
def initialize
puts “ping”
end
end

class Scarf
include Wizard
include Pong

def initialize
super
end
end

>> s = Scarf.new
ping
=> #<Scarf:0x35889c>

The reason Wizard’s initialize never fired is due to the way Ruby handles inserting modules into a class’ inheritance tree when include is called.  In fact, if you try

>> Scarf.ancestors
=> [Scarf, Pong, Wizard, Object, Kernel]

You can see that Scarf’s super is the most recently added module.  You could also call super in Pong but that introduces a brittle coupling between Pong and Wizard.  Which brings me to the second reason I like using a modules API to handle initialization: it is explicit.  When I see a class with 5 includes and it just calls super it isn’t immediately clear what is going to happen.  In some cases I might not need initialization behavior from every module.  Using a well named module API I can see exactly what is happening when my class is instantiated.

because most of time, I came across this matter as a problem. most of time i mixed them. and now, I have lots of classes that inherits some base casses, and as u can guess, I lost my control on that. I have to decide on a solution. I have to see my ways about this matter. where should I go.

I understand “is a” and “has a” subjects. but, still, I confused.

I think I must use composition rather than inheritance. cus, as you said above “using inheritance makes a highly-coupled relations” and this stuaition is not for me as a not enought settled-knowlage person.

regards.

module Glar
def initialize
puts “I am glarring”
end
end

class Hloom
include Glar
end

class Bglon
include Glar
def initialize
puts “I am a Bglon”
super
end
end

puts “Creating a Hloom”
Hloom.new
puts “Creating a Bglon”
Bglon.new

### Output:
# Creating a Hloom
# I am glarring
# Creating a Bglon
# I am a Bglon
# I am glarring

But just ‘cause you asked I’ll put up a hpricot based `assert_tag_in` later today.

It’s certainly an idea worthy of further exploration.

There are some rules about migrations we DO know, right? For example, the last migrations take priority --- we know that’s where we want to end up!

Ultimately, I think schema.rb rolls up well though, and a rake task to push that into place of the last migration, and nuke the rest, might be the solution.

This is a nice solution. These problems definitely keep me up at night. What happens when you have 40-50 migrations to consolidate? Seems unwieldy and lengthy to join them together by hand. Have you written any tasks to help you do this? That’s really what I’d love to see:  rake db:migrate:consolidate

Kevin

Do you have any larger goals for spect, or does this scratch the itch nearly completely?

Also, do you see yourself using test/unit, test/spec, and spect all together?