Rails - Jul 2007 - What are the benefits of REST in plain English?

Can anyone explain the benefits of RESTful design so that a
non-programmer will understand? I can''t for the life of me understand
why I would want to go through all the trouble of limiting myself to
seven methods per controller or typing in arcane exceptions if I want to
use an eighth or ninth or tenth. It just seems to make more sense to
keep everything in one simple file.
-- 
Posted via http://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

Sean Colquhoun wrote:
> Can anyone explain the benefits of RESTful design so that a
> non-programmer will understand? I can''t for the life of me
understand
> why I would want to go through all the trouble of limiting myself to
> seven methods per controller or typing in arcane exceptions if I want to
> use an eighth or ninth or tenth. It just seems to make more sense to
> keep everything in one simple file.
I tried to get an answer to this a while ago.  No takers.  As near as I 
can see, there is only one significant benefit:  it makes it super easy 
to support a web service.  In other words, if you want to give some sort 
of access to your data to other websites/developers, then REST makes 
that fall-off-a-log easy to do.

Other than that, it seems like it''s just a more convoluted way to do
the
same old stuff.

My opinion is that DHH and others find the (somewhat forced) parallels 
between the (mostly unused) capabilities of HTTP protocol and CRUD to be 
"artistically pleasing".  This has, in my opinion, led them to break 
some of the rules found in the 37 signals book regarding feature-itis 
and fixing what ain''t broke.

OTOH, DHH and the rest of the Rails Core group were smart enough to 
create Rails in the first place and I was not, so I would certainly 
welcome some enlightenment on this issue.

cheers,
jp
-- 
Posted via http://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

Webservices are nice and all, but it''s not the reason why I use
map.resources. In fact most of the time I will not implement
webservices at all except for where I need them, since this is
additional code that might break and will probably be untested.
Besides all those respond_to blocks make controllers a pain to read.

The term REST has in the Rails world become almost synonymous with
map.resources, but it''s not, really. REST are web services,
map.resources is just a different way of organizing your controller,
and to me it makes perfect sense, so let me explain:

- you know where everything goes
Before REST came I (and pretty much everyone else) never really knew
where to put stuff. Say you have a Post model and a Comment model, for
comments there will only be add and delete, not the full set of CRUD
operations. Now you''re unsure, do I create two seperate controllers
for this or do I create just one? With map.resources the answer is
obvious, two models = two controllers. Without map.resources everyone
stuck to their personal preference, which ended up becoming a horrible
mess when collaborating with other people. Now this is just one
example, there are other such organizational things in controllers
that are made way easier by map.resources.

- all that hassle with GET and POST and GWR is finally gone.
Always needing to protect your methods from destructive GET requests
was a pain, and it was inelegant. Say you would have something like
''verify :method => :post, :redirect => blah'' in your
controller, now
that is just ugly. No such hassle with map.resources.

- No leeky URLs
Honestly, having a /person/create URL is stupid, and granted it was
possible to have /person/new be both form and post method, but that
led to some seriously ugly controller code.

- Prettier URLs
oh yes, they are prettier /person/1 tops /person/show/1 by miles imho,
and person/jncoward is waaay better than person/show/jncoward, no?

- Ability to selectively ''turn off'' controllers.
Need to disable a feature for a while? No problem, just comment out
the map.resources in your routes file and it''s dead and gone.

- Named routes mean none of that stupid curly bracket nonsense
Need to set the class for a link? So what looks better?

link_to @user.name, { :controller => ''person'', :action
=> ''show'', :id
=> @user }, { :class => ''delete'' }

or

link_to @user.name, user_path(@user), :class => ''delete''

hey or even:

link_to @user.name, @user, :class => ''delete''


There are probably some further reasons, this is what I came up with
off the top of my head. So give map.resources a spin, you''ll very
probably like it :P

/Jonas


