jnunemaker / httparty

Click here to lend your support to: httparty and make a donation at www.pledgie.com !

Makes http fun! Also, makes consuming restful web services dead easy. — Read more

Sort by: Priority | Votes | Last Updated

Loading…

26.

1 vote

why use include HTTParty instead of extend?
4 comments Created 14 days ago by timcharper

Title

Body
As far as I can tell, the module HTTParty has no instance methods. You include it, and it turns around and calls extend on a different module. And then it sets class-level instance variables, class-level inheritable attributes, and so forth. Is it just a personal preference? What if we would prefer the module to operate on an instance level instead? IE: instantianting an agent class that configures the httparty attributes. Tim
or cancel
As far as I can tell, the module HTTParty has no instance methods. You include it, and it turns around and calls extend on a different module. And then it sets class-level instance variables, class-level inheritable attributes, and so forth.

Is it just a personal preference? What if we would prefer the module to operate on an instance level instead? IE: instantianting an agent class that configures the httparty attributes.

Tim

Comments
jnunemaker Tue Dec 15 16:23:35 -0800 2009 | link

I believe the reason is that extend doesn't have a hook like include. Include has included but the extended hook doesn't work when you use extend inside a class definition like the current include idiom.

Overall, yes, extend is maybe "more" correct, but it does exactly what is needed and is easy to use which is what I care about most.

Comment
I believe the reason is that extend doesn't have a hook like include. Include has included but the extended hook doesn't work when you use extend inside a class definition like the current include idiom. Overall, yes, extend is maybe "more" correct, but it does exactly what is needed and is easy to use which is what I care about most.
or cancel
timcharper Tue Dec 15 18:05:58 -0800 2009 | link
module A def self.extended(c) puts "I extended #{c}" end end class C extend A end

The above outputs "I extended A". Is there a behavioral difference between extended and included I'm not aware of?

The issue I see with include is it encourages some VERY BAD practices. Such as this, for example:

http://github.com/mcommons/tinder/blob/master/lib/tinder/campfire.rb

Here, Campfire sets takes parameters in it's initializer, then turns around and applies those settings as class variables. This means if you construct two instance of Campfire, you will get surprised that the first instance suddenly uses the configuration of the second.

HTTParty has a slick API - I applaud you on the design. I just believe this one little detail would be smoothed over if we could actually include HTTParty, instead of being forced to extend the class with HTTParty via an included hook. The above Campfire source would thus be able to configure HTTParty on an instance based level, rather than having to resort to setting class variables, and two instances could have separate configurations.

It just may be worth considering :)
Comment
<pre> module A def self.extended(c) puts "I extended #{c}" end end class C extend A end </pre> The above outputs "I extended A". Is there a behavioral difference between extended and included I'm not aware of? The issue I see with include is it encourages some VERY BAD practices. Such as this, for example: http://github.com/mcommons/tinder/blob/master/lib/tinder/campfire.rb Here, Campfire sets takes parameters in it's initializer, then turns around and applies those settings as class variables. This means if you construct two instance of Campfire, you will get surprised that the first instance suddenly uses the configuration of the second. HTTParty has a slick API - I applaud you on the design. I just believe this one little detail would be smoothed over if we could actually include HTTParty, instead of being forced to extend the class with HTTParty via an included hook. The above Campfire source would thus be able to configure HTTParty on an instance based level, rather than having to resort to setting class variables, and two instances could have separate configurations. It just may be worth considering :)
or cancel
timcharper Tue Dec 15 18:09:23 -0800 2009 | link

Clarification: the problem I see is with the way include is being used in this case. :) Used appropriately, I love include.

That is all. Thank you for responding :)

Comment
Clarification: the problem I see is with the way include is being used in this case. :) Used appropriately, I love include. That is all. Thank you for responding :)
or cancel
timcharper Wed Dec 16 10:32:45 -0800 2009 | link
I've got an idea: what if HTTParty really did include instance methods?

require 'rubygems' require 'httparty' class Twitter include HTTParty base_uri 'twitter.com' def initialize(user, pass) basic_auth user, pass end def post_message(text) post('/statuses/update.json', :query => {:status => text}) end end puts Twitter.new('username', 'password').post_message("It's an HTTParty and everyone is invited!").inspect

