Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 593

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/galeal/ideaforge.org/blog/wp-includes/classes.php on line 710

Strict Standards: Redefining already defined constructor for class wpdb in /home/galeal/ideaforge.org/blog/wp-includes/wp-db.php on line 58

Deprecated: Assigning the return value of new by reference is deprecated in /home/galeal/ideaforge.org/blog/wp-includes/cache.php on line 99

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/galeal/ideaforge.org/blog/wp-includes/cache.php on line 404

Deprecated: Assigning the return value of new by reference is deprecated in /home/galeal/ideaforge.org/blog/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /home/galeal/ideaforge.org/blog/wp-includes/theme.php on line 576
Hyperactive Resource — The Idea Forge

Hyperactive Resource

There’s rumblings here and there about how ActiveResource isn’t really complete. The documentation refers to features that aren’t implemented, etc.

That’s just the tip of the iceberg.

The documentation states that ActiveResource behaves “very similarly to Active Record”. But ActiveResource doesn’t support any of the meta-data that ActiveRecord uses (like belongs_to, has_many, etc). So even the simplest cases behave radically different than you might expect.

A small sampling of things that don’t work:

a_person = Person.new

a_person.name = Luke #No method something= !!
a_person.parent #No belongs_to
a_person.children #No has_many

This is all fine if you are writing an app from scratch to use ActiveResource (well.. that’s debatable). At Medical Decision Logic, we needed to replace ActiveRecord with ActiveResource in an app with 50,000 lines of Ruby code. So we wrote Hyperactive Resource.

Hyperactive Resource

Hyperactive Resource extends ActiveResource::Base to make it.. work properly. You should use it. It’s awesome.

Check it out at http://github.com/lukegalea/hyperactiveresource/wikis

17 comments ↓

#1 Adrian on 08.18.08 at 5:22 am

I came across this ‘issue’ and was shocked. I worked around it by reverting to old-school methods - creating an ActiveResource proxy class and serializing my real class data before it went over the wire. I reconstructed the classes at the server end.

I think the whole Restful movement is mis-guided in several places, this being one. We don’t generally write simple CRUD applications that work on individual classes in isolation, so let’s stop pretending that this is enough. I think the same problem applies to named routes - the seven restful methods don’t simplify my controllers, they obfuscate the true work-flow of my application.

I’ll be sure to check out your code as soon as I get the chance - ActiveResource that fetches ActiveRecord meta data would be awesome.

#2 Luke Galea on 08.18.08 at 5:36 am

A few people have asked about that (having a controller that responds to meta data requests).

My only concern there is that it does feel like WSDL at that point. We’d effectively be defining a new meta-data description format.

On the other hand, it’s not very DRY right now….

#3 Inflector.erl: Rails Style String Inflection For Erlang — The Idea Forge on 09.08.08 at 6:24 pm

[...] developers use erlang + mnesia to replace their ruby models and traditional relational DBs (using Hyperactive Resource + Mochiweb). But a key part of interoperating with rails is being able to infer that [...]

#4 bryanl on 09.12.08 at 4:25 am

Who says you have to use ActiveResource at all? Why not use something simpler like httparty? Grafting more complexity on an already complex piece of code doesn’t seem like it doing any one any great service.

#5 Luke Galea on 09.12.08 at 5:16 am

In our case, we had > 50k lines of code written that assumed activerecord.

Hyperactive Resource let us move from record to resource “almost” seamlessly.

When writing a greenfield app, I’d consider something like httparty. But if you found yourself writing client side validation, callbacks, etc then you’d want to back out and go for the more complex route rather than re-invent the wheel IMHO.

#6 Steve on 09.12.08 at 8:32 am

@Adrian

“I think the whole Restful movement is mis-guided in several places, this being one. We don’t generally write simple CRUD applications that work on individual classes in isolation, so let’s stop pretending that this is enough.”

I don’t think this is a limitation of REST but it’s definitely a limitation of ActiveResource. Discoverable links are a fundamental propery of REST. Imagine the web without links!

So ideally an XML representation of a model could have links to other models, and ActiveResource could handle that. For example ‘. ActiveResource would automatically grok that and dynamically add a ‘children’ method that would make the remote request. No need to statically add a ‘has_many :children’; links are discoverable. I’m implemented something like this but never used it.

In the ‘REST Web Services’ they wrote a Ruby WADL client:

http://www.crummy.com/software/wadl.rb/wadl.rb

If you’re not too much of a REST purist and can stomach a service description file, WADL combined with a library like this makes writing clients trivial.

#7 Luke Galea on 09.12.08 at 9:56 am

Nice idea re: WADL. I’ll investigate.

#8 rick on 09.12.08 at 9:35 pm

Why not just contribute back to ActiveResource with your enhancements?

#9 fury_on_fails on 09.15.08 at 6:43 am

@rick: best point so far.

#10 Luke Galea on 09.15.08 at 10:34 am

Hi Rick,

We’ve had little/no success trying to get patches approved by the Rails core team if they are for new features. It’s actually an official policy I remember reading somewhere. You can submit bug fixes, but even those we’ve had problems with.

Rather than complain or risk other developers suffering with ActiveResource as it stands, we felt we were better off just releasing what we had and hoping the rails core team will feel free to cherry pick from us.

#11 Michael Koziarski on 09.16.08 at 8:11 am

Hi Luke,

You’ve done some nice work here, and it’d be great if we could pull stuff like this into active resource itself.

I realise that we’ve been a little tardy in the past with replying to patches, but we’re really not as bad as the FUDsters would have you believe ;).

Our policy is definitely not that you may only contribute bug fixes, we welcome features from anyone with the motivation and wherewithal to get a patch finished. That’s not to say we’d apply everything but it’s hardly the inverse either.

Out of interest, what attempts did you make to have us apply your patches? No one from ideaforge has ever contacted the core list, and the only emails you’ve sent that I’ve received have been the rails talk list. So apologies if you’ve contacted me or the list and not heard back, it must’ve been lost in the spam-traps.

#12 Luke Galea on 09.16.08 at 8:58 am

Hi Michael,

Sorry, didn’t mean to further propagate the FUD :)

I work for Medical Decision Logic (mdlogix.com) and it’s been my colleagues who have submitted patches unsuccessfully, so I’m not speaking from personal experience. Mostly they are fixes for problems that relate to MS-SQL so I’m not entirely surprised they’ve been overlooked in favour of the common good ;)

And for the life of me I can’t find where I read that feature patches wouldn’t be accepted!

Well that’s that. I’ll write up a patch!

#13 Michael Koziarski on 09.16.08 at 10:16 am

We don’t accept ‘feature request tickets’, which is basically just a ticket saying ‘hey, please make rails do X’ without any patches or intention of attaching them.

Perhaps there was (is?) some unclear documentation somewhere?

#14 Luke on 01.23.09 at 9:09 am

Thanks Luke for the time you’ve spent on Hyperactive Resource and for making this publicly available! I feel like this is one step closer to getting ActiveScaffold to sit on top of ActiveResource, but I still ran into a few issues. Has there been any success stories of this working, or is ActiveScaffold really only configured to work with ActiveRecord?

#15 terrance on 12.16.13 at 10:19 pm

defied@scouring.profiles” rel=”nofollow”>.…

thanks!…

#16 Derrick on 03.09.14 at 9:19 pm

civilized@phosphate.cappy” rel=”nofollow”>.…

спасибо….

#17 Gilbert on 03.12.14 at 6:52 am

crowder@attrition.cashed” rel=”nofollow”>.…

благодарствую!…

You must log in to post a comment.