Initial release of acts_as_resource 18
Right. I’ve bundled acts_as_resource up and stuck it on the typosphere SVN server. You can grab it from http://svn.typosphere.org/typo/plugins/acts_as_resource if you’re interested.
It’s currently in what I’d call an all convention, no configuration state – if your resources don’t look pretty similar to the kind of things you get from the resource scaffolding, you’ll probably have some pain, but I expect to rectify that with coming releases. One thing I want/need to do for instance is to allow for ‘relative’ ids in your resource url. For instance, if you’re looking at /albums/10/tracks/982, it’s not the most readable of permalinks… next trick is to allow you to have urls like /albums/because-its-there/tracks/1, ie: the first track on the album ‘Because it’s There’. I’m sort of expecting that you’d do that by doing:
class Album
has_many :tracks
acts_as_resource :uri_field => :name_dasherized
end
class Track
belongs_to :album
acts_as_list
acts_as_resource :uri_field => :position, :parent => :album
end
However, my first priority is to add some tests (or, more likely,Rspec specifications) so I’ve got some confidence that I’m not breaking things as I go.
Anyhow, go grab the plugin, have a play, let me know what you think.

I guess my question is, “Why?”. I mean, why would an end user care about the URL in their browser? As opposed to, say, a “track_number” attribute that they could see within a view? Or do you have some other nefarious use for that URL?
Also, will that URL work as the end point to a web service?
Just curious.
Why the possible extension? Or why the plugin?
Assuming the former, well, it’s because the URL is the new command line. It seems to me that the choice is between Seaside’s ‘HREF considered harmful approach’ of having an utterly opaque URL after the first entry point and trying to make URLs carry meaning. And yes, of course the resulting URLs can serve as an entry point for web service. Assuming I do end up implementing meaningful URLS, the resulting URL would be the only URL for the particular resource.
This comes from a project I’m working on where the resources already have well known IDs that are container scoped. It makes sense to expose those identifiers in the URL rather than some brand new and wholly unfamiliar integer id. I doubt I’m the only person with a similar need.
Posted at http://agilewebdevelopment.com/plugins/acts_as_resource :)
I still don’t understand what the need is exactly. In my experience end users don’t even look at the URL, except perhaps to copy/paste them into an email when they encounter a problem.
But, hey, I’m relatively new to the whole web programming thing, so maybe I’m missing the big picture here.
Daniel Berger, RESTful URLs are very common. In fact the are so common they are being used for a lot of applications and they are built into rails.
SEO is another benefit of descriptive URL’s
SEO? Someone Else’s Opinions? Search Everywhere Once? Suck Elvis Off?
Enquiring minds want to know.
Oh, right. RESTful URL’s. Forgot about REST. Good point.
Hey, I said I was relatively new to this! I’m still using xml-rpc over here! It’s hard to keep up with the new and better way of doing things, especially since the “new and better way” seems to change, like, every two weeks in the world of web programming (and especially Rails). ;)
http://en.wikipedia.org/wiki/SEO
REST really isn’t that new. I asked DHH about it on IRC not long after Rail first got announced – /:controller/:action/:id just seemed to be the wrong way round.
Why did you choose to put acts_as_resource on the model? It feels like it belongs in the controller.
Because a model is an object, not a data structure. The generated methods don’t need any of the controller’s state, so, obviously, they belong to the model.
Actually, Seaside isn’t dependent on the opaque URLs. I thought it was too, but I was wrong. It turns out that Pier, which is built on top of Seaside, includes methods for RESTful URLs. I haven’t played with these yet, but by all reports Seaside’s had REST support for a while.
Sometimes I wonder why I’m bothering with Ruby on Rails. Seaside is so nice.
Hey, let’s even comment on the right post this time. :-)
Here is a patch to try and make the index action behave correctly on top-level resources. Eg for Article, with no parent, it’ll prefill
@articles. http://woss.name/dist/index-action-works-with-top-level-resources.diffIn practice, I’m not sure how useful prefilling any of the collection ones will be once the data set increases to the level that I need pagination of some variety, but I’ll cross that gorge when I come to it.
Ah, yes. I’m inclined to roll Why’s pagination trick or something like it at some point.
Thanks for the patch, I shall take a proper look at it later.
Why’s pagination trick?
Argh. Sorry for not getting back to you on this. It’s not Why’s trick, it’s something from Err the Blog, you’ll find it at http://errtheblog.com/post/929