This way, instance settings could individually override class settings. It would certainly make HTTParty work my use case, but wouldn't want to suggest something that would get in the way of what you want out of the gem.
Comment
I've got an idea: what if HTTParty really did include instance methods? <pre> require 'rubygems' require 'httparty' class Twitter include HTTParty base_uri 'twitter.com' def initialize(user, pass) basic_auth user, pass end def post_message(text) post('/statuses/update.json', :query => {:status => text}) end end puts Twitter.new('username', 'password').post_message("It's an HTTParty and everyone is invited!").inspect </pre> This way, instance settings could individually override class settings. It would certainly make HTTParty work my use case, but wouldn't want to suggest something that would get in the way of what you want out of the gem.
or cancel
Parsed with GitHub Flavored Markdown
22.

0 votes

httparty 0.4.4 and 0.4.5 differences
1 comment Created 3 months ago by whoisjake

Title

Body
I wrote a small Twitter httparty client that used it's search features. In development on my machine, 0.4.4 and 0.4.5 worked the same... When I deployed the application to Heroku, 0.4.4 works but 0.4.5 causes Twitter to return a 400 Bad Request. I feel like a bad bug reporter since I don't have any sample code, it was basically the same as your twitter example but built for the search. I would imagine it's something to do with how it builds the request. Not sure if anything has changed recently, but for some reason, whatever is machine specific in the request generation is causing errors on Heroku. Steps to reproduce: 1) Used this: http://gist.github.com/178266 2) With 0.4, it returned results in dev mode and on Heroku. 3) With 0.4.5 it returns results in dev, but not on Heroku. Expected: I should get twitter search results. Actual: I get a 400 Bad Request
or cancel

I wrote a small Twitter httparty client that used it's search features.

In development on my machine, 0.4.4 and 0.4.5 worked the same... When I deployed the application to Heroku, 0.4.4 works but 0.4.5 causes Twitter to return a 400 Bad Request.

I feel like a bad bug reporter since I don't have any sample code, it was basically the same as your twitter example but built for the search.

I would imagine it's something to do with how it builds the request. Not sure if anything has changed recently, but for some reason, whatever is machine specific in the request generation is causing errors on Heroku.

Steps to reproduce:
1) Used this: http://gist.github.com/178266
2) With 0.4, it returned results in dev mode and on Heroku.
3) With 0.4.5 it returns results in dev, but not on Heroku.

Expected:
I should get twitter search results.

Actual:
I get a 400 Bad Request

Comments

jnunemaker Tue Sep 22 07:53:44 -0700 2009 | link

Twitter search started recently requiring the user agent to be set. My guess is it is related to that. Please check the twitter mailing list, and the httparty google group before submitting tickets.

Comment
Twitter search started recently requiring the user agent to be set. My guess is it is related to that. Please check the twitter mailing list, and the httparty google group before submitting tickets.
or cancel

Parsed with GitHub Flavored Markdown
21.

0 votes

Tumblr works with 4.3 but not 4.5
3 comments Created 3 months ago by voodoo

Title

Body
0.4.3 Tumblr::User.new('VALID_EMAIL', 'VALID_PWD') => #<Tumblr::User:0x7fedb8b43dd8 @tumblr=LOTS_OF_TUMBLR_VARS 0.4.5 Tumblr::User.new('VALID_EMAIL', 'VALID_PWD') => #<Tumblr::User:0x36b40ec ....@tumblr="tumblr" Note @tumblr just equals the string 'tumblr' in 4.5 Anyone have a pointer for why that might be?
or cancel

0.4.3
Tumblr::User.new('VALID_EMAIL', 'VALID_PWD') => #<Tumblr::User:0x7fedb8b43dd8 @tumblr=LOTS_OF_TUMBLR_VARS

0.4.5
Tumblr::User.new('VALID_EMAIL', 'VALID_PWD') => #<Tumblr::User:0x36b40ec ....@tumblr="tumblr"

Note @tumblr just equals the string 'tumblr' in 4.5

Anyone have a pointer for why that might be?

Comments

voodoo Mon Sep 21 11:31:32 -0700 2009 | link

This tumlr gem, that is :)
http://github.com/jeffkreeftmeijer/tumblr

Comment
This tumlr gem, that is :) http://github.com/jeffkreeftmeijer/tumblr
or cancel

jnunemaker Mon Sep 21 21:19:59 -0700 2009 | link

