Camping 2.1: Tests
Wanted to highlight some of the issues we know have on github and get some discussion going. First up: Tests - http://github.com/camping/camping/issues#issue/15 Currently Camping doesn't have any automated tests. At all. Now, I'm not a testing freak, but I'm not _why either, so I believe we'll have to have *some* tests. I'm not talking about 100% unit-test coverage, but just something which lets us commit with confidence and makes it easier to make sure everything works on both 1.8 and 1.9. One idea I had: Use what we have in test/apps/ now and write WebRat-steps to make sure everything works as expected. The apps should be ran through Camping::Server, and the tests should use Net::HTTP so we test the whole stack. Anyone wants to give it a try, or have any other ideas? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Rackification
Rackification - http://github.com/camping/camping/issues#issue/3 I want to make Camping even more Rack-ish. Some ideas: 1. Make Camping::Server use Rack::Server 2. The dispatcher shouldn't care about the method Previously the dispatcher (Controllers.D) has taken a path and a method, and returns an array with the controller and the method: D(/, get) # = [Index, 'get'] D(/, post) # = [I, 'r501'] # no post-method in Index D(/not_found, get) # = [I, 'r404'] I want to make it such that the dispatcher only cares about the path, and then the controllers are responsible for calling the right method. I feel that is more HTTP-ish: First look up the resource, then try to call the method. 3. When the method isn't found, call #method_missing Okay, this one is kinda dangerous, but it would be cool if Camping would call #method_missing if the method doesn't exist. That way, Camping almost becomes the Ruby-version of HTTP. Too dangerous (aka. it would swallow regular NoMethorError) or possible? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Easier to extend
http://github.com/camping/camping/issues#issue/10 It's currently very hard to extend Camping, so I've been thinking of ways to make it easier without taking too many bytes. Here's a very simple approach: https://gist.github.com/75ecb81a3ae98b097f8a When you write `Camping.plugin :Foo` it stores the code in the file, and when you later call `App.needs :Foo` it fetches the file again and replaces Camping with App. Not perfect, but at least it's something. I'll have to try to get RESTstop using this technique to see how it works... Any other ideas? Comments? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Making migrations less sucky
http://github.com/camping/camping/issues#issue/12 This is probably the most exciting issue: Making migrations less sucky. The fact that you'll have to do this to get started sucks: module Nuts::Models class Page Base end class BasicFields V 1.0 def self.up create_table Page.table_name do |t| t.string :title t.text :content # This gives us created_at and updated_at t.timestamps end end def self.down drop_table Page.table_name end end end It should really just be something like this: module Nuts::Models class Page Base t.string :title t.text :content t.timestamps end end But we still want to support regular migrations (in some way at least). See the issue for more examples/comments. // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 2.1: Rackification
#1 seems to make sense. I personally tend to use rackup anyway. #2 seems ok. #3 agreed with the dangerous override - how about http_method_missing instead? On 4/12/2010 8:32 AM, Magnus Holm wrote: Rackification - http://github.com/camping/camping/issues#issue/3 I want to make Camping even more Rack-ish. Some ideas: 1. Make Camping::Server use Rack::Server 2. The dispatcher shouldn't care about the method Previously the dispatcher (Controllers.D) has taken a path and a method, and returns an array with the controller and the method: D(/, get) # = [Index, 'get'] D(/, post) # = [I, 'r501'] # no post-method in Index D(/not_found, get) # = [I, 'r404'] I want to make it such that the dispatcher only cares about the path, and then the controllers are responsible for calling the right method. I feel that is more HTTP-ish: First look up the resource, then try to call the method. 3. When the method isn't found, call #method_missing Okay, this one is kinda dangerous, but it would be cool if Camping would call #method_missing if the method doesn't exist. That way, Camping almost becomes the Ruby-version of HTTP. Too dangerous (aka. it would swallow regular NoMethorError) or possible? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 2.1: Tilt integration
Tilt seems pretty cool based on quick glance at the site. This would give people a few more well-known options. On 4/12/2010 8:37 AM, Magnus Holm wrote: Tilt - http://github.com/camping/camping/issues#issue/18 Tilt integration (http://github.com/rtomayko/tilt) is a dead-simple way to support ERB, Erubis, Haml, Liquid, Builder and other template engines. It would be nice if require 'camping/templates' would re-define Base#render to use Tilt IMO. // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
