Rails - Feb 2007 - Updating multiple RESTful records in one request

I like REST, it generally makes sense and is pretty easy to follow.

Where I''m having trouble though is when it comes to the point where
you need to update multiple records.

Say for instance you have an email application, which is RESTful.

Now lets say you go to your inbox and select 5 emails and you want to
mark them all as read.

It would be easy enough to create a custom action that would process
this kind of request, but is there a good way to do it while
maintaining REST?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I asked this very
question<http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/5b8e9e2d0b77c1/73000d78df51ffe7?lnk=gst&q=multiple+rest&rnum=2&hl=en#73000d78df51ffe7>about
a week ago and didn''t get a definitive answer.  The consensus was that
I was missing a model somewhere.  That answer didn''t really work for me
(since I was RESTifying a production app and couldn''t change it too
extremely).  So I have routes like:

  map.resources :emails, :collection => { :archive => :post, :destroy
=>
:delete }

and then, in your EmailsController#destroy, you need to handle multiple
email ids.  It''s a hack, but it can work.

ed

On 2/6/07, monki <geemus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> I like REST, it generally makes sense and is pretty easy to follow.
>
> Where I''m having trouble though is when it comes to the point
where
> you need to update multiple records.
>
> Say for instance you have an email application, which is RESTful.
>
> Now lets say you go to your inbox and select 5 emails and you want to
> mark them all as read.
>
> It would be easy enough to create a custom action that would process
> this kind of request, but is there a good way to do it while
> maintaining REST?
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for the reference to the previous discussion and your choice of
solution.

I''m designing a new app luckily, and I''m still in the
"making pieces
fit together" stage of things.
So I have a lot more liberty in my data modeling.

I think I understand well enough to try and put something together.

I suppose I just need to treat the "mark multiple emails as read"
action as a seperate model.
Then you can restfully create batch requests.

Seems like a round about way to do it, but maybe I just need to let
the idea sink in better...


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Short a specific answer to that very common problem I would be disinclined
to agree that you''re missing a model to represent a collection of
accounts.
If it''s clean and clear and there''s a convention there it
should''ve been
easy to get an answer to your very simple and fair question about updating
multiple records.

On 2/6/07, monki <geemus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Thanks for the reference to the previous discussion and your choice of
> solution.
>
> I''m designing a new app luckily, and I''m still in the
"making pieces
> fit together" stage of things.
> So I have a lot more liberty in my data modeling.
>
> I think I understand well enough to try and put something together.
>
> I suppose I just need to treat the "mark multiple emails as read"
> action as a seperate model.
> Then you can restfully create batch requests.
>
> Seems like a round about way to do it, but maybe I just need to let
> the idea sink in better...
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I still tend to agree.

It might be great to wrap your transactions in a model of some sort if
you need to do auditing or other things, but most apps don''t need the
extra overhead.

There are certainly situations where the "you missed a model" answer
is probably quite true, as DHH did when he introduced a lot of this
stuff.  In that case it did make sense to squeeze another model in the
middle to solve the problem.

I don''t necessarily think that the sort of processing we are talking
about fits into that same notion though.  Or at least I remain
unconvinced.

That doesn''t mean that I have some shining light or better way either,
unfortunately.
It just means I haven''t figured this out yet (and I suspect
I''m not
the only one).


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You don''t necessarily need a separate model to handle operations on
multiple records.

I''ve got a few places in my app where I need to perform an action on a
group of related records, and the best way I''ve found is to use class
methods.  You could simply define a Message.mark_as_read(message_ids)
method in your message class.  Class methods are useful when you need
to do table-level (as opposed to row-level) operations.  That way,
you''re keeping all the logic for marking multiple messages as read in
the model, where it belongs, and your controller can simply have an
''archive'' action to call it and pass it the array of
message_ids.

On Feb 7, 10:37 am, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I still tend to agree.
>
> It might be great to wrap your transactions in a model of some sort if
> you need to do auditing or other things, but most apps don''t need
the
> extra overhead.
>
> There are certainly situations where the "you missed a model"
answer
> is probably quite true, as DHH did when he introduced a lot of this
> stuff.  In that case it did make sense to squeeze another model in the
> middle to solve the problem.
>
> I don''t necessarily think that the sort of processing we are
talking
> about fits into that same notion though.  Or at least I remain
> unconvinced.
>
> That doesn''t mean that I have some shining light or better way
either,
> unfortunately.
> It just means I haven''t figured this out yet (and I suspect
I''m not
> the only one).

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

That sounds entirely logical to me.

I would agree that using the class method is a good way to implement
it too.

The problem is that, by my understanding, you would be breaking out of
the REST paradigm.
REST aims to make it such that the only actions are create, read,
update and delete.

As per DHH in the <a href="http://weblog.rubyonrails.org/2007/1/19/
rails-1-2-rest-admiration-http-lovefest-and-utf-8-celebrations">1.2
announcement</a>
"Then start thinking about how your application could become more
RESTful. How you too can transform that 15-action controller into 2-3
new controllers each embracing a single resource with CRUDing love."

REST uses nouns, not verbs.  So having other actions than CRUD (which
can use the same noun, at least in theory, by using HTML PUT, GET,
DELETE) is against the RESTful rules.

I want to be able to click a button and have it submit several
requests to the same action.  That is what a batch controller or an
external application would do.
There just doesn''t seem to be a good, direct way to do this (that I
know of) within a webpage...


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I had a similar problem...

I wanted an action to connect a product to it''s categories...

So the web user can pick several categories from a list and assign it to the
current product

This means you have two different model classes, one single product and
several categories that should be connected by a m:n relationship. how could
you model something like that in crud?

I find the idea of having a ProductCategoriesController a little awkward :-(

Having an action set_categories inside the ProductController that accepts a
list of categories seems logical but doesn''t fit into crud either.

My personal opinion is that REST has it''s limits and is no replacement
for
bulky controller actions and routes *sigh*


2007/2/7, monki
<geemus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
>
> That sounds entirely logical to me.
>
> I would agree that using the class method is a good way to implement
> it too.
>
> The problem is that, by my understanding, you would be breaking out of
> the REST paradigm.
> REST aims to make it such that the only actions are create, read,
> update and delete.
>
> As per DHH in the <a href="http://weblog.rubyonrails.org/2007/1/19/
> rails-1-2-rest-admiration-http-lovefest-and-utf-8-celebrations">1.2
> announcement</a>
> "Then start thinking about how your application could become more
> RESTful. How you too can transform that 15-action controller into 2-3
> new controllers each embracing a single resource with CRUDing love."
>
> REST uses nouns, not verbs.  So having other actions than CRUD (which
> can use the same noun, at least in theory, by using HTML PUT, GET,
> DELETE) is against the RESTful rules.
>
> I want to be able to click a button and have it submit several
> requests to the same action.  That is what a batch controller or an
> external application would do.
> There just doesn''t seem to be a good, direct way to do this (that
I
> know of) within a webpage...
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Just curious what you guys think of this:

Why not create a transient (no db table) model named EmailBatch or
whatever.  Conceptually it would always exist and it''s id is always 1
so you''d always do PUT/update operations.  You simply initialize it
with whatever group of emails you need to deal with at any given
moment.

Then have an EmailBatchesController with routes like the following.

/inbox/email_batch/1;read

or whatever.

Did that make sense?

Tim



On Feb 6, 7:09 am, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I like REST, it generally makes sense and is pretty easy to follow.
>
> Where I''m having trouble though is when it comes to the point
where
> you need to update multiple records.
>
> Say for instance you have an email application, which is RESTful.
>
> Now lets say you go to your inbox and select 5 emails and you want to
> mark them all as read.
>
> It would be easy enough to create a custom action that would process
> this kind of request, but is there a good way to do it while
> maintaining REST?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

oops sorry... that route is:

/inbox/37/email_batch/1;read

or whatever:-)
Tim