This is not an httparty responsibility. File a ticket with the tumblr gem.

Comment
This is not an httparty responsibility. File a ticket with the tumblr gem.
or cancel

voodoo Tue Sep 22 07:37:54 -0700 2009 | link

This is true, sorry about that.

Comment
This is true, sorry about that.
or cancel

Parsed with GitHub Flavored Markdown
20.

0 votes

superclass mismatch for class BlankSlate
3 comments Created 3 months ago by plainprogrammer

Title

Body
Encountering an odd error under Snow Leopard regarding a superclass mismatch when trying to run `rake db:migrate`: ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment rake aborted! superclass mismatch for class BlankSlate /opt/local/lib/ruby/gems/1.9.1/gems/httparty-0.4.4/lib/httparty/core_extensions.rb:6:in `<top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `block in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in `new_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/httparty-0.4.4/lib/httparty.rb:203:in `<top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `block in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in `new_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/twitter-0.6.15/lib/twitter.rb:11:in `<top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `block in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in `new_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/rails/gem_dependency.rb:208:in `load' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:307:in `block in load_gems' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:307:in `each' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:307:in `load_gems' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:164:in `process' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:113:in `run' /Users/jamesthompson/Development/RubyBayou-Website/config/environment.rb:9:in `<top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `block in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in `new_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in `require' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/tasks/misc.rake:4:in `block in <top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:636:in `call' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:636:in `block in execute' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:631:in `each' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:631:in `execute' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:597:in `block in invoke_with_call_chain' /opt/local/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:607:in `block in invoke_prerequisites' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:604:in `each' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:604:in `invoke_prerequisites' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:596:in `block in invoke_with_call_chain' /opt/local/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:583:in `invoke' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2029:in `block (2 levels) in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2029:in `each' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2029:in `block in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2001:in `block in run' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake:31:in `<top (required)>' /opt/local/bin/rake:19:in `load' /opt/local/bin/rake:19:in `<main>'
or cancel

Encountering an odd error under Snow Leopard regarding a superclass mismatch when trying to run rake db:migrate:

Invoke db:migrate (first_time) Invoke environment (first_time) ** Execute environment rake aborted! superclass mismatch for class BlankSlate /opt/local/lib/ruby/gems/1.9.1/gems/httparty-0.4.4/lib/httparty/core_extensions.rb:6:in <top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:inrequire' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in block in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:innew_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in require' /opt/local/lib/ruby/gems/1.9.1/gems/httparty-0.4.4/lib/httparty.rb:203:in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:inblock in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in new_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:inrequire' /opt/local/lib/ruby/gems/1.9.1/gems/twitter-0.6.15/lib/twitter.rb:11:in <top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:inrequire' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in block in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:innew_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in require' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/rails/gem_dependency.rb:208:inload' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:307:in block in load_gems' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:307:ineach' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:307:in load_gems' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:164:inprocess' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/initializer.rb:113:in run' /Users/jamesthompson/Development/RubyBayou-Website/config/environment.rb:9:in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:inblock in require' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:521:in new_constants_in' /opt/local/lib/ruby/gems/1.9.1/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:156:inrequire' /opt/local/lib/ruby/gems/1.9.1/gems/rails-2.3.3/lib/tasks/misc.rake:4:in block in <top (required)>' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:636:incall' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:636:in block in execute' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:631:ineach' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:631:in execute' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:597:inblock in invoke_with_call_chain' /opt/local/lib/ruby/1.9.1/monitor.rb:190:in mon_synchronize' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:590:ininvoke_with_call_chain' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:607:in block in invoke_prerequisites' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:604:ineach' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:604:in invoke_prerequisites' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:596:inblock in invoke_with_call_chain' /opt/local/lib/ruby/1.9.1/monitor.rb:190:in mon_synchronize' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:590:ininvoke_with_call_chain' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:583:in invoke' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2051:ininvoke_task' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2029:in block (2 levels) in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2029:ineach' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2029:in block in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2068:instandard_exception_handling' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2023:in top_level' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2001:inblock in run' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2068:in standard_exception_handling' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:1998:inrun' /opt/local/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake:31:in <top (required)>' /opt/local/bin/rake:19:inload' /opt/local/bin/rake:19:in `'

Comments

plainprogrammer Tue Sep 01 14:36:43 -0700 2009 | link