On 27 Juli, 11:49, Jeff Pritchard
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Sean Colquhoun wrote:
> > Can anyone explain the benefits of RESTful design so that a
> > non-programmer will understand? I can''t for the life of me
understand
> > why I would want to go through all the trouble of limiting myself to
> > seven methods per controller or typing in arcane exceptions if I want
to
> > use an eighth or ninth or tenth. It just seems to make more sense to
> > keep everything in one simple file.
>
> I tried to get an answer to this a while ago.  No takers.  As near as I
> can see, there is only one significant benefit:  it makes it super easy
> to support a web service.  In other words, if you want to give some sort
> of access to your data to other websites/developers, then REST makes
> that fall-off-a-log easy to do.
>
> Other than that, it seems like it''s just a more convoluted way to
do the
> same old stuff.
>
> My opinion is that DHH and others find the (somewhat forced) parallels
> between the (mostly unused) capabilities of HTTP protocol and CRUD to be
> "artistically pleasing".  This has, in my opinion, led them to
break
> some of the rules found in the 37 signals book regarding feature-itis
> and fixing what ain''t broke.
>
> OTOH, DHH and the rest of the Rails Core group were smart enough to
> create Rails in the first place and I was not, so I would certainly
> welcome some enlightenment on this issue.
>
> cheers,
> jp
> --
> Posted viahttp://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

Hmm just realized that this was probably not so friendly to non-
programmers, but I suppose not so many of them will read this.

Also came up with another reason map.resources rocks:

- you don''t have to check for the existence of an ID.
what happen when someones enters /people/show or /people/edit? Why an
error of course! What happens when someone enters /people with
map.resources? It shows the index page.

On 27 Juli, 12:20, JN_Coward
<jonas.nick...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Webservices are nice and all, but it''s not the reason why I use
> map.resources. In fact most of the time I will not implement
> webservices at all except for where I need them, since this is
> additional code that might break and will probably be untested.
> Besides all those respond_to blocks make controllers a pain to read.
>
> The term REST has in the Rails world become almost synonymous with
> map.resources, but it''s not, really. REST are web services,
> map.resources is just a different way of organizing your controller,
> and to me it makes perfect sense, so let me explain:
>
> - you know where everything goes
> Before REST came I (and pretty much everyone else) never really knew
> where to put stuff. Say you have a Post model and a Comment model, for
> comments there will only be add and delete, not the full set of CRUD
> operations. Now you''re unsure, do I create two seperate
controllers
> for this or do I create just one? With map.resources the answer is
> obvious, two models = two controllers. Without map.resources everyone
> stuck to their personal preference, which ended up becoming a horrible
> mess when collaborating with other people. Now this is just one
> example, there are other such organizational things in controllers
> that are made way easier by map.resources.
>
> - all that hassle with GET and POST and GWR is finally gone.
> Always needing to protect your methods from destructive GET requests
> was a pain, and it was inelegant. Say you would have something like
> ''verify :method => :post, :redirect => blah'' in
your controller, now
> that is just ugly. No such hassle with map.resources.
>
> - No leeky URLs
> Honestly, having a /person/create URL is stupid, and granted it was
> possible to have /person/new be both form and post method, but that
> led to some seriously ugly controller code.
>
> - Prettier URLs
> oh yes, they are prettier /person/1 tops /person/show/1 by miles imho,
> and person/jncoward is waaay better than person/show/jncoward, no?
>
> - Ability to selectively ''turn off'' controllers.
> Need to disable a feature for a while? No problem, just comment out
> the map.resources in your routes file and it''s dead and gone.
>
> - Named routes mean none of that stupid curly bracket nonsense
> Need to set the class for a link? So what looks better?
>
> link_to @user.name, { :controller => ''person'', :action
=> ''show'', :id
> => @user }, { :class => ''delete'' }
>
> or
>
> link_to @user.name, user_path(@user), :class =>
''delete''
>
> hey or even:
>
> link_to @user.name, @user, :class => ''delete''
>
> There are probably some further reasons, this is what I came up with
> off the top of my head. So give map.resources a spin, you''ll very
> probably like it :P
>
> /Jonas
>
> On 27 Juli, 11:49, Jeff Pritchard
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> wrote:
>
> > Sean Colquhoun wrote:
> > > Can anyone explain the benefits of RESTful design so that a
> > > non-programmer will understand? I can''t for the life of
me understand
> > > why I would want to go through all the trouble of limiting myself
to
> > > seven methods per controller or typing in arcane exceptions if I
want to
> > > use an eighth or ninth or tenth. It just seems to make more sense
to
> > > keep everything in one simple file.
>
> > I tried to get an answer to this a while ago.  No takers.  As near as
I
> > can see, there is only one significant benefit:  it makes it super
easy
> > to support a web service.  In other words, if you want to give some
sort
> > of access to your data to other websites/developers, then REST makes
> > that fall-off-a-log easy to do.
>
> > Other than that, it seems like it''s just a more convoluted
way to do the
> > same old stuff.
>
> > My opinion is that DHH and others find the (somewhat forced) parallels
> > between the (mostly unused) capabilities of HTTP protocol and CRUD to
be
> > "artistically pleasing".  This has, in my opinion, led them
to break
> > some of the rules found in the 37 signals book regarding feature-itis
> > and fixing what ain''t broke.
>
> > OTOH, DHH and the rest of the Rails Core group were smart enough to
> > create Rails in the first place and I was not, so I would certainly
> > welcome some enlightenment on this issue.
>
> > cheers,
> > jp
> > --
> > Posted viahttp://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