On Feb 7, 11:04 am, mcintyre....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wrote:
> Just curious what you guys think of this:
>
> Why not create a transient (no db table) model named EmailBatch or
> whatever.  Conceptually it would always exist and it''s id is
always 1
> so you''d always do PUT/update operations.  You simply initialize
it
> with whatever group of emails you need to deal with at any given
> moment.
>
> Then have an EmailBatchesController with routes like the following.
>
> /inbox/email_batch/1;read
>
> or whatever.
>
> Did that make sense?
>
> Tim
>
> On Feb 6, 7:09 am, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I like REST, it generally makes sense and is pretty easy to follow.
>
> > Where I''m having trouble though is when it comes to the point
where
> > you need to update multiple records.
>
> > Say for instance you have an email application, which is RESTful.
>
> > Now lets say you go to your inbox and select 5 emails and you want to
> > mark them all as read.
>
> > It would be easy enough to create a custom action that would process
> > this kind of request, but is there a good way to do it while
> > maintaining REST?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Seems like a lot of bending over backwards for a new, shiny concept
like REST when a simple "each" loop and set of checkboxes works fine.

I predict that, like so many other design fads, REST will be a
"remember that thing?" 10 years from now. Don''t kill yourself
for it.
Get as close as you can.

-Nate


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

The thing that''s helped me the most in refactoring to REST is
understanding what Nouns need to be accessible externally.  My RESTful
controllers support the basic CRUD operations, and then, as needed
have additional operations for the in-browser user experience.  In
this case, I''d say that "mark selected emails read" is the
sort of
thing that a user interacting with the application via a web browser
would like to have, but it probably doesn''t matter to an XML REST
client consuming your site externally.  So, in that case, I don''t mind
having a controller with 9-12 actions where the extra actions support
the user experience.

If you''re finding that you want to view the mailbox externally, check
off messages, and mark them as read over REST, the client can do some
of the lifting for you, in which case that client will loop over the
IDs and make separate PUT calls to change the has_been_read status
from false to true.

On Feb 7, 11:43 am, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> That sounds entirely logical to me.
>
> I would agree that using the class method is a good way to implement
> it too.
>
> The problem is that, by my understanding, you would be breaking out of
> the REST paradigm.
> REST aims to make it such that the only actions are create, read,
> update and delete.
>
> As per DHH in the <a href="http://weblog.rubyonrails.org/2007/1/19/
> rails-1-2-rest-admiration-http-lovefest-and-utf-8-celebrations">1.2
> announcement</a>
> "Then start thinking about how your application could become more
> RESTful. How you too can transform that 15-action controller into 2-3
> new controllers each embracing a single resource with CRUDing love."
>
> REST uses nouns, not verbs.  So having other actions than CRUD (which
> can use the same noun, at least in theory, by using HTML PUT, GET,
> DELETE) is against the RESTful rules.
>
> I want to be able to click a button and have it submit several
> requests to the same action.  That is what a batch controller or an
> external application would do.
> There just doesn''t seem to be a good, direct way to do this (that
I
> know of) within a webpage...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I don''t know if I''d go so far as to suggest that REST will
wind up
completely forgotten... there will always be certain cases where we want 
machine-to-machine communication.

However, I do smell a little bit of shiny-new-thing-itis... I would 
throw out the question: how many people playing (struggling?) with 
RESTful rails actually have a machine-to-machine use case? Are most 
people adding REST services "just in case"?

b

PS: My current project is currently fleshing out an application with 
very heavy REST usage, so I don''t mean to come off as a luddite here.

Nate Wiger wrote:
> Seems like a lot of bending over backwards for a new, shiny concept
> like REST when a simple "each" loop and set of checkboxes works
fine.
> 
> I predict that, like so many other design fads, REST will be a
> "remember that thing?" 10 years from now. Don''t kill
yourself for it.
> Get as close as you can.
> 
> -Nate
> 
> 
> > 
> 
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 8, 5:43 am, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> That sounds entirely logical to me.
>
>
> REST uses nouns, not verbs.  So having other actions than CRUD (which
> can use the same noun, at least in theory, by using HTML PUT, GET,
> DELETE) is against the RESTful rules.
>
Just a point of clarification of the concept of REST (at least the one
that is inside my head).

REST .NEQ. CRUD

REST uses verbs acting on nouns.

Simple entities with trivial life-cycles can be handled with CRUD.
They are either there or they are not. In business analysis terms,
these are usually classifiers or look-ups (e.g. sales area, message
type,...)

More interesting entities have a richer life-cycle typically marked
with a status field.
 (e.g. Mail message={Unread,Read,Archived}, WorksOrder {Booked,Scheduled,In
Progress, Completed,Billed} )

Now moving from one status to another is a life-cycle event and often
there is extra data involved.
So the ''Read'' event for the mail-message moves it from
''Unread'' to
''Read'' and may involve populating the read_date column.
The  ''StartWork'' event for the WorksOrder moves it from the
''Scheduled'' to ''In progress'' state and may
involve populating the
start_date and also adding work-queue information to other parts of
the data model.

This concept is very well documented in its variants as ''finite state
machine'', ''state transition diagram'',''state
machine'',''state
engine'',''life-cycle model'',.....

One of the goals of REST is to surface your state-engine events as
verbs on the underlying nouns.

As he climbs wearily down from his soap-box, "Oh yeah, it only works
for a single entity life-cycle, so class methods are good for small
batches".



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

ChrisR
> One of the goals of REST is to surface your state-engine events as
> verbs on the underlying nouns.
Yes.  I agree, but I think the ''state machine'' description is
useful.
> One of the goals of REST is to surface your state-engine events as
> verbs on the underlying nouns.
I agree, but having custom verbs is also not good.
One of the main goals of the REST model is consistancy across models.
I think a lot of this type of state-to-state transition can be covered
with simple updates.
If you need more data than that you may need a has_many through sort
of thing.
> As he climbs wearily down from his soap-box, "Oh yeah, it only works
> for a single entity life-cycle, so class methods are good for small
> batches".
This is definately the case.  I think I have the pieces together in my
mind now.
All single model updates (the stuff that would be accessible both
externally and internally) probably ought to be restful.
If you need to do stuff like batch processing you can add extra
options/actions, and it won''t break REST.

Thats because when you add these external options for internal use you
are really building a client,
which just happens to reside on the server due to the nature of the
web.
So, go wild but keep it to yourself.
Which, I think is what Jared was suggesting.

As for Nate and Ben.
I think that REST is useful and there is a growing need for machine-to-
machine interaction.
BUT, I think people are misunderstanding what that entails and going
overboard or "bending over backwards" to try and fit round pegs into
square holes.

Lots of discussion, so a summary of my thoughts:

Use/Expose a RESTful interface to each of your models, to handle all
the requests to manipulate single objects.
More complex and batched commands can exist outside the REST model, in
order to provide client-type functionality.
These complex functions need not be exposed (each client should
provide their own utility functions), and for consistancy
they should use the REST methods to actually do the meat of the work
(therefore decoupling/drying up the actual model manipulation from
other complex logic).

Hopefully that makes some sense, I at least feel like I have a much
firmer grasp of what I''m up against.
I think it may take me a bit more time to really put it down in a
succinct, elequent manner...


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

So what''s the point?

REST is good for simple stuff ... and that''s it???

just another hype/buzzword?

my current summary (with the ''mark emails as read'' example):

- I don''t think it makes sense to iterate several emails in the
browser to mark them unread (c''mon, one http request for each mail,
you gotta be kidding :-)

- having additional nouns/verbs that affect more than one model type
or instance seems not to fit into REST

- I don''t think a ''EmailBatch'' can necessarily be
seen as a model

- having an extra so called ''batch-processor'' for every little
operation consisting of more than one item or whatever sounds
ridicuous IMHO

- it seems that most people think REST ist cool but they all just
struggle with it. so REST is only useful for the most simple of cases
(create, read, update, delete) but gives you a headache if you need
more...

true?