I isolated the issue a little bit. It is connected with the Twitter gem I am using in my Rails app. If I have 0.4.3 (required by Twitter gem) installed and update to 0.4.4 then this error occurs. The problem is not likely in HTTParty itself.

Comment
I isolated the issue a little bit. It is connected with the Twitter gem I am using in my Rails app. If I have 0.4.3 (required by Twitter gem) installed and update to 0.4.4 then this error occurs. The problem is not likely in HTTParty itself.
or cancel

sandro Tue Sep 01 16:23:41 -0700 2009 | link

I had the same problem when using ruby 1.9 with rails, see http://github.com/sandro/httparty/commit/0e9ed2108810c763235129fe167d08860cc73cfc

Comment
I had the same problem when using ruby 1.9 with rails, see http://github.com/sandro/httparty/commit/0e9ed2108810c763235129fe167d08860cc73cfc
or cancel

jnunemaker Tue Sep 08 21:11:28 -0700 2009 | link

Switched from BlankSlate to BasicObject and only defining it if it doesn't exist for ruby 1.9 compat.

Closed by 4eb14a1

Comment
Switched from BlankSlate to BasicObject and only defining it if it doesn't exist for ruby 1.9 compat. Closed by 4eb14a17ba94856053b7e11ae6488b1a331c7e91
or cancel

Parsed with GitHub Flavored Markdown
19.

0 votes

Cookie header overwrites headers set by user
2 comments Created 4 months ago by sandro

Title

Body
class A include HTTParty headers 'referer' => 'http://mysite.com' end When inspect options within HTTParty::Request#perform_actual_request, the headers hash always contained :headers=>{"cookie"=>""}. I've temporarily fixed this by overriding #perform_request and removing the call to #process_cookies class A include HTTParty headers 'referer' => 'http://mysite.com' def self.perform_request(http_method, path, options) #:nodoc: # process_cookies(options) Request.new(http_method, path, default_options.dup.merge(options)).perform end end
or cancel
```
class A
  include HTTParty
  headers 'referer' => 'http://mysite.com'
end
```
When inspect options within HTTParty::Request#perform_actual_request, the headers hash always contained :headers=>{"cookie"=>""}.
I've temporarily fixed this by overriding #perform_request and removing the call to #process_cookies
```
class A
  include HTTParty
  headers 'referer' => 'http://mysite.com'

  def self.perform_request(http_method, path, options) #:nodoc:
    # process_cookies(options)
    Request.new(http_method, path, default_options.dup.merge(options)).perform
  end
end
```
Comments

sporkd Mon Sep 07 09:15:24 -0700 2009 | link

I submitted a fix for this a while back.

http://github.com/sporkd/httparty/commit/c1366ec2c4ca872b03b583b280180222fca11660

Comment
I submitted a fix for this a while back. http://github.com/sporkd/httparty/commit/c1366ec2c4ca872b03b583b280180222fca11660
or cancel

sandro Tue Sep 08 19:07:24 -0700 2009 | link

Fix headers overwritten by #process_cookies

Closed by 385dc65

Comment
Fix headers overwritten by #process_cookies Closed by 385dc65ba36d40d1503d1eba02bb23047d2f6e9e
or cancel

Parsed with GitHub Flavored Markdown
17.

6 votes

Timeout Support
4 comments Created 6 months ago by tadman

Title

Body
There needs to be some kind of option to specify a timeout on calls. Example patch to HTTParty::Request#http: http://e-huned.com/2009/06/11/monkey-patch-httparty-to-use-a-timeout/ http://gist.github.com/130298
or cancel

There needs to be some kind of option to specify a timeout on calls.

Example patch to HTTParty::Request#http:

http://e-huned.com/2009/06/11/monkey-patch-httparty-to-use-a-timeout/ http://gist.github.com/130298

Comments

sandro Thu Aug 06 12:09:23 -0700 2009 | link

Had to apply attack's patch http://github.com/attack/httparty/commit/36047e293c77c06b3cf86eea50b9265943047751 to keep my site up while twitter was down today. Please merge in the patch, it's extremely useful.

Comment
Had to apply attack's patch http://github.com/attack/httparty/commit/36047e293c77c06b3cf86eea50b9265943047751 to keep my site up while twitter was down today. Please merge in the patch, it's extremely useful.
or cancel