> There are probably some further reasons, this is what I came up with
> off the top of my head. So give map.resources a spin, you''ll very
> probably like it :P
Don''t forget respond_to: one of the most elegant and RESTy things!
Straight from http://tinyurl.com/3bo9na :

== quote =Formats and respond_to

While respond_to has been with us since Rails 1.1, we''ve added a small
tweak in 1.2 that ends up making a big difference for immediate
usefulness of the feature. That is the magic of :format. All new
applications will have one additional default route: map.connect
'':controller/:action/:id.:format''. With this route installed,
imagine
the following example:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end
GET /weblog     # returns HTML from browser Accept header
GET /weblog.xml # returns the XML
GET /weblog.rss # returns the RSS
Using the Accept header to accomplish this is no longer necessary.
That makes everything a lot easier. You can explore your API in the
browser just by adding .xml to an URL. You don''t need a before_filter
to look for clues of a newsreader, just use .rss. And all of them
automatically works with page and action caching.

Of course, this format-goodness plays extra well together with
map.resources, which automatically makes sure everything Just Works.
The resource-scaffold generator even includes an example for this
using format.xml, so /posts/5.xml is automatically wired up. Very
nifty!

== end quote
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
-~----------~----~----~----~------~----~------~--~---

Sean,

you''re actually asking 2 questions in one.

The first, what are the benefits of REST (explained in a way non- 
programmers can understand).

Take a look at "How I explained REST to my Wife":

http://tomayko.com/articles/2004/12/12/rest-to-my-wife

The second part of your question is more about "how is splitting  
things up better than keeping things in one simple file?"

Unfortunately that''s much more difficult to explain in a way
that''s
meaningful to non-programmers.  That part of your question is more  
about "sound development practices" which can''t be considered
''rules''
because there''s so many damn exceptions.  So when you read this, bear  
in mind that there''s a tug-of-war going on between all the objectives  
you have.  Nothing is absolute.

But basically the issue is "one simple file".

You *could* write your rails app as having only one controller.  No  
views, no helpers, everything done in the controller.  Heck you could  
even write it as one *action* in one controller.  That''s one file,  
but I assure you, it would *not* be simple.