On 7 Feb., 22:29, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> ChrisR> One of the goals of REST is to surface your state-engine events
as
> > verbs on the underlying nouns.
>
> Yes.  I agree, but I think the ''state machine''
description is useful.
>
> > One of the goals of REST is to surface your state-engine events as
> > verbs on the underlying nouns.
>
> I agree, but having custom verbs is also not good.
> One of the main goals of the REST model is consistancy across models.
> I think a lot of this type of state-to-state transition can be covered
> with simple updates.
> If you need more data than that you may need a has_many through sort
> of thing.
>
> > As he climbs wearily down from his soap-box, "Oh yeah, it only
works
> > for a single entity life-cycle, so class methods are good for small
> > batches".
>
> This is definately the case.  I think I have the pieces together in my
> mind now.
> All single model updates (the stuff that would be accessible both
> externally and internally) probably ought to be restful.
> If you need to do stuff like batch processing you can add extra
> options/actions, and it won''t break REST.
>
> Thats because when you add these external options for internal use you
> are really building a client,
> which just happens to reside on the server due to the nature of the
> web.
> So, go wild but keep it to yourself.
> Which, I think is what Jared was suggesting.
>
> As for Nate and Ben.
> I think that REST is useful and there is a growing need for machine-to-
> machine interaction.
> BUT, I think people are misunderstanding what that entails and going
> overboard or "bending over backwards" to try and fit round pegs
into
> square holes.
>
> Lots of discussion, so a summary of my thoughts:
>
> Use/Expose a RESTful interface to each of your models, to handle all
> the requests to manipulate single objects.
> More complex and batched commands can exist outside the REST model, in
> order to provide client-type functionality.
> These complex functions need not be exposed (each client should
> provide their own utility functions), and for consistancy
> they should use the REST methods to actually do the meat of the work
> (therefore decoupling/drying up the actual model manipulation from
> other complex logic).
>
> Hopefully that makes some sense, I at least feel like I have a much
> firmer grasp of what I''m up against.
> I think it may take me a bit more time to really put it down in a
> succinct, elequent manner...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

<...>
> - it seems that most people think REST ist cool but they all just
> struggle with it. so REST is only useful for the most simple of cases
> (create, read, update, delete) but gives you a headache if you need
> more...
>
> true?
False :)


Regards,
Rimantas
--
http://rimantas.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> just another hype/buzzword?
I think it is useful for structuring server side things, it just
doesn''t cover all the needs of a client.
> - I don''t think it makes sense to iterate several emails in the
> browser to mark them unread (c''mon, one http request for each
mail,
> you gotta be kidding :-)
I could go either way.  Iterating over them doesn''t really seem
intolerable to me,
and treating them as individual is cleaner and more regular than
somehow modifying multiples.
> - having additional nouns/verbs that affect more than one model type
> or instance seems not to fit into REST
I would still say this is the case, I''m not sure what you were saying
about them though.
I think it is important to be consistant so it would be better to keep
it limited to exposed CRUD operations when possible.
> - I don''t think a ''EmailBatch'' can necessarily
be seen as a model
I agree here.  I think it would be terrible case of premature
extraction,
but unfortunately a lot of people seem to be trying to head down that
road.
Or at least to use "find an extra model" as an easy way to answer a
hard question.
> - having an extra so called ''batch-processor'' for every
little
> operation consisting of more than one item or whatever sounds
> ridicuous IMHO
I agree, hence why I feel a request per item probably makes more
sense.
> - it seems that most people think REST ist cool but they all just
> struggle with it. so REST is only useful for the most simple of cases
> (create, read, update, delete) but gives you a headache if you need
> more...
>
> true?
I don''t think that it should be disregarded simply because it is hard
or misunderstood.
I think it is good to shift the focus to a resource driven
architecture, as this is often
a better/cleaner solution.  I just think it is folly to try and fit
everything within this context,
there are some things that are better off being outside this clean
little package.  The
kinds of things that an independant client would do to aide user
interaction still need to be
done, and I feel that it is in this area that REST alone falls short.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

>
> > - I don''t think it makes sense to iterate several emails in
the browser
> to mark them unread (c''mon, one http request for each mail,
> > you gotta be kidding :-)
> I could go either way.  Iterating over them doesn''t really seem
> intolerable to me, and treating them as individual is cleaner and more
> regular than somehow modifying multiples.

Yes, separate HTTP requests for the bulk actions seems a bit overkill to
me.  My solution for these multi-item actions was to just bastardize the
REST methodologies and allow the method to be passed multiple ids in the
query string.  I then iterate over then in the code.

> > - I don''t think a ''EmailBatch'' can
necessarily be seen as a model
> I agree here.  I think it would be terrible case of premature extraction,
> but unfortunately a lot of people seem to be trying to head down that
> road. Or at least to use "find an extra model" as an easy way to
answer a
> hard question.

I also agree.  For some cases, a new model makes sense, but for many things
(like EmailBatch) it seems unnecessary.  So great, you''re following the
REST
ideals but now your breaking other good coding methods and making things
generally more complicated!  For me, I think it will just take time to
understand the intricacies of REST and the best ways to handle the issue
that arise when coding under the inherent constraints.