hashrocket Thu Aug 06 12:09:50 -0700 2009 | link

We ran into a problem today with the twitter outage. Our solution was to monkeypatch from attack's fork (http://github.com/attack/httparty/commit/36047e293c77c06b3cf86eea50b9265943047751). Worked a charm.

Comment
We ran into a problem today with the twitter outage. Our solution was to monkeypatch from attack's fork (http://github.com/attack/httparty/commit/36047e293c77c06b3cf86eea50b9265943047751). Worked a charm.
or cancel

geetarista Fri Aug 28 10:14:59 -0700 2009 | link

+1 We had an issue with Vimeo and our site blew up even though the request was in a rescue block.

Comment
+1 We had an issue with Vimeo and our site blew up even though the request was in a rescue block.
or cancel

kevn Tue Sep 01 22:46:07 -0700 2009 | link

+1 for attack's timeout patch. We, too, are running into failures when 3rd-party services are down. Is there a reason this hasn't been merged yet?

Comment
+1 for attack's timeout patch. We, too, are running into failures when 3rd-party services are down. Is there a reason this hasn't been merged yet?
or cancel

Parsed with GitHub Flavored Markdown
6.

1 vote

JSON parser mishandles backslashes
3 comments Created 8 months ago by jnunemaker

Title

Body
HTTParty's JSON parser seems to not handle backslashes properly. A script that demonstrates can be found here: http://pastie.org/377389 Briefly, HTTParty::Parsers::JSON.decode('{"chokes": "on this \"}') raises an HTTParty::Parsers::JSON::ParseError, when services like JSONLint (jsonlint.com) deems {"chokes": "on this \"} to be valid JSON.
or cancel

HTTParty's JSON parser seems to not handle backslashes properly. A script that demonstrates can be found here: http://pastie.org/377389

Briefly, HTTParty::Parsers::JSON.decode('{"chokes": "on this "}') raises an HTTParty::Parsers::JSON::ParseError, when services like JSONLint (jsonlint.com) deems {"chokes": "on this "} to be valid JSON.

Comments

jnunemaker Thu Apr 16 15:55:11 -0700 2009 | link

Looks like I lost some backslashes in the description. "on this " should be "on this \" (with two backslashes) (assuming this renders the way I'm expecting).

Comment
Looks like I lost some backslashes in the description. "on this \" should be "on this \\" (with two backslashes) (assuming this renders the way I'm expecting).
or cancel

amerine Sat Apr 18 01:06:56 -0700 2009 | link

Are you sure its an HTTParty issue? Could it be crack?

Comment
Are you sure its an HTTParty issue? Could it be crack?
or cancel

jnunemaker Sun Apr 19 15:32:49 -0700 2009 | link

Yes, it is crack actually. Moving ticket there.

Comment
Yes, it is crack actually. Moving ticket there.
or cancel

Parsed with GitHub Flavored Markdown
5.

0 votes

Cannot parse recursive structure
2 comments Created 8 months ago by jnunemaker

Title

Body
The following code gives a 'stack level too deep' error message when run on the attached data file: require 'rubygems' require 'happymapper' class Node include HappyMapper element :node_name, String has_many :node, ::Node end class Taxonomy include HappyMapper element :taxonomy_name, String has_many :node, ::Node end class Taxonomies include HappyMapper has_many :taxonomy, ::Taxonomy end file_contents = File.read('worldguide_data/taxonomy_short.xml') taxonomies = Taxonomies.parse(file_contents) /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:93:in `create_collection': stack level too deep (SystemStackError) from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:93:in `each' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:93:in `create_collection' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:107:in `inject' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `each' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `inject' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `create_collection' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:79:in `parse' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper/item.rb:29:in `from_xml_node' ... 12965 levels... from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `inject' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `create_collection' from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:79:in `parse' from test.rb:22
or cancel
The following code gives a 'stack level too deep' error message when run on the attached data file:
```
require 'rubygems'
require 'happymapper'

class Node
  include HappyMapper
  element :node_name, String
  has_many :node, ::Node
end

class Taxonomy
  include HappyMapper
  element :taxonomy_name, String
  has_many :node, ::Node
end

class Taxonomies
  include HappyMapper
  has_many :taxonomy, ::Taxonomy
end

file_contents = File.read('worldguide_data/taxonomy_short.xml')
taxonomies = Taxonomies.parse(file_contents)

/opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:93:in `create_collection': stack level too deep (SystemStackError)
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:93:in `each'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:93:in `create_collection'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:107:in `inject'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `each'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `inject'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `create_collection'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:79:in `parse'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper/item.rb:29:in `from_xml_node'
     ... 12965 levels...
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `inject'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:90:in `create_collection'
    from /opt/local/lib/ruby/gems/1.8/gems/jnunemaker-happymapper-0.1.5/lib/happymapper.rb:79:in `parse'
    from test.rb:22
```
Comments

jnunemaker Thu Apr 16 15:44:47 -0700 2009 | link

From Mike Woodhouse (at old lighthouse project):

I tried that with 0.1.6 and didn't get the error, which was good.

Recursive structures still don't work properly, though: in Steve's example, the Taxonomy object gets 4 Nodes: the single "parent" one and the three "children". The parent does also get the children as you'd expect.

I'd already found this trying to write a script to play with my Google Reader OPML, which has some recursion of elements. See http://pastie.org/366720 , which shows where I was able to work around the problem by removing higher-level outlines that had no children (which got the desired result in this particular case).

Comment
From Mike Woodhouse (at old lighthouse project): I tried that with 0.1.6 and didn't get the error, which was good. Recursive structures still don't work properly, though: in Steve's example, the Taxonomy object gets 4 Nodes: the single "parent" one and the three "children". The parent does also get the children as you'd expect. I'd already found this trying to write a script to play with my Google Reader OPML, which has some recursion of <outline> elements. See http://pastie.org/366720 , which shows where I was able to work around the problem by removing higher-level outlines that had no children (which got the desired result in this particular case).
or cancel

jnunemaker Thu Apr 16 15:50:20 -0700 2009 | link

this was suppose to be for happymapper, please ignore.

Comment
this was suppose to be for happymapper, please ignore.
or cancel

Parsed with GitHub Flavored Markdown
4.

0 votes

Cannot have multiple child elements with a default namespace
1 comment Created 8 months ago by jnunemaker

Title

Body
HappyMapper 0.2.2 (commit 545ebcd8a8b6dec66a526244321fc1dfb171de05) libxml 0.9.8 If an object including HappyMapper has multiple child elements (via has_one or has_many) and a default namespace, an exception is raised when processing the second child element. I've recreated the issue in the specs, see attached diff. It seems trying to assign a default namespace prefix to a node fails in libxml, but HappyMapper should probably not try to do this anyway. I've fixed this ticket with http://github.com/lightningdb/happymapper/commit/ac6510bcec0314435d29ae092e857e965c0e1c28 The issue is that libxml falls over if the default prefix is assigned more than once. Seems to be a bug with libxml, but likewise it is probably something that happymapper should avoid anyway. So before assigning the default prefix, we check whether a default prefix has already been assigned. I've updated the tests to reflect this situation, by adding an extra 'has_one', which invokes the nested parsing that caused the error in the first place. I moved the Address class mapper definition up and added an address node to the product (I realise this doesn't make 'domain' sense, but it proves the issue and the fix). Hopefully John approves and can pull into the main happymapper?
or cancel

HappyMapper 0.2.2 (commit 545ebcd) libxml 0.9.8

If an object including HappyMapper has multiple child elements (via has_one or has_many) and a default namespace, an exception is raised when processing the second child element.

I've recreated the issue in the specs, see attached diff.

It seems trying to assign a default namespace prefix to a node fails in libxml, but HappyMapper should probably not try to do this anyway.

I've fixed this ticket with http://github.com/lightningdb/happymapper/commit/ac6510bcec0314435d29ae092e857e965c0e1c28

The issue is that libxml falls over if the default prefix is assigned more than once. Seems to be a bug with libxml, but likewise it is probably something that happymapper should avoid anyway.

So before assigning the default prefix, we check whether a default prefix has already been assigned.

I've updated the tests to reflect this situation, by adding an extra 'has_one', which invokes the nested parsing that caused the error in the first place. I moved the Address class mapper definition up and added an address node to the product (I realise this doesn't make 'domain' sense, but it proves the issue and the fix).