So you start to break it down into logical chunks.  You split things  
up according to MVC, asking questions like "does it makes sense for  
models to care about http requests?".  All along the way you are  
adding files (and classes).

As you do that, it might occur to you that *adding* classes  
(splitting your app into controllers or models or views) has actually  
reduced your complexity.  Eventually you may come to the conclusion  
that a lot of objects which do one thing really well, working  
together to complete a task, is a *heck* of a lot easier to manage  
than a few objects which are like swiss army knives.

Which leads us to how Rails does REST by default.  By using those 7  
controller methods as a threshold, it''s a great reminder to take a  
step back and ask: "hmm... am I reasonably separating my concerns by  
putting an add_tag action in my articles_controller?  How much  
simpler would things be if articles_controller didn''t care about
tags?".

You don''t *need* to subscribe to the whole RESTful or RAILSy way of  
doing things.  Plenty of great apps don''t.

But my advice to you is, if you don''t know enough to know the  
difference, then don''t fight it.  It''s encouraging you in the
direction of sound software development practices - pointing out ways  
where you might separate concerns in your domain logic.

  HTH,
Trevor

On 26-Jul-07, at 5:13 PM, Sean Colquhoun wrote:
>
> Can anyone explain the benefits of RESTful design so that a
> non-programmer will understand? I can''t for the life of me
understand
> why I would want to go through all the trouble of limiting myself to
> seven methods per controller or typing in arcane exceptions if I  
> want to
> use an eighth or ninth or tenth. It just seems to make more sense to
> keep everything in one simple file.
> -- 
> Posted via http://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

Sean Colquhoun wrote:
> Can anyone explain the benefits of RESTful design so that a
> non-programmer will understand? I can''t for the life of me
understand
> why I would want to go through all the trouble of limiting myself to
> seven methods per controller or typing in arcane exceptions if I want to
> use an eighth or ninth or tenth. It just seems to make more sense to
> keep everything in one simple file.
Actually the 7 methods per controller is a Rails implementation detail. 
There''s nothing about REST in general that prescribes this distinction.
Actually there''s nothing about REST that says you even have to use 
controllers. What REST does say is that you should model your 
application with a couple of things in mind. Off the top of my head I 
can think of:

- Everything is a resource, so every URL should point to some
"physical"
entity. This means there''s no "action" URL''s like
"subscribe" or "delete".
- The actions are moved to the HTTP methods GET, POST, PUT and DELETE 
(there''s a few more, but they''re not interesting in this
discussion). So
you''re limited to modelling your application with these actions.
- The client should track it''s own state. This means every request to 
the server can be handled in total isolation from everything else.
- GET requests must never alter the state of the application. No 
destructive or constructive GET requests.
- GET and PUT are idempotent, doing it once yields the same result as 
doing it multiple times.

What this means if that REST prescribes a way of thinking about and 
designing web applications. I think I read the expression "A straight 
jacket for your mind" somewhere. You may compare it to the opinionated 
ways of Rails, where model classes should be in this folder, the 
extension of your view file determines which renderer should render it, 
database tables must be pluralized, etc. So in the same way as Rails 
gives you a set of conventions to abide by in your code, REST gives you 
a set of conventions to abide by in the way you design your application 
from the users point of view, that is what entry points does the user 
have into the application and how is the user supposed to interact with 
the application. And this is probably the biggest reason why you would 
want to do REST. To have a set of conventions to guide you in your 
design, just like Rails guides you in your implementation.

-- 
Cheers,
- Jacob Atzen


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Jacob Atzen wrote:
...
What this means if that REST prescribes a way of thinking about and
designing web applications. I think I read the expression "A straight
jacket for your mind" somewhere. >
...
> --
> Cheers,
> - Jacob Atzen
First, let me admit that while I''ve read the REST stuff a couple of 
times and listened to DHH explain it, it has not intrigued me, so I 
haven''t tried to use it.  From the other responses to the OP''s
question,
it seems as if those who have tried it liked it.