-ed

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > just another hype/buzzword?
>
>
> > - I don''t think it makes sense to iterate several emails in
the
> > browser to mark them unread (c''mon, one http request for each
mail,
> > you gotta be kidding :-)
>
> I could go either way.  Iterating over them doesn''t really seem
> intolerable to me,
> and treating them as individual is cleaner and more regular than
> somehow modifying multiples.
>
I grew up with 8 bit computers where people cared about resources.
creating probably
houndreds of http(s) requests to mark 250 spam email for deletion is
just so horrible
that I must stop breathing... :-((


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I used to be able to destroy multiple records in my restful controller
by using the following:

in my view:

  <%= form_tag product_path, :method => :delete %>
    <% for product in @products %>
      <td><%= product.title  %></td>
      <td><%= check_box_tag (''id[]'', product.id)
%></td>
    </tr>
    <% end %>
<%= end_form_tag %>

and in my products_controller:

  def destroy
    begin
      # params[:id] may either be a single id, or an array of id''s
      @products = Product.find(params[:id])
    rescue
      logger.warn("ERROR: #{$!}")
    end

    if @products and Product.destroy(@products)
      flash[:notice] = "Product successfully deleted"
    else
      flash[:warning] = "An error was encountered while attempting to
delete the product(s)"
    end
  end

however, after upgrading to the most recent edge rails (6207 as of
yesterday), this no longer works.. I get an error

"product_url failed to generate from {:controller=>"products",
:action=>"show"} - you may have ambiguous routes, or you may need
to
supply additional parameters for this route."

I solved this by using the following:

in routes.rb:

  map.resources :products, :collection => {
    :delete => :delete
  }

in my view:

  <%= form_tag delete_products_path, :method => :delete %>
       blah blah...
  <%= end_form_tag %>

and then I use the same code in my controller, however, I alias the
delete method to destroy by using the following in my controller:

  alias delete destroy

so am I bastardizing RESTful standards? I''m sure I am, but I
can''t
think of a better way around this.  If anyone else has any ideas,
please let us know!  Also, why was I previously able to do this using
the standard restful routes (ie multiple id''s could be passed to an
action), but this no longer seems to be the case?

Mike


On 2/23/07, pete4711-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
<pete4711-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
>
>
>
> On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > just another hype/buzzword?
> >
> >
> > > - I don''t think it makes sense to iterate several emails
in the
> > > browser to mark them unread (c''mon, one http request for
each mail,
> > > you gotta be kidding :-)
> >
> > I could go either way.  Iterating over them doesn''t really
seem
> > intolerable to me,
> > and treating them as individual is cleaner and more regular than
> > somehow modifying multiples.
> >
>
> I grew up with 8 bit computers where people cared about resources.
> creating probably
> houndreds of http(s) requests to mark 250 spam email for deletion is
> just so horrible
> that I must stop breathing... :-((
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I''d be interested in seeing how DHH intends to implement this in
ActiveResource ... if it''s still being developed.  I checked today and
ActiveResource hasn''t been touched in a very, very long time.

It seems logical to expect methods to be able to act upon more than
one object ... in a batch.  I cringe at the thought of iterating over
every object in a collection just to do a batch update or create.  I''d
love to be able to upload an XML file to a RESTful URL and have it
know whether it''s a single object or a collection of objects.  It
seems to be that it would be as simple as determining whether the root
entity was singular or plural:

If I want to work with a single entity, I''d hit
http://www.myapplication.com/people/
with...
<person>
  <id>...</id>
  ...
</person>

and if I want to work with more than one person, I''d hit the same URL
with...
<people>
  <person>
    <id>...</id>
    ...
  </person>
  <person>
    <id>...</id>
    ...
  </person>
</people>

I''m trying to let a couple of applications talk together using REST
interfaces but, without this kind of functionality, it''s proving to be
very difficult.

Am I thinking about this incorrectly or does something like this seem
possible?

Thanks,
Chris

On Feb 23, 9:57 pm, "Mike Garey"
<random...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I used to be able to destroy multiple records in my restful controller
> by using the following:
>
> in my view:
>
>   <%= form_tag product_path, :method => :delete %>
>     <% for product in @products %>
>       <td><%= product.title  %></td>
>       <td><%= check_box_tag (''id[]'', product.id)
%></td>
>     </tr>
>     <% end %>
> <%= end_form_tag %>
>
> and in my products_controller:
>
>   def destroy
>     begin
>       # params[:id] may either be a single id, or an array of id''s
>       @products = Product.find(params[:id])
>     rescue
>       logger.warn("ERROR: #{$!}")
>     end
>
>     if @products and Product.destroy(@products)
>       flash[:notice] = "Product successfully deleted"
>     else
>       flash[:warning] = "An error was encountered while attempting to
> delete the product(s)"
>     end
>   end
>
> however, after upgrading to the most recent edge rails (6207 as of
> yesterday), this no longer works.. I get an error
>
> "product_url failed to generate from
{:controller=>"products",
> :action=>"show"} - you may have ambiguous routes, or you may
need to
> supply additional parameters for this route."
>
> I solved this by using the following:
>
> in routes.rb:
>
>   map.resources :products, :collection => {
>     :delete => :delete
>   }
>
> in my view:
>
>   <%= form_tag delete_products_path, :method => :delete %>
>        blah blah...
>   <%= end_form_tag %>
>
> and then I use the same code in my controller, however, I alias the
> delete method to destroy by using the following in my controller:
>
>   alias delete destroy
>
> so am I bastardizing RESTful standards? I''m sure I am, but I
can''t
> think of a better way around this.  If anyone else has any ideas,
> please let us know!  Also, why was I previously able to do this using
> the standard restful routes (ie multiple id''s could be passed to
an
> action), but this no longer seems to be the case?
>
> Mike
>
> On 2/23/07, pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
<pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>
>
>
> > On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > just another hype/buzzword?
>
> > > > - I don''t think it makes sense to iterate several
emails in the
> > > > browser to mark them unread (c''mon, one http
request for each mail,
> > > > you gotta be kidding :-)
>
> > > I could go either way.  Iterating over them doesn''t
really seem
> > > intolerable to me,
> > > and treating them as individual is cleaner and more regular than
> > > somehow modifying multiples.
>
> > I grew up with 8 bit computers where people cared about resources.
> > creating probably
> > houndreds of http(s) requests to mark 250 spam email for deletion is
> > just so horrible
> > that I must stop breathing... :-((

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 3/5/07, Chris Grant <cdgonline-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> I''d be interested in seeing how DHH intends to implement this in
> ActiveResource ... if it''s still being developed.  I checked today
and
> ActiveResource hasn''t been touched in a very, very long time.

That''s odd; where''d you check? There''s regular,
though not high-volume,
activity.

It seems logical to expect methods to be able to act upon more
than
> one object ... in a batch.  I cringe at the thought of iterating over
> every object in a collection just to do a batch update or create. 
I''d
> love to be able to upload an XML file to a RESTful URL and have it
> know whether it''s a single object or a collection of objects.  It
> seems to be that it would be as simple as determining whether the root
> entity was singular or plural:

There''s nothing stopping you, but it''s not baked in yet.  XML
params are
just read in as nested hashes, after all.

Try it, see what works best, extract the solution and post a patch!

jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Yeah, I forgot to mention that I''m gonna start working on this and see
what I can come up with.  I''m just a little surprised that it
wasn''t
baked-in from the beginning. ;)

On Mar 5, 11:57 pm, "Jeremy Kemper"
<jer...-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>
wrote:
> On 3/5/07, Chris Grant
<cdgonl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> > I''d be interested in seeing how DHH intends to implement this
in
> > ActiveResource ... if it''s still being developed.  I checked
today and
> > ActiveResource hasn''t been touched in a very, very long time.
>
> That''s odd; where''d you check? There''s regular,
though not high-volume,
> activity.
>
> It seems logical to expect methods to be able to act upon more than
>
> > one object ... in a batch.  I cringe at the thought of iterating over
> > every object in a collection just to do a batch update or create. 
I''d
> > love to be able to upload an XML file to a RESTful URL and have it
> > know whether it''s a single object or a collection of objects.
It
> > seems to be that it would be as simple as determining whether the root
> > entity was singular or plural:
>
> There''s nothing stopping you, but it''s not baked in yet. 
XML params are
> just read in as nested hashes, after all.
>
> Try it, see what works best, extract the solution and post a patch!
>
> jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 3/5/07, Chris Grant <cdgonline-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Yeah, I forgot to mention that I''m gonna start working on this and
see
> what I can come up with.  I''m just a little surprised that it
wasn''t
> baked-in from the beginning. ;)

Great! It''s not baked in because nobody ordered that entree yet.

"if it''s still being developed.  I checked today and
ActiveResource hasn''t
been touched in a very, very long time"

Still curious where you checked ;-)
jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I don''t know what I was looking at but, since checking the official
Trac (thought I was there before), I''m finding myself wrong on this
one.  Thanks for keeping me honest! ;)

On Mar 6, 12:43 am, "Jeremy Kemper"
<jer...-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>
wrote:
> On 3/5/07, Chris Grant
<cdgonl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> > Yeah, I forgot to mention that I''m gonna start working on
this and see
> > what I can come up with.  I''m just a little surprised that it
wasn''t
> > baked-in from the beginning. ;)
>
> Great! It''s not baked in because nobody ordered that entree yet.
>
> "if it''s still being developed.  I checked today and
ActiveResource hasn''t
> been touched in a very, very long time"
>
> Still curious where you checked ;-)
> jeremy

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I forgot to mention...

After searching around a bit, I stumbled upon some code that would
probably be a great base for what we''ve been talking about.  It straps
a from_xml method onto ActiveRecord::Base and has the logic to
determine whether the root is the singular or plural version of the
current class.  I''m not sure how resilient the code is when it comes
to nested associations and such but it''s worth a look.

The code is here: http://riftor.g615.co.uk/content.php?view=50&type=1

-Chris


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Chris,

On 5-Mar-07, at 9:39 PM, Chris Grant wrote:
>
> I''d be interested in seeing how DHH intends to implement this in
> ActiveResource ... if it''s still being developed.  I checked today
and
> ActiveResource hasn''t been touched in a very, very long time.
>
> It seems logical to expect methods to be able to act upon more than
> one object ... in a batch.  I cringe at the thought of iterating over
> every object in a collection just to do a batch update or create. 
I''d
> love to be able to upload an XML file to a RESTful URL and have it
> know whether it''s a single object or a collection of objects.  It
> seems to be that it would be as simple as determining whether the root
> entity was singular or plural:
>
This is pretty much the exact opposite direction that I instinctively  
head in.

I cringe at the thought of littering my controller methods with case/ 
if statements to cover the scenarios of getting "no id", "one
id",
"many ids".  It seems like a step backwards.

In my projects I completely sidestep the issues you guys have been  
having (i.e. calling POST, PUT, DELETE for a batch)  by treating the  
"subset" that I want to operate on as something at a different  
RESTful URL.

So rather than overloading the idea expressed by /comments with both  
"the collection of comments" and "a batch-subset of
comments" I would
have both /comments and /comments/batch - they are, after all, two  
different things.

Admittedly, I haven''t looked at ActiveResource in a while and I  
haven''t (yet) had to build anything beyond a toy ARes client.   
However, I don''t see *anything* missing on the server side when doing  
this in-browser.

Regards,
Trevor
> If I want to work with a single entity, I''d hit http:// 
> www.myapplication.com/people/
> with...
> <person>
>   <id>...</id>
>   ...
> </person>
>
> and if I want to work with more than one person, I''d hit the same
URL
> with...
> <people>
>   <person>
>     <id>...</id>
>     ...
>   </person>
>   <person>
>     <id>...</id>
>     ...
>   </person>
> </people>
>
> I''m trying to let a couple of applications talk together using
REST
> interfaces but, without this kind of functionality, it''s proving
to be
> very difficult.
>
> Am I thinking about this incorrectly or does something like this seem
> possible?
>
> Thanks,
> Chris
>
> On Feb 23, 9:57 pm, "Mike Garey"
<random...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> I used to be able to destroy multiple records in my restful  
>> controller
>> by using the following:
>>
>> in my view:
>>
>>   <%= form_tag product_path, :method => :delete %>
>>     <% for product in @products %>
>>       <td><%= product.title  %></td>
>>       <td><%= check_box_tag (''id[]'',
product.id) %></td>
>>     </tr>
>>     <% end %>
>> <%= end_form_tag %>
>>
>> and in my products_controller:
>>
>>   def destroy
>>     begin
>>       # params[:id] may either be a single id, or an array of
id''s
>>       @products = Product.find(params[:id])
>>     rescue
>>       logger.warn("ERROR: #{$!}")
>>     end
>>
>>     if @products and Product.destroy(@products)
>>       flash[:notice] = "Product successfully deleted"
>>     else
>>       flash[:warning] = "An error was encountered while attempting
to
>> delete the product(s)"
>>     end
>>   end
>>
>> however, after upgrading to the most recent edge rails (6207 as of
>> yesterday), this no longer works.. I get an error
>>
>> "product_url failed to generate from
{:controller=>"products",
>> :action=>"show"} - you may have ambiguous routes, or you
may need to
>> supply additional parameters for this route."
>>
>> I solved this by using the following:
>>
>> in routes.rb:
>>
>>   map.resources :products, :collection => {
>>     :delete => :delete
>>   }
>>
>> in my view:
>>
>>   <%= form_tag delete_products_path, :method => :delete %>
>>        blah blah...
>>   <%= end_form_tag %>
>>
>> and then I use the same code in my controller, however, I alias the
>> delete method to destroy by using the following in my controller:
>>
>>   alias delete destroy
>>
>> so am I bastardizing RESTful standards? I''m sure I am, but I
can''t
>> think of a better way around this.  If anyone else has any ideas,
>> please let us know!  Also, why was I previously able to do this using
>> the standard restful routes (ie multiple id''s could be passed
to an
>> action), but this no longer seems to be the case?
>>
>> Mike
>>
>> On 2/23/07, pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
<pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>>
>>
>>
>>> On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> just another hype/buzzword?
>>
>>>>> - I don''t think it makes sense to iterate several
emails in the
>>>>> browser to mark them unread (c''mon, one http
request for each
>>>>> mail,
>>>>> you gotta be kidding :-)
>>
>>>> I could go either way.  Iterating over them doesn''t
really seem
>>>> intolerable to me,
>>>> and treating them as individual is cleaner and more regular
than
>>>> somehow modifying multiples.
>>
>>> I grew up with 8 bit computers where people cared about resources.
>>> creating probably
>>> houndreds of http(s) requests to mark 250 spam email for deletion
is
>>> just so horrible
>>> that I must stop breathing... :-((
>
>
> 
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Trevor,

I can see the logic from both sides.  Conditionals do suck and, to
avoid them and really encapsulate the behavior, I think the code would
need to be within ActiveRecord itself (maybe not core ::Base but
perhaps in a plugin that modifies AR).  I''ve not had the time to study
all of the pertinent files and process flows but I think it can be
done without changing controller code too much.

Before I go any further, I may be totally wrong about how Rails is
doing some things behind the scenes because I''ve not had the time to
thoroughly study the behind-the-scenes code.  So, if I get something
wrong, just let me know. ;)

Given a RESTful URL, it seems logical to be able to POST/PUT
collections just like we do singular items.  Currently, if an XML file
reaches an action (e.g. create or update), it''s processed and
reconstituted as the ''params'' hash (see: param_parsers in
base.rb and
parsing logic within cgi_methods.rb -- both part of
ActionController).  The XML data is then accessible via
params[:xml_root][:some_key] (note: prior to Rails 1.1, the XML root
was not part of the params hash).  Anyways, this is great because,
whether our params hash was built from form parameters or a posted XML
file, our controllers can act on the params hash the same exact way
(for singular items):

(code taken from the AWDwR book)
# POST /articles
# POST /articles.xml
def create
  @article = Article.new(params[:article])
  ...
end

So, we''re just passing the params hash to the model for processing.
The conditional logic to support collections, at this point (not
taking ActiveRecord into account), would seem to be fairly easy:

(excuse the pseudo-code, it''s late and I don''t want to go api
hunting)
def create
  @articles = ( if params[:articles] exists, we process as a
collection of articles ... if not, we process as a singular article )
  ...
end

The conditional code may not even need to be in the controller.
Perhaps the heavy-lifting would be offloaded to the appropriate class
methods (e.g. Article.new()) in ActiveRecord.

I don''t know ... I may be thinking too simply but it seems like this
would be possible.  From there, the model would be responsible for
determining whether it was passed a singular item or a collection.

Anyways, I do want to look at all of the Rails code that''s involved in
this stuff and then try to take a whack at it.  I''m too tired to think
right now, so I''m going to cut this shorter than I had expected
(sorry).

-Chris


On Mar 6, 11:59 am, Trevor Squires
<tre...-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org>
wrote:
> Hi Chris,
>
> On 5-Mar-07, at 9:39 PM, Chris Grant wrote:
>
>
>
> > I''d be interested in seeing how DHH intends to implement this
in
> > ActiveResource ... if it''s still being developed.  I checked
today and
> > ActiveResource hasn''t been touched in a very, very long time.
>
> > It seems logical to expect methods to be able to act upon more than
> > one object ... in a batch.  I cringe at the thought of iterating over
> > every object in a collection just to do a batch update or create. 
I''d
> > love to be able to upload an XML file to a RESTful URL and have it
> > know whether it''s a single object or a collection of objects.
It
> > seems to be that it would be as simple as determining whether the root
> > entity was singular or plural:
>
> This is pretty much the exact opposite direction that I instinctively  
> head in.
>
> I cringe at the thought of littering my controller methods with case/
> if statements to cover the scenarios of getting "no id",
"one id",
> "many ids".  It seems like a step backwards.
>
> In my projects I completely sidestep the issues you guys have been  
> having (i.e. calling POST, PUT, DELETE for a batch)  by treating the  
> "subset" that I want to operate on as something at a different  
> RESTful URL.
>
> So rather than overloading the idea expressed by /comments with both  
> "the collection of comments" and "a batch-subset of
comments" I would
> have both /comments and /comments/batch - they are, after all, two  
> different things.
>
> Admittedly, I haven''t looked at ActiveResource in a while and I  
> haven''t (yet) had to build anything beyond a toy ARes client.  
> However, I don''t see *anything* missing on the server side when
doing
> this in-browser.
>
> Regards,
> Trevor
>
> > If I want to work with a single entity, I''d hit http://
> >www.myapplication.com/people/
> > with...
> > <person>
> >   <id>...</id>
> >   ...
> > </person>
>
> > and if I want to work with more than one person, I''d hit the
same URL
> > with...
> > <people>
> >   <person>
> >     <id>...</id>
> >     ...
> >   </person>
> >   <person>
> >     <id>...</id>
> >     ...
> >   </person>
> > </people>
>
> > I''m trying to let a couple of applications talk together
using REST
> > interfaces but, without this kind of functionality, it''s
proving to be
> > very difficult.
>
> > Am I thinking about this incorrectly or does something like this seem
> > possible?
>
> > Thanks,
> > Chris
>
> > On Feb 23, 9:57 pm, "Mike Garey"
<random...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> I used to be able to destroy multiple records in my restful  
> >> controller
> >> by using the following:
>
> >> in my view:
>
> >>   <%= form_tag product_path, :method => :delete %>
> >>     <% for product in @products %>
> >>       <td><%= product.title  %></td>
> >>       <td><%= check_box_tag (''id[]'',
product.id) %></td>
> >>     </tr>
> >>     <% end %>
> >> <%= end_form_tag %>
>
> >> and in my products_controller:
>
> >>   def destroy
> >>     begin
> >>       # params[:id] may either be a single id, or an array of
id''s
> >>       @products = Product.find(params[:id])
> >>     rescue
> >>       logger.warn("ERROR: #{$!}")
> >>     end
>
> >>     if @products and Product.destroy(@products)
> >>       flash[:notice] = "Product successfully deleted"
> >>     else
> >>       flash[:warning] = "An error was encountered while
attempting to
> >> delete the product(s)"
> >>     end
> >>   end
>
> >> however, after upgrading to the most recent edge rails (6207 as of
> >> yesterday), this no longer works.. I get an error
>
> >> "product_url failed to generate from
{:controller=>"products",
> >> :action=>"show"} - you may have ambiguous routes, or
you may need to
> >> supply additional parameters for this route."
>
> >> I solved this by using the following:
>
> >> in routes.rb:
>
> >>   map.resources :products, :collection => {
> >>     :delete => :delete
> >>   }
>
> >> in my view:
>
> >>   <%= form_tag delete_products_path, :method => :delete
%>
> >>        blah blah...
> >>   <%= end_form_tag %>
>
> >> and then I use the same code in my controller, however, I alias
the
> >> delete method to destroy by using the following in my controller:
>
> >>   alias delete destroy
>
> >> so am I bastardizing RESTful standards? I''m sure I am,
but I can''t
> >> think of a better way around this.  If anyone else has any ideas,
> >> please let us know!  Also, why was I previously able to do this
using
> >> the standard restful routes (ie multiple id''s could be
passed to an
> >> action), but this no longer seems to be the case?
>
> >> Mike
>
> >> On 2/23/07, pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
<pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>
> >>> On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>> just another hype/buzzword?
>
> >>>>> - I don''t think it makes sense to iterate
several emails in the
> >>>>> browser to mark them unread (c''mon, one http
request for each
> >>>>> mail,
> >>>>> you gotta be kidding :-)
>
> >>>> I could go either way.  Iterating over them
doesn''t really seem
> >>>> intolerable to me,
> >>>> and treating them as individual is cleaner and more
regular than
> >>>> somehow modifying multiples.
>
> >>> I grew up with 8 bit computers where people cared about
resources.
> >>> creating probably
> >>> houndreds of http(s) requests to mark 250 spam email for
deletion is
> >>> just so horrible
> >>> that I must stop breathing... :-((

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Chris,

comments inline:

On 7-Mar-07, at 1:10 AM, Chris Grant wrote:

<snip>
> Given a RESTful URL, it seems logical to be able to POST/PUT
> collections just like we do singular items.  Currently, if an XML file
> reaches an action (e.g. create or update), it''s processed and
> reconstituted as the ''params'' hash (see: param_parsers in
base.rb and
> parsing logic within cgi_methods.rb -- both part of
> ActionController).  The XML data is then accessible via
> params[:xml_root][:some_key] (note: prior to Rails 1.1, the XML root
> was not part of the params hash).  Anyways, this is great because,
> whether our params hash was built from form parameters or a posted XML
> file, our controllers can act on the params hash the same exact way
> (for singular items):
>
I agree, reconstitution as a params hash is desirable.  Careful about  
that "(for singular items)" thing - it''s not quite true, you
can have
multiple params and even though a param is a key/value pair, there''s  
nothing saying a ''value'' can''t be composite.

I''m pointing this out because I think you''re getting hung up
on
detecting when a given param is a single object or a list of  
objects.  See below:
> (code taken from the AWDwR book)
> # POST /articles
> # POST /articles.xml
> def create
>   @article = Article.new(params[:article])
>   ...
> end
>
> So, we''re just passing the params hash to the model for
processing.
> The conditional logic to support collections, at this point (not
> taking ActiveRecord into account), would seem to be fairly easy:
>
> (excuse the pseudo-code, it''s late and I don''t want to go
api hunting)
> def create
>   @articles = ( if params[:articles] exists, we process as a
> collection of articles ... if not, we process as a singular article )
>   ...
> end
Blech.  :-)

Even those who lines look ugly and you haven''t yet included results  
checking.
>
> The conditional code may not even need to be in the controller.
> Perhaps the heavy-lifting would be offloaded to the appropriate class
> methods (e.g. Article.new()) in ActiveRecord.
>
Article.new returns *one* Article so no, that''s not the place.

If you want to create a bunch of articles in one go, that''s something  
like Article.create_zero_or_more_from_this_hash.

But that method (when you give it an accurate name) looks pretty  
smelly and my personal preference is for classes to be really good at  
doing as little as possible.

So I''d create an ArticleBatch class that was really good at  
maintaining a list of Articles and would forward create/update/delete  
requests to each object it''s referencing.

And suddenly the whole need to detect a singular article vs many  
articles goes away - it''s not articles, it''s *one*
article_batch.

batch = ArticleBatch.new(params[:article_batch])
batch.can_save_all?
batch.errors
batch.save_all
batch.destroy_all
batch.each_article
batch.to_xml

So, if you review my previous mail - you have /articles and /articles/ 
batch (or /articles_batch - it doesn''t matter).

And you have controller methods (maybe in a different _controller.rb  
file, maybe not) that do *one* thing really well.

In the end it''s a matter of taste and smell.  I''ve seen people
complain about having to create extra classes for their RESTful nouns  
and I''ve seen people opine that REST breaks down a bit in more  
complicated systems because you''re trying to shoe-horn the concept  
(implying that noun classes will litter your project).

Hooey!   More classes (that are really good at *one* thing) will set  
you free. :-)

Give it a try, you may even end up saying "actually, I need an  
ArticleBatch and an ArticleFactory because handling both new and  
existing records leads to way too many conditionals".

HTH,
Trevor
> I don''t know ... I may be thinking too simply but it seems like
this
> would be possible.  From there, the model would be responsible for
> determining whether it was passed a singular item or a collection.
>
> Anyways, I do want to look at all of the Rails code that''s
involved in
> this stuff and then try to take a whack at it.  I''m too tired to
think
> right now, so I''m going to cut this shorter than I had expected
> (sorry).
>
> -Chris
>
>
> On Mar 6, 11:59 am, Trevor Squires
<tre...-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote:
>> Hi Chris,
>>
>> On 5-Mar-07, at 9:39 PM, Chris Grant wrote:
>>
>>
>>
>>> I''d be interested in seeing how DHH intends to implement
this in
>>> ActiveResource ... if it''s still being developed.  I
checked
>>> today and
>>> ActiveResource hasn''t been touched in a very, very long
time.
>>
>>> It seems logical to expect methods to be able to act upon more than
>>> one object ... in a batch.  I cringe at the thought of iterating  
>>> over
>>> every object in a collection just to do a batch update or  
>>> create.  I''d
>>> love to be able to upload an XML file to a RESTful URL and have it
>>> know whether it''s a single object or a collection of
objects.  It
>>> seems to be that it would be as simple as determining whether the  
>>> root
>>> entity was singular or plural:
>>
>> This is pretty much the exact opposite direction that I instinctively
>> head in.
>>
>> I cringe at the thought of littering my controller methods with case/
>> if statements to cover the scenarios of getting "no id",
"one id",
>> "many ids".  It seems like a step backwards.
>>
>> In my projects I completely sidestep the issues you guys have been
>> having (i.e. calling POST, PUT, DELETE for a batch)  by treating the
>> "subset" that I want to operate on as something at a
different
>> RESTful URL.
>>
>> So rather than overloading the idea expressed by /comments with both
>> "the collection of comments" and "a batch-subset of
comments" I would
>> have both /comments and /comments/batch - they are, after all, two
>> different things.
>>
>> Admittedly, I haven''t looked at ActiveResource in a while and
I
>> haven''t (yet) had to build anything beyond a toy ARes client.
>> However, I don''t see *anything* missing on the server side
when doing
>> this in-browser.
>>
>> Regards,
>> Trevor
>>
>>> If I want to work with a single entity, I''d hit http://
>>> www.myapplication.com/people/
>>> with...
>>> <person>
>>>   <id>...</id>
>>>   ...
>>> </person>
>>
>>> and if I want to work with more than one person, I''d hit
the same
>>> URL
>>> with...
>>> <people>
>>>   <person>
>>>     <id>...</id>
>>>     ...
>>>   </person>
>>>   <person>
>>>     <id>...</id>
>>>     ...
>>>   </person>
>>> </people>
>>
>>> I''m trying to let a couple of applications talk together
using REST
>>> interfaces but, without this kind of functionality, it''s
proving
>>> to be
>>> very difficult.
>>
>>> Am I thinking about this incorrectly or does something like this  
>>> seem
>>> possible?
>>
>>> Thanks,
>>> Chris
>>
>>> On Feb 23, 9:57 pm, "Mike Garey"
<random...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> I used to be able to destroy multiple records in my restful
>>>> controller
>>>> by using the following:
>>
>>>> in my view:
>>
>>>>   <%= form_tag product_path, :method => :delete %>
>>>>     <% for product in @products %>
>>>>       <td><%= product.title  %></td>
>>>>       <td><%= check_box_tag (''id[]'',
product.id) %></td>
>>>>     </tr>
>>>>     <% end %>
>>>> <%= end_form_tag %>
>>
>>>> and in my products_controller:
>>
>>>>   def destroy
>>>>     begin
>>>>       # params[:id] may either be a single id, or an array of
id''s
>>>>       @products = Product.find(params[:id])
>>>>     rescue
>>>>       logger.warn("ERROR: #{$!}")
>>>>     end
>>
>>>>     if @products and Product.destroy(@products)
>>>>       flash[:notice] = "Product successfully deleted"
>>>>     else
>>>>       flash[:warning] = "An error was encountered while  
>>>> attempting to
>>>> delete the product(s)"
>>>>     end
>>>>   end
>>
>>>> however, after upgrading to the most recent edge rails (6207 as
of
>>>> yesterday), this no longer works.. I get an error
>>
>>>> "product_url failed to generate from
{:controller=>"products",
>>>> :action=>"show"} - you may have ambiguous routes,
or you may
>>>> need to
>>>> supply additional parameters for this route."
>>
>>>> I solved this by using the following:
>>
>>>> in routes.rb:
>>
>>>>   map.resources :products, :collection => {
>>>>     :delete => :delete
>>>>   }
>>
>>>> in my view:
>>
>>>>   <%= form_tag delete_products_path, :method => :delete
%>
>>>>        blah blah...
>>>>   <%= end_form_tag %>
>>
>>>> and then I use the same code in my controller, however, I alias
the
>>>> delete method to destroy by using the following in my
controller:
>>
>>>>   alias delete destroy
>>
>>>> so am I bastardizing RESTful standards? I''m sure I am,
but I can''t
>>>> think of a better way around this.  If anyone else has any
ideas,
>>>> please let us know!  Also, why was I previously able to do this
>>>> using
>>>> the standard restful routes (ie multiple id''s could be
passed to an
>>>> action), but this no longer seems to be the case?
>>
>>>> Mike
>>
>>>> On 2/23/07, pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
<pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>>> wrote:
>>
>>>>> On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>> just another hype/buzzword?
>>
>>>>>>> - I don''t think it makes sense to iterate
several emails in the
>>>>>>> browser to mark them unread (c''mon, one
http request for each
>>>>>>> mail,
>>>>>>> you gotta be kidding :-)
>>
>>>>>> I could go either way.  Iterating over them
doesn''t really seem
>>>>>> intolerable to me,
>>>>>> and treating them as individual is cleaner and more
regular than
>>>>>> somehow modifying multiples.
>>
>>>>> I grew up with 8 bit computers where people cared about
resources.
>>>>> creating probably
>>>>> houndreds of http(s) requests to mark 250 spam email for  
>>>>> deletion is
>>>>> just so horrible
>>>>> that I must stop breathing... :-((
>
>
> 
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Yup, I like what you''ve got here, too.

Thanks for bringing up the ''singular item'' point, too.  I was
aware of
what you''re talking about but it''s good for others who may be
following along.

I like your abstraction of the batch functionalities into a dedicated
Batch class.  It makes sense, removes the need for conditionals strewn
throughout controller methods and is probably a lot easier to create
tests for.

I''m going to start working on the general case Batch class and see if
we can''t get something working.

Thanks for the thoughts!

-Chris

On Mar 7, 12:51 pm, Trevor Squires
<tre...-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org>
wrote:
> Hey Chris,
>
> comments inline:
>
> On 7-Mar-07, at 1:10 AM, Chris Grant wrote:
>
> <snip>
>
> > Given a RESTful URL, it seems logical to be able to POST/PUT
> > collections just like we do singular items.  Currently, if an XML file
> > reaches an action (e.g. create or update), it''s processed and
> > reconstituted as the ''params'' hash (see:
param_parsers in base.rb and
> > parsing logic within cgi_methods.rb -- both part of
> > ActionController).  The XML data is then accessible via
> > params[:xml_root][:some_key] (note: prior to Rails 1.1, the XML root
> > was not part of the params hash).  Anyways, this is great because,
> > whether our params hash was built from form parameters or a posted XML
> > file, our controllers can act on the params hash the same exact way
> > (for singular items):
>
> I agree, reconstitution as a params hash is desirable.  Careful about  
> that "(for singular items)" thing - it''s not quite true,
you can have
> multiple params and even though a param is a key/value pair,
there''s
> nothing saying a ''value'' can''t be composite.
>
> I''m pointing this out because I think you''re getting hung
up on
> detecting when a given param is a single object or a list of  
> objects.  See below:
>
>
>
> > (code taken from the AWDwR book)
> > # POST /articles
> > # POST /articles.xml
> > def create
> >   @article = Article.new(params[:article])
> >   ...
> > end
>
> > So, we''re just passing the params hash to the model for
processing.
> > The conditional logic to support collections, at this point (not
> > taking ActiveRecord into account), would seem to be fairly easy:
>
> > (excuse the pseudo-code, it''s late and I don''t want
to go api hunting)
> > def create
> >   @articles = ( if params[:articles] exists, we process as a
> > collection of articles ... if not, we process as a singular article )
> >   ...
> > end
>
> Blech.  :-)
>
> Even those who lines look ugly and you haven''t yet included
results
> checking.
>
>
>
> > The conditional code may not even need to be in the controller.
> > Perhaps the heavy-lifting would be offloaded to the appropriate class
> > methods (e.g. Article.new()) in ActiveRecord.
>
> Article.new returns *one* Article so no, that''s not the place.
>
> If you want to create a bunch of articles in one go, that''s
something
> like Article.create_zero_or_more_from_this_hash.
>
> But that method (when you give it an accurate name) looks pretty  
> smelly and my personal preference is for classes to be really good at  
> doing as little as possible.
>
> So I''d create an ArticleBatch class that was really good at  
> maintaining a list of Articles and would forward create/update/delete  
> requests to each object it''s referencing.
>
> And suddenly the whole need to detect a singular article vs many  
> articles goes away - it''s not articles, it''s *one*
article_batch.
>
> batch = ArticleBatch.new(params[:article_batch])
> batch.can_save_all?
> batch.errors
> batch.save_all
> batch.destroy_all
> batch.each_article
> batch.to_xml
>
> So, if you review my previous mail - you have /articles and /articles/
> batch (or /articles_batch - it doesn''t matter).
>
> And you have controller methods (maybe in a different _controller.rb  
> file, maybe not) that do *one* thing really well.
>
> In the end it''s a matter of taste and smell.  I''ve seen
people
> complain about having to create extra classes for their RESTful nouns  
> and I''ve seen people opine that REST breaks down a bit in more  
> complicated systems because you''re trying to shoe-horn the concept
> (implying that noun classes will litter your project).
>
> Hooey!   More classes (that are really good at *one* thing) will set  
> you free. :-)
>
> Give it a try, you may even end up saying "actually, I need an  
> ArticleBatch and an ArticleFactory because handling both new and  
> existing records leads to way too many conditionals".
>
> HTH,
> Trevor
>
> > I don''t know ... I may be thinking too simply but it seems
like this
> > would be possible.  From there, the model would be responsible for
> > determining whether it was passed a singular item or a collection.
>
> > Anyways, I do want to look at all of the Rails code that''s
involved in
> > this stuff and then try to take a whack at it.  I''m too tired
to think
> > right now, so I''m going to cut this shorter than I had
expected
> > (sorry).
>
> > -Chris
>
> > On Mar 6, 11:59 am, Trevor Squires
<tre...-k8q5a0yEZAgS+FvcfC7Uqw@public.gmane.org> wrote:
> >> Hi Chris,
>
> >> On 5-Mar-07, at 9:39 PM, Chris Grant wrote:
>
> >>> I''d be interested in seeing how DHH intends to
implement this in
> >>> ActiveResource ... if it''s still being developed.  I
checked
> >>> today and
> >>> ActiveResource hasn''t been touched in a very, very
long time.
>
> >>> It seems logical to expect methods to be able to act upon more
than
> >>> one object ... in a batch.  I cringe at the thought of
iterating
> >>> over
> >>> every object in a collection just to do a batch update or  
> >>> create.  I''d
> >>> love to be able to upload an XML file to a RESTful URL and
have it
> >>> know whether it''s a single object or a collection of
objects.  It
> >>> seems to be that it would be as simple as determining whether
the
> >>> root
> >>> entity was singular or plural:
>
> >> This is pretty much the exact opposite direction that I
instinctively
> >> head in.
>
> >> I cringe at the thought of littering my controller methods with
case/
> >> if statements to cover the scenarios of getting "no id",
"one id",
> >> "many ids".  It seems like a step backwards.
>
> >> In my projects I completely sidestep the issues you guys have been
> >> having (i.e. calling POST, PUT, DELETE for a batch)  by treating
the
> >> "subset" that I want to operate on as something at a
different
> >> RESTful URL.
>
> >> So rather than overloading the idea expressed by /comments with
both
> >> "the collection of comments" and "a batch-subset of
comments" I would
> >> have both /comments and /comments/batch - they are, after all, two
> >> different things.
>
> >> Admittedly, I haven''t looked at ActiveResource in a while
and I
> >> haven''t (yet) had to build anything beyond a toy ARes
client.
> >> However, I don''t see *anything* missing on the server
side when doing
> >> this in-browser.
>
> >> Regards,
> >> Trevor
>
> >>> If I want to work with a single entity, I''d hit
http://
> >>>www.myapplication.com/people/
> >>> with...
> >>> <person>
> >>>   <id>...</id>
> >>>   ...
> >>> </person>
>
> >>> and if I want to work with more than one person, I''d
hit the same
> >>> URL
> >>> with...
> >>> <people>
> >>>   <person>
> >>>     <id>...</id>
> >>>     ...
> >>>   </person>
> >>>   <person>
> >>>     <id>...</id>
> >>>     ...
> >>>   </person>
> >>> </people>
>
> >>> I''m trying to let a couple of applications talk
together using REST
> >>> interfaces but, without this kind of functionality,
it''s proving
> >>> to be
> >>> very difficult.
>
> >>> Am I thinking about this incorrectly or does something like
this
> >>> seem
> >>> possible?
>
> >>> Thanks,
> >>> Chris
>
> >>> On Feb 23, 9:57 pm, "Mike Garey"
<random...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>> I used to be able to destroy multiple records in my
restful
> >>>> controller
> >>>> by using the following:
>
> >>>> in my view:
>
> >>>>   <%= form_tag product_path, :method => :delete
%>
> >>>>     <% for product in @products %>
> >>>>       <td><%= product.title  %></td>
> >>>>       <td><%= check_box_tag
(''id[]'', product.id) %></td>
> >>>>     </tr>
> >>>>     <% end %>
> >>>> <%= end_form_tag %>
>
> >>>> and in my products_controller:
>
> >>>>   def destroy
> >>>>     begin
> >>>>       # params[:id] may either be a single id, or an array
of id''s
> >>>>       @products = Product.find(params[:id])
> >>>>     rescue
> >>>>       logger.warn("ERROR: #{$!}")
> >>>>     end
>
> >>>>     if @products and Product.destroy(@products)
> >>>>       flash[:notice] = "Product successfully
deleted"
> >>>>     else
> >>>>       flash[:warning] = "An error was encountered
while
> >>>> attempting to
> >>>> delete the product(s)"
> >>>>     end
> >>>>   end
>
> >>>> however, after upgrading to the most recent edge rails
(6207 as of
> >>>> yesterday), this no longer works.. I get an error
>
> >>>> "product_url failed to generate from
{:controller=>"products",
> >>>> :action=>"show"} - you may have ambiguous
routes, or you may
> >>>> need to
> >>>> supply additional parameters for this route."
>
> >>>> I solved this by using the following:
>
> >>>> in routes.rb:
>
> >>>>   map.resources :products, :collection => {
> >>>>     :delete => :delete
> >>>>   }
>
> >>>> in my view:
>
> >>>>   <%= form_tag delete_products_path, :method =>
:delete %>
> >>>>        blah blah...
> >>>>   <%= end_form_tag %>
>
> >>>> and then I use the same code in my controller, however, I
alias the
> >>>> delete method to destroy by using the following in my
controller:
>
> >>>>   alias delete destroy
>
> >>>> so am I bastardizing RESTful standards? I''m sure
I am, but I can''t
> >>>> think of a better way around this.  If anyone else has any
ideas,
> >>>> please let us know!  Also, why was I previously able to do
this
> >>>> using
> >>>> the standard restful routes (ie multiple id''s
could be passed to an
> >>>> action), but this no longer seems to be the case?
>
> >>>> Mike
>
> >>>> On 2/23/07,
pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
<pete4...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >>>> wrote:
>
> >>>>> On 15 Feb., 15:46, "monki"
<gee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>>>> just another hype/buzzword?
>
> >>>>>>> - I don''t think it makes sense to
iterate several emails in the
> >>>>>>> browser to mark them unread (c''mon,
one http request for each
> >>>>>>> mail,
> >>>>>>> you gotta be kidding :-)
>
> >>>>>> I could go either way.  Iterating over them
doesn''t really seem
> >>>>>> intolerable to me,
> >>>>>> and treating them as individual is cleaner and
more regular than
> >>>>>> somehow modifying multiples.
>
> >>>>> I grew up with 8 bit computers where people cared
about resources.
> >>>>> creating probably
> >>>>> houndreds of http(s) requests to mark 250 spam email
for
> >>>>> deletion is
> >>>>> just so horrible
> >>>>> that I must stop breathing... :-((

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---