Hopefully John approves and can pull into the main happymapper?

Comments

jnunemaker Thu Apr 16 15:50:07 -0700 2009 | link

this was suppose to be for happymapper, please ignore.

Comment
this was suppose to be for happymapper, please ignore.
or cancel

Parsed with GitHub Flavored Markdown
3.

0 votes

Allowing reusable mapping classes
1 comment Created 8 months ago by jnunemaker

Title

Body
In the existing codebase, the xpath for non-primitive elements is from the downcased classname of the non-primitive class. This works well, but there are several cases where some more flexibility would be good. For instance, consider this XML: <game> <details> <quarter>1</quarter> <round>22</round> </details> <q1> <start>4:40:15 PM</start> </q1> <q2> <start>5:18:53 PM</start> </q2> <q3> <start>6:06:17 PM</start> </q3> <q4> <start>6:41:49 PM</start> </q4> </game> There is an obvious problem with this xml: the q1, q2, q3, q4 elements should be 'quarter' elements, with an attribute containing the quarter number. However, we usually don't have control of the format of external xml, so we just need to work with it. Anyway, we might map these with the following classes: class Quarter include HappyMapper element :start, String end class Details include HappyMapper element :round, Integer element :quarter, Integer end class Game include HappyMapper has_one :details, QuarterTest::Details has_one :q1, QuarterTest::Quarter has_one :q2, QuarterTest::Quarter has_one :q3, QuarterTest::Quarter has_one :q4, QuarterTest::Quarter end The problem is that the elements q1, q2, q3 and q4 will not be able to be found using the current HappyMapper implementation, since the xpath used will be 'quarter', which will find game/details/quarter in each case. Adding :tag => 'q1' etc will not help, since the tag name is derived from the class name. We can fix this and allow mapping classes to be resuable. Instead of using the classname as the default tag name, we can use the following finders, in order: 1. specified tag (e.g. :tag => 'q1') 2. name of element (e.g. from has_one :q1) 3. tag_name (derived from class name by default) Using this method, the Game class changes to: class Game include HappyMapper has_one :details, QuarterTest::Details has_one :q1, QuarterTest::Quarter, :tag => 'q1' has_one :q2, QuarterTest::Quarter, :tag => 'q2' has_one :q3, QuarterTest::Quarter, :tag => 'q3' has_one :q4, QuarterTest::Quarter, :tag => 'q4' end This is a bit of a change, but the additional flexibility and reusability has worked really well for me in a variety of situations. In the existing specs, I only had to make one change for everything to pass: class Radar include HappyMapper # OLD: has_many :places, Place # NEW: has_many :places, Place, :tag => :place end I've made the changes needed in my fork (http://github.com/lightningdb/happymapper/tree/master, commits ce59623df1ce0b16bbbee89e6fac2b2473756a43 and 3251509d1e68fb652227a42b1e5593ee8bc19d5b), and updated the gemspec version to 0.3.0 to reflect that the change might need minor changes to existing mappings. I think the flexibility is worth it though. Any thoughts or questions?
or cancel
In the existing codebase, the xpath for non-primitive elements is from the downcased classname of the non-primitive class. This works well, but there are several cases where some more flexibility would be good.

For instance, consider this XML:
```
<game>
  <details>
    <quarter>1</quarter>
    <round>22</round>
  </details>
  <q1>
    <start>4:40:15 PM</start>
  </q1>
  <q2>
    <start>5:18:53 PM</start>
  </q2>
  <q3>
    <start>6:06:17 PM</start>
  </q3>
  <q4>
    <start>6:41:49 PM</start>
  </q4>
</game>
```
There is an obvious problem with this xml: the q1, q2, q3, q4 elements should be 'quarter' elements, with an attribute containing the quarter number. However, we usually don't have control of the format of external xml, so we just need to work with it. Anyway, we might map these with the following classes:
```
class Quarter
  include HappyMapper

  element :start, String
end

class Details
  include HappyMapper

  element :round, Integer
  element :quarter, Integer
end

class Game
  include HappyMapper

  has_one :details, QuarterTest::Details
  has_one :q1, QuarterTest::Quarter
  has_one :q2, QuarterTest::Quarter
  has_one :q3, QuarterTest::Quarter
  has_one :q4, QuarterTest::Quarter
end
```
The problem is that the elements q1, q2, q3 and q4 will not be able to be found using the current HappyMapper implementation, since the xpath used will be 'quarter', which will find game/details/quarter in each case. Adding :tag => 'q1' etc will not help, since the tag name is derived from the class name.

We can fix this and allow mapping classes to be resuable. Instead of using the classname as the default tag name, we can use the following finders, in order:
1. specified tag (e.g. :tag => 'q1')
2. name of element (e.g. from has_one :q1)
3. tag_name (derived from class name by default)

Using this method, the Game class changes to:
```
class Game
  include HappyMapper

  has_one :details, QuarterTest::Details
  has_one :q1, QuarterTest::Quarter, :tag => 'q1'
  has_one :q2, QuarterTest::Quarter, :tag => 'q2'
  has_one :q3, QuarterTest::Quarter, :tag => 'q3'
  has_one :q4, QuarterTest::Quarter, :tag => 'q4'
end
```
This is a bit of a change, but the additional flexibility and reusability has worked really well for me in a variety of situations. In the existing specs, I only had to make one change for everything to pass:
```
class Radar
  include HappyMapper
  # OLD: has_many :places, Place
  # NEW:
  has_many :places, Place, :tag => :place
end
```
I've made the changes needed in my fork (http://github.com/lightningdb/happymapper/tree/master, commits ce59623 and 3251509), and updated the gemspec version to 0.3.0 to reflect that the change might need minor changes to existing mappings. I think the flexibility is worth it though.

Any thoughts or questions?
Comments

jnunemaker Thu Apr 16 15:49:48 -0700 2009 | link

this was suppose to be for happymapper, please ignore.

Comment
this was suppose to be for happymapper, please ignore.
or cancel

Parsed with GitHub Flavored Markdown
2.

0 votes

Cannot declare has_many with primitive type
1 comment Created 8 months ago by jnunemaker

Title

Body
I have the following mapping for the attached xml: module FamilySearch class AlternateIds include HappyMapper tag 'alternateIds' has_many :ids, String, :tag => 'id' end class Information include HappyMapper has_one :alternateIds, AlternateIds end class Person include HappyMapper attribute :version, String attribute :modified, Time attribute :id, String has_one :information, Information end class Persons include HappyMapper has_many :person, Person end class FamilyTree include HappyMapper tag 'familytree' attribute :version, String attribute :status_message, String, :tag => 'statusMessage' attribute :status_code, String, :tag => 'statusCode' has_one :persons, Persons end end Notice the AlternateIds class declares a has_many with type String, which should assign ids as a collection of Strings. However, ids ends up being a String of the first object. I have a failing spec in my fork that represents this situation: http://github.com/jimmyz/happymapper/commit/496365548e20a15707a46be9a756b1035301773e
or cancel
I have the following mapping for the attached xml:
```
module FamilySearch
  class AlternateIds
    include HappyMapper

    tag 'alternateIds'
    has_many :ids, String, :tag => 'id'
  end

  class Information
    include HappyMapper

    has_one :alternateIds, AlternateIds
  end

  class Person
    include HappyMapper

    attribute :version, String
    attribute :modified, Time
    attribute :id, String
    has_one :information, Information
  end

  class Persons
    include HappyMapper
    has_many :person, Person
  end

  class FamilyTree
    include HappyMapper

    tag 'familytree'
    attribute :version, String
    attribute :status_message, String, :tag => 'statusMessage'
    attribute :status_code, String, :tag => 'statusCode'
    has_one :persons, Persons
  end
end
```
Notice the AlternateIds class declares a has_many with type String, which should assign ids as a collection of Strings. However, ids ends up being a String of the first object.

I have a failing spec in my fork that represents this situation:
http://github.com/jimmyz/happymapper/commit/496365548e20a15707a46be9a756b1035301773e
Comments

jnunemaker Thu Apr 16 15:49:29 -0700 2009 | link

this was suppose to be for happymapper, please ignore.

Comment
this was suppose to be for happymapper, please ignore.
or cancel

Parsed with GitHub Flavored Markdown
1.

0 votes

Cannot get attribute when there is element of same name
1 comment Created 8 months ago by jnunemaker

Title

Body

or cancel

Comments

jnunemaker Thu Apr 16 15:46:54 -0700 2009 | link

this was suppose to be for happymapper, please ignore.

Comment
this was suppose to be for happymapper, please ignore.
or cancel

Parsed with GitHub Flavored Markdown

Labels

jnunemaker / httparty

Pledgie Donations

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Comments