Jacob''s reply has me wondering if the "straight jacket" that
REST
provides isn''t a matter of choosing whether to write "scaffolding
plus
CSS", or a rich internet app.  I very rarely use scaffolding for 
anything.  I tend to imagine a rich solution to the problem before me 
and cook up a solution with lots of ajaxy stuff sliding in and popping 
up where needed, etc.  I try to make my solution parallel the way a user 
would like to view the problem rather than having the organization of 
the data define the interface.  Jacob''s explanation brings about
notions
of a slightly prettied up scaffolding app.  A neat and tidy but rather 
limited and boring UI that seeks to enforce the organization of the data 
on the user rather than working on the data the way a user would want 
to.

Again, I speak from my imagination here.  I welcome enlightenment from 
anyone who has written a "fancy" app using REST techniques.

cheers,
jp
-- 
Posted via http://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

<...>
> A neat and tidy but rather
> limited and boring UI that seeks to enforce the organization of the data
> on the user rather than working on the data the way a user would want
> to.
<...>

REST has nothing to do with how nice or ugly UI is - it''s all up to
you.
Same goes for data organization - why should user care?


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
-~----------~----~----~----~------~----~------~--~---

On 27 Jul 2007, at 17:05, Jeff Pritchard wrote:
> Again, I speak from my imagination here.  I welcome enlightenment from
> anyone who has written a "fancy" app using REST techniques.
Would these qualify?

http://demo.placid.be/slideshows/54;manage
http://demo.placid.be/albums/51;manage
http://demo.placid.be/agendas/1;manage

All RESTful routes.

Your argument doesn''t add up for me. I like the way RESTful routes  
are defined, the way they behave and how much less code I have to  
write and maintain.


Best regards

Peter De Berdt


--~--~---------~--~----~------------~-------~--~----~
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 27 Jul 2007, at 17:13, Rimantas Liubertas wrote:
> REST has nothing to do with how nice or ugly UI is - it''s all up
to
> you.
> Same goes for data organization - why should user care?
Exactly, UI is view logic, has nothing to do with RESTful routes.


Best regards

Peter De Berdt


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Peter De Berdt wrote:
> On 27 Jul 2007, at 17:13, Rimantas Liubertas wrote:
> 
>> REST has nothing to do with how nice or ugly UI is - it''s all
up to
>> you.
>> Same goes for data organization - why should user care?
> 
> Exactly, UI is view logic, has nothing to do with RESTful routes.
> 
> 
> Best regards
> 
> Peter De Berdt
Peter, first let me just say that your work is very nice.  Also, it may 
be that this application might not benefit from anything beyond the CRUD 
you''ve provided (a regrettable name that isn''t fitting for
your very
nice site) and RESTful routes you''ve used to accomplish it.

As soon as you start using ajax you wind up with lots of additional 
controller stuff that doesn''t fit that pattern.  In some cases that is 
probably worthless fluff.  In others it can make a site more useful, and 
I try to limit my use of it to those situations.

In defense of my position, I never said "ugly", I said
"scaffolding plus
CSS, which probably should have been CRUD plus CSS.  Basic maintenance 
of the database (no matter how pretty) works well for some tasks, and 
not so well for others.  Some apps are more than just a "front end"
for
a set of tables in a database.  Such apps are not necessarily better, 
just different and require a different approach.

BTW, the statement "UI is view logic" seems somewhat oxymoronic to me.
I thought the goal was to limit how much logic one puts in the views. 
For me, that means lots of "additional" stuff winds up in the
controller
(and helpers).

I agree that a very CRUD centric RESTful app is probably much easier to 
write.  I plan force myself to find an appropriate part of an app to use 
this in so that I can learn more about RESTful routes.  Thanks for 
helping me learn more about REST.  I do believe it has it''s place now;
a
shift from my previous opinion.

cheers,
jp


-- 
Posted via http://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

Jeff Pritchard wrote:
> As soon as you start using ajax you wind up with lots of additional 
> controller stuff that doesn''t fit that pattern.  In some cases
that is
> probably worthless fluff.  In others it can make a site more useful, and 
> I try to limit my use of it to those situations.
> 
> In defense of my position, I never said "ugly", I said
"scaffolding plus
> CSS, which probably should have been CRUD plus CSS.  Basic maintenance 
> of the database (no matter how pretty) works well for some tasks, and 
> not so well for others.  Some apps are more than just a "front
end" for
> a set of tables in a database.  Such apps are not necessarily better, 
> just different and require a different approach.
> 
> BTW, the statement "UI is view logic" seems somewhat oxymoronic
to me.
> I thought the goal was to limit how much logic one puts in the views. 
> For me, that means lots of "additional" stuff winds up in the
controller
> (and helpers).
> 
> I agree that a very CRUD centric RESTful app is probably much easier to 
> write.  I plan force myself to find an appropriate part of an app to use 
> this in so that I can learn more about RESTful routes.  Thanks for 
> helping me learn more about REST.  I do believe it has it''s place
now; a
> shift from my previous opinion.
You might find Dave Thomas'' article on the RADAR architecture
inspiring.
He raises some of the same issues as you and provides a good description 
of the motivation for REST:

http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html

-- 
Cheers,
- Jacob Atzen

--~--~---------~--~----~------------~-------~--~----~
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''s all about design of your domain. Watch this

http://www.scribemedia.org/2006/07/09/dhh/

You won''t regret it.

-- 
MK

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Jacob Atzen wrote:
> Jeff Pritchard wrote:
>> just different and require a different approach.
>> shift from my previous opinion.
> You might find Dave Thomas'' article on the RADAR architecture
inspiring.
> He raises some of the same issues as you and provides a good description
> of the motivation for REST:
> 
> http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html
> 
> --
> Cheers,
> - Jacob Atzen
Thanks Jacob, this was brilliant!  I think I''m going to build my next 
Rails app that way.  Best of both worlds, worst of neither.  Thanks very 
much for pointing me to this excellent article.

jp
-- 
Posted via http://www.ruby-forum.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
-~----------~----~----~----~------~----~------~--~---

I think this bit is wrong...
> - all that hassle with GET and POST and GWR is finally gone.
> Always needing to protect your methods from destructive GET requests
> was a pain, and it was inelegant. Say you would have something like
> ''verify :method => :post, :redirect => blah'' in
your controller, now
> that is just ugly. No such hassle with map.resources.
even the default routes.rb still has

  map.connect '':controller/:action/:id''

and as long as it does you can access any controller action with a
GET, and yes you can then delete something with a GET.
So I still have verify :method => :put, or :delete or :post in all my
controllers, it is just safer that way.



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

wolfmanjm,

there is nothing stopping you from removing the map.connect statement.
In fact, I allways get rid of all the junk in routes.rb. If you do
that (and if you''re really using REST you should) then no, that bit is
not wrong, since map.resources will only expose those actions for PUT,
POST and DELETE requests. After all, they have the same URL. In that
case the verify statement is not safer at all, it is only redundant.

/Jonas


On 29 Juli, 14:35, wolfmanjm
<wolfma...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I think this bit is wrong...
>
> > - all that hassle with GET and POST and GWR is finally gone.
> > Always needing to protect your methods from destructive GET requests
> > was a pain, and it was inelegant. Say you would have something like
> > ''verify :method => :post, :redirect => blah''
in your controller, now
> > that is just ugly. No such hassle with map.resources.
>
> even the default routes.rb still has
>
>   map.connect '':controller/:action/:id''
>
> and as long as it does you can access any controller action with a
> GET, and yes you can then delete something with a GET.
> So I still have verify :method => :put, or :delete or :post in all my
> controllers, it is just safer that way.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---