-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using a hash as the data object does not seem to work. #21
Comments
I never considered using a hash as the object, interesting idea. I always used a class (ORM) record as the object. I guess I don't see a reason a Hash couldn't be made to work but not surprising it doesn't. There are a few assumptions I made about the object right now and one of them is that the object responds to the "valid?" method and that it has dot notations to access attributes. Here's how I would achieve what you want for now: object false
node(:foo) { "bar" }
node(:pop) { 123 } or if its a nested hash: object false
node(:thing) { @thing } I have to give this some thought, this is a use case I never considered supporting. |
Also as for the |
Hi, Thanks for the feedback - will try what you suggest. I tried creating a local object like this: class Thing
attr_accessor :foo, :pop
def initialize(a,b)
@foo =a
@pop =b
end
end So the controller did this: @thing2 = Thing.new("boo",987) And template is this: object @thing2
attributes :foo, :pop Getting 'null' response (when I specify the format). On the to_html stuff, yesterday I got away without it - not sure how. Wonder if there is a way to make json the default format. Thanks, |
Hi, Just to say your suggestion with the "object false" does the job - and is clearer in my controller, so I prefer it - the hash was a contrived object to get the data to the view - so better to not have it :) Thanks, |
@kimptoc the to_html error comes from this change yesterday: ed9ec55 in which I detect the request format if theres no explicit format. I will have to fix it by disallowing html as the format I think and default to json. As for the Thing record, try this for fun: class Thing < Struct.new(:foo, :pop)
def initialize(h)
super *h.values_at(*self.class.members.map {|s| s.intern})
end
def valid?; true; end
end and @thing2 = Thing.new(:foo => "boo", :pop => 987) Can you tell me if that works? |
@kimptoc Okay, I am actually going to close this for now, I have never had the need to use a hash as the object. I don't think I will in the future either. In the case of constructing a response from scratch I would go with the object false approach :) If you or someone else finds this issue, I am not against the idea if someone else would like to patch it in with a pull request. I will fix the "to_html" issue tho soon. Thanks! |
Hi, The Thing suggestion works just fine and yes, please close it - was going to suggest that. Regards, |
Hey @nesquena - perfect, works like a charm :) Many thanks. |
Excellent thanks man, pushing out a small gem point release. |
Hi,
I am probably doing this wrong, but I have a method that wants to return a collection and a status, so I am making my data object sort of like this:
@thing = {:foo => "bar", :pop => 123}
So, my rabl template is
Hoping to get
{ "foo" : "bar", "pop" :123}
But was getting this under last night's version:
{ "pop":"bar", "pop":123}
Today I get an error:
undefined method `to_html' for #<Rabl::Engine:0x1075c0730>
Perhaps I should be using the "object false" route...
Thanks,
Chris
PS Tried to add tests/fix it - seems that the problem is the attribute method can be passed a hash of options and its confusing the object hash as options:
https://github.com/kimptoc/rabl/commit/dc3be6eba6389998614f7cb846240aebcc2062ef
The text was updated successfully, but these errors were encountered: