Forum: Ruby on Rails under MVC, business rules belong in the __________

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Phlip (Guest)
on 2009-05-27 17:23
(Received via mailing list)
Railsters:

I heard a rumor that the incorrect answer, "Controller", was in
circulation out
there.

The C should be as thin as possible, like a telephone patch-board. The
View
should be thick, but only with Viewey things.

The Model should be as fat as possible. Anything a user can do to the
biz rules,
thru the View, unit test can do to the Model directly.

So the question is: Where did this disinformation come from? Do any
websites (or
 >cough< books) out there actually say the biz rules belong in the
controller?

--
   Phlip
Robert W. (Guest)
on 2009-05-27 18:34
Phlip wrote:
> Railsters:
>
> I heard a rumor that the incorrect answer, "Controller", was in
> circulation out
> there.

Where did you hear this rumor? At least within the Rails circles I'm
aware of thin controllers and fat models are the mantra.

> The C should be as thin as possible, like a telephone patch-board. The
> View
> should be thick, but only with Viewey things.
>
> The Model should be as fat as possible. Anything a user can do to the
> biz rules,
> thru the View, unit test can do to the Model directly.

In the context of Rails' MVC this is what's generally promoted. However,
Rails is not the only application of MVC out there and it certainly
wasn't invented along with Rails.

For example: I also work with the Mac OS X Cocoa framework, which is
also very much MVC based. However, it's very common to have fat
controllers. This is not a problem, and is highly promoted. The reason
for this is that controllers in Cocoa serve a somewhat different role in
the design of Cocoa based desktop applications. They are often used as
delegates for windows, views, persistency related objects, etc. They are
often used for handing notifications that are broadcast between objects,
and there are many other uses for them. There's nothing wrong with this
and it doesn't "break" MVC or anything else. It's just a different
approach that makes sense in it's own right.

> So the question is: Where did this disinformation come from? Do any
> websites (or
>  >cough< books) out there actually say the biz rules belong in the
> controller?

I can't answer that, because I've not heard these rumors you speak of.
Rick D. (Guest)
on 2009-05-28 17:57
(Received via mailing list)
On Wed, May 27, 2009 at 10:34 AM, Robert W.
<removed_email_address@domain.invalid> wrote:
>
> Phlip wrote:
>> Railsters:
>>
>> I heard a rumor that the incorrect answer, "Controller", was in
>> circulation out
>> there.
>
> Where did you hear this rumor? At least within the Rails circles I'm
> aware of thin controllers and fat models are the mantra.

Thin controllers.
Fat models
Dumb views

Although as I type this maybe Thick as a synonym for Dumb might be a
better fit with the other two. <G>

And to drive the point home:
http://www.railsenvy.com/2008/6/3/mvc-videos
--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Jeff S. (Guest)
on 2009-05-28 18:20
(Received via mailing list)
Phlip wrote:
> Railsters:
>
> I heard a rumor that the incorrect answer, "Controller", was in circulation out
> there.

That's how I was taught MVC, long before I'd heard of Ruby:  Models do
some basic checking, but business logic belongs in the controller.  That
was the point of the controller; it gave a central place to put business
logic.

> The C should be as thin as possible, like a telephone patch-board. The View
> should be thick, but only with Viewey things.

That's the Rails take.  Rails munges terminology a little.  Rails models
do a lot of what used to be done by controllers.  I'm not saying it's a
bad thing, but MVC far predates Ruby, and supposed "best practices"
change over time.

> The Model should be as fat as possible. Anything a user can do to the biz rules,
> thru the View, unit test can do to the Model directly.

That's not necessarily true.

> So the question is: Where did this disinformation come from? Do any websites (or
>  >cough< books) out there actually say the biz rules belong in the controller?

I first used MVC with MFC, about 10+ years ago, and in Java shortly
thereafter.  Fat controllers may have been advocated by MS back then.
Rick D. (Guest)
on 2009-05-28 18:55
(Received via mailing list)
On Thu, May 28, 2009 at 10:17 AM, Jeff S. <removed_email_address@domain.invalid>
wrote:
> logic.
Well that's not the original intention of Trygve Reenskaug when he
conceived of MVC:

 http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

Trygve's original goal was separating UI logic from domain logic (what
we commonly cause Business logic).  The Model holds the domain
information and methods for processing it.

The View is concerned only with presenting the view to the user, a
model might have multiple views presenting different subsets and/or
projections of the model.

The Controller deals with communicating with the user, it processes
user input, and decides which views should be rendered and where.

So the Rails notion of MVC seems very similar to this 1979 version.
Controllers process user input and decide which view to render, Views
do the rendering, and Models do the heavy application lifting.

Subsequent variations of MVC, particularly those which piled
application logic into the controller are perversions of the original
idea.

Note also that Reenskaug talks about Editors which are objects which
are associated with a view and are temporarily interposed between a
controller and a view.  I think if you squint just a little bit you
can see the seeds of what Rails developers now refer to as a
Presenter.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Jeff S. (Guest)
on 2009-05-28 19:30
(Received via mailing list)
Rick DeNatale wrote:
>
> Well that's not the original intention of Trygve Reenskaug when he
> conceived of MVC:
>
>  http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

Thanks, I'll read that as soon as I have a chance.

> Trygve's original goal was separating UI logic from domain logic (what
> we commonly cause Business logic).  The Model holds the domain
> information and methods for processing it.
>
> The View is concerned only with presenting the view to the user, a
> model might have multiple views presenting different subsets and/or
> projections of the model.
>
> The Controller deals with communicating with the user, it processes
> user input, and decides which views should be rendered and where.

That's different from any form of MVC I've ever heard of, including
Rails.  Ordinarily, the views define the UI, and the Controller exists
strictly behind the scenes, as implementation details.

> So the Rails notion of MVC seems very similar to this 1979 version.
> Controllers process user input and decide which view to render, Views
> do the rendering, and Models do the heavy application lifting.

That's not how Rails works.  You're mostly right about the Models, but
the controllers are, as Phlip suggested, just "patch boards," not for
user input.  Sometimes a savvy user can send HTTP requests to a Rails
application without going through any view, but that's not the intent.

One piece of "heavy lifting" still done by the controllers is access
control; Models know how to answer questions, and don't intrinsically
care who's asking.  It's up to the Controllers to determine who gets to
see what.

> Subsequent variations of MVC, particularly those which piled
> application logic into the controller are perversions of the original
> idea.

"Perversions."  You know, there are ways of making a point that don't
involve blanket insults of everyone who disagrees with you.

> Note also that Reenskaug talks about Editors which are objects which
> are associated with a view and are temporarily interposed between a
> controller and a view.  I think if you squint just a little bit you
> can see the seeds of what Rails developers now refer to as a
> Presenter.

I'll have to look up Presenter.
p_W (Guest)
on 2009-05-28 22:15
(Received via mailing list)
I didn't read it as an insult...according to the dictionary:

    'perversions: a perverted form of something'
    'perverted: turned from what is right; misguided; distorted.'

Then every MVC implementation that differs from the original is indeed
'distorted' and therefore 'perverted'

Do we really need to try and interpret everything as flamebait?
Brian (Guest)
on 2009-05-28 22:57
(Received via mailing list)
On May 28, 11:29 am, Jeff S. <removed_email_address@domain.invalid> wrote:
> That's not how Rails works.  You're mostly right about the Models, but
> the controllers are, as Phlip suggested, just "patch boards," not for
> user input.  Sometimes a savvy user can send HTTP requests to a Rails
> application without going through any view, but that's not the intent.
>


I'm new to both rails and MVC, so please correct me if I
misunderstand.  But it seems that controllers DO handle user input for
the typical web application.  A view helps a user format that input,
but it can't receive anything.  In fact, I could just send an http
request to a rails application before ever interacting with UI.  The
controller is what processes this request, consulting models if
necessary.  The view isn't involved until the application tries to
send information back to me.
Jeff S. (Guest)
on 2009-05-29 01:54
(Received via mailing list)
Brian wrote:
> I'm new to both rails and MVC, so please correct me if I
> misunderstand.  But it seems that controllers DO handle user input for
> the typical web application.  A view helps a user format that input,
> but it can't receive anything.  In fact, I could just send an http
> request to a rails application before ever interacting with UI.  The
> controller is what processes this request, consulting models if
> necessary.  The view isn't involved until the application tries to
> send information back to me.

You could, but you ordinarily don't.  A user typically deals with a web
page, entering information in (e.g.) a styled form.  The controller only
deals with "input" in the sense of HTTP requests, and it doesn't know
whether they come directly from some hacker, or from an XMLHttpRequest
object in some Ajax application.  In such a case, btw, the Controller
sends back XML directly, without going through the view; so, if we're
going to take the stance that Controllers deal with input directly, then
we also have to see them as providing output directly.  It makes more
sense, IMO, to see the View as defining the UI, and the Controller as an
implementation detail.
Jeff S. (Guest)
on 2009-05-29 02:01
(Received via mailing list)
p_W wrote:
> I didn't read it as an insult...according to the dictionary:
>
>     'perversions: a perverted form of something'
>     'perverted: turned from what is right; misguided; distorted.'
>
> Then every MVC implementation that differs from the original is indeed
> 'distorted' and therefore 'perverted'

"Perversion" is an extremely derogatory term.  That connotation may not
be expressed by your dictionary, but I assure you, "perverse" is a very
nasty way of referring to something, and implies strong disapproval.
The most common use of the word is probably in relation to sex crimes.
It's just not a nice thing to say.  That doesn't mean Ron hasn't got the
right to say it, especially if it accurately expresses his opinion;
however, it's not something that ordinarily comes up in civil discourse.

> Do we really need to try and interpret everything as flamebait?

Do we really need to turn every intellectual debate into a struggle for
personal superiority?  It's silly.  If I told my coworkers their
opinions were "perverse," I wouldn't have coworkers anymore.
Michael S. (Guest)
on 2009-05-29 02:25
(Received via mailing list)
On Thursday 28 May 2009, Jeff S. wrote:
> Phlip wrote:
> > Railsters:
> >
> > I heard a rumor that the incorrect answer, "Controller", was in
> > circulation out there.
>
> That's how I was taught MVC, long before I'd heard of Ruby:  Models
> do some basic checking, but business logic belongs in the controller.
>  That was the point of the controller; it gave a central place to put
> business logic.

That sounds more like Jacobson's Entity-Boundary-Control. Is there a
chance you're thinking of that?

Michael

--
Michael S.
mailto:removed_email_address@domain.invalid
http://www.schuerig.de/michael/
Hassan S. (Guest)
on 2009-05-29 02:33
(Received via mailing list)
On Thu, May 28, 2009 at 2:57 PM, Jeff S. <removed_email_address@domain.invalid>
wrote:

> "Perversion" is an extremely derogatory term.  That connotation may not
> be expressed by your dictionary, but I assure you, "perverse" is a very
> nasty way of referring to something, and implies strong disapproval.

I'd suggest it's a serious mistake to assume your odd point of view --
which doesn't match up with either the m-w.com dictionary, or my own
experience -- is shared by the majority.

Your assurances notwithstanding :-)

--
Hassan S. ------------------------ removed_email_address@domain.invalid
Jeff S. (Guest)
on 2009-05-29 02:52
(Received via mailing list)
Michael S. wrote:
>
> That sounds more like Jacobson's Entity-Boundary-Control. Is there a
> chance you're thinking of that?

No, what I'm describing was a dominant view of MVC in the late 90's.  Of
course, that doesn't make it right, and maybe it should have been called
Entity-Boundary-Control.  Thanks for giving me something to Google.
Rick D. (Guest)
on 2009-05-29 04:05
(Received via mailing list)
On Thu, May 28, 2009 at 11:29 AM, Jeff S. <removed_email_address@domain.invalid>
wrote:
>
> Rick DeNatale wrote:

> That's different from any form of MVC I've ever heard of, including
> Rails.  Ordinarily, the views define the UI, and the Controller exists
> strictly behind the scenes, as implementation details.

By UI I mean both output and input. And the Controller and View are
both involved.

>> So the Rails notion of MVC seems very similar to this 1979 version.
>> Controllers process user input and decide which view to render, Views
>> do the rendering, and Models do the heavy application lifting.
>
> That's not how Rails works.  You're mostly right about the Models, but
> the controllers are, as Phlip suggested, just "patch boards," not for
> user input.  Sometimes a savvy user can send HTTP requests to a Rails
> application without going through any view, but that's not the intent.

No, I really understand how Rails, HTTP browsers work, and I maintain
that controllers handle input and decide how to change what the user
sees in response.  This is partially in response to a later response
you made to Brian.

if we step back and see how the user interacts with a web application
through a browser, the first step is to make the initial request by
getting the browser to send an http request to the app. This happens
when he does something like typing a url into the address bar, or
following a link.

The http request, typically a get here is the input I'm talking about.
 That input in the form of a request is routed to a controller, which
typically interacts with one or more models, then renders something.
That something is typically an html page from a rendered view, but
could also be json, javascript, or a partial dom replacement for an
ajax call, often view are involved in the rendering of this response.

The only thing that views have to do with input is to provide
affordances by which the user may cause additional input requests to
happen, whether they be links, buttons which generate ajax requests,
etc. but the input is processed by the controller in the web
application.

> One piece of "heavy lifting" still done by the controllers is access
> control; Models know how to answer questions, and don't intrinsically
> care who's asking.  It's up to the Controllers to determine who gets to
> see what.

Only in the simplest of access control. Usually there's model
involvement here as well, although it's often not obvious because the
controller interaction with the security model objects is done in
before filters.

>> Subsequent variations of MVC, particularly those which piled
>> application logic into the controller are perversions of the original
>> idea.
>
> "Perversions."  You know, there are ways of making a point that don't
> involve blanket insults of everyone who disagrees with you.

As others have pointed out, you are over reacting to the word. The
intention here was in the same sense as "a perversion of justice". No
insult was intended.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Phlip (Guest)
on 2009-05-29 07:47
(Received via mailing list)
Brian wrote:

> I'm new to both rails and MVC, so please correct me if I
> misunderstand.  But it seems that controllers DO handle user input for
> the typical web application.  A view helps a user format that input,
> but it can't receive anything.  In fact, I could just send an http
> request to a rails application before ever interacting with UI.  The
> controller is what processes this request, consulting models if
> necessary.  The view isn't involved until the application tries to
> send information back to me.

Regardless of the direction data travels, a controller should dispatch
to the
view or model as soon as possible. For example...

   Model.create! params[:model]

That common idiom passes <form> parameters directly into the createe, in
the
model. This might look like a violation of the rule "no view data
leaking into
the model", where the params[] are indeed CGI Query details wrapped up
in a
convenient package, but note that params[:model] should only contain
data
primitives - strings and strung integers.

In real life coding, actions can get thick. They might need to use lots
of if
statements to triage input, for example. The rule "all biz logic in the
model"
is not a rule, it is a goal. The closer you get to it, and the more
often you
refactor a design towards that goal, the better.

--
   Phlip
Phlip (Guest)
on 2009-05-29 07:50
(Received via mailing list)
>>> Subsequent variations of MVC, particularly those which piled
>>> application logic into the controller are perversions of the original
>>> idea.

>> "Perversions."  You know, there are ways of making a point that don't
>> involve blanket insults of everyone who disagrees with you.

Mr. Manners reminds the Gentle Poster(s) that the early 1980s were,
indeed,
quite perverse...

--
   Phlip
Phlip (Guest)
on 2009-05-29 08:04
(Received via mailing list)
Jeff S. wrote:

> That's how I was taught MVC, long before I'd heard of Ruby:  Models do
> some basic checking, but business logic belongs in the controller.  That
> was the point of the controller; it gave a central place to put business
> logic.

Could you cite? It's flat-out wrong, and a friend of mine seems to have
flubbed
an interview by stating the correct answer.

The Model should store things your boss says, like "client X can handle
Visas
and Mastercards, but client Y can handle only Visas". Business rules.

Because controllers are busy controlling, you can't refactor the crap
out of
them, to leverage tricks like inheritance. X could inherit Y, and add
Mastercard
handling. (Please note that's a contrived example that would not
withstand even
cursory domain-driven analysis!;)

Models have only one predefined role - persistence into a database - so
they are
free to otherwise refactor their logic around until it's DRY. If you
wrote a
non-trivial Rails app without this refactoring and designing, your
controllers
are going to rapidly devolve into unmanageable brambles of tangled
thorny logic...

In a system where the controllers are not so constrained (CGI, Ajax,
HTTP, etc.)
they are free to refactor into more subtle designs. Some projects, using
other
platforms, could conceivably store lots of business rules in objects
that also
control. That still does not mean it's a good idea.

>> The Model should be as fat as possible. Anything a user can do to the biz rules,
>> thru the View, unit test can do to the Model directly.
>
> That's not necessarily true.

That is extremely necessarily true. Defining designs in terms of how to
test-drive their creation is a simple but powerful way to explain
generic design
guidelines. Think, for example, of the tests required to generate one of
the
designs in the book /Design Patterns/.

When you are writing an application, you should respond to the business
rules in
your requirements by TDDing them into your models first, then wiring
them up to
your Views. There's simply no counter-example for this practice.

>> So the question is: Where did this disinformation come from? Do any websites (or
>>  >cough< books) out there actually say the biz rules belong in the controller?
>
> I first used MVC with MFC, about 10+ years ago, and in Java shortly
> thereafter.  Fat controllers may have been advocated by MS back then.

MFC exploits "vendor lock-in" by tempting you with a wizard. I suspect
Rails is
an example of a competing platform that simply doesn't need one! Beyond
script/generate...

--
   Phlip
Phlip (Guest)
on 2009-05-29 08:26
(Received via mailing list)
Phlip wrote:

> Regardless of the direction data travels

travel.

<voice size='tiny'> sorry </voice>
Jeff S. (Guest)
on 2009-05-29 16:08
(Received via mailing list)
Phlip wrote:
> Jeff S. wrote:
>
>> That's how I was taught MVC, long before I'd heard of Ruby:  Models do
>> some basic checking, but business logic belongs in the controller.  That
>> was the point of the controller; it gave a central place to put business
>> logic.
>
> Could you cite?

No; as I say, this was 10+ years ago.  Again, I'm not arguing what it
"should be," nor what it "originally was;" however, I am telling you
that a lot professional engineers, including me, were originally taught
that business logic belonged in controllers.  When I first learned of
MVC, I was undergraduate student, not an expert on OOD.  I don't code my
Rails apps with thick Controllers, but I am bothered by this cult-like
adherence to some One True Way of Agile programming.  We're going to end
up with a lot of bad software and lousy developers.

>>> The Model should be as fat as possible. Anything a user can do to the biz rules,
>>> thru the View, unit test can do to the Model directly.
>> That's not necessarily true.
>
> That is extremely necessarily true.

"This is widely considered a good idea" != "This is necessarily true"

> Defining designs in terms of how to
> test-drive their creation is a simple but powerful way to explain generic design
> guidelines. Think, for example, of the tests required to generate one of the
> designs in the book /Design Patterns/.

Whether TDD is a good idea has nothing to do with how functionality
should be apportioned among Model, View, and Controller.  In particular,
Controllers need tests of their own, no matter how much functionality
you stick in the Models.  (Unless you're going for only a Model/View
paradigm, as some would argue Java Swing uses.)

> When you are writing an application, you should respond to the business rules in
> your requirements by TDDing them into your models first, then wiring them up to
> your Views. There's simply no counter-example for this practice.

I believe you've been misled, and that you are mistaken.  I'm not sure
how else to say that, nor do I have any interest in arguing with a
zealot who makes such absolutisms.

>>> So the question is: Where did this disinformation come from? Do any websites (or
>>>  >cough< books) out there actually say the biz rules belong in the controller?
>> I first used MVC with MFC, about 10+ years ago, and in Java shortly
>> thereafter.  Fat controllers may have been advocated by MS back then.
>
> MFC exploits "vendor lock-in" by tempting you with a wizard. I suspect Rails is
> an example of a competing platform that simply doesn't need one! Beyond
> script/generate...

Rails is more "wizard" driven than MFC ever was, with scripts to
generate just about everything.  MFC was that way because it was meant
to encourage consistent look and feel among applications; Rails is that
way because it relies heavily on conventions to work properly.  If you
really want to pick an "our way or the highway" development framework,
take a look at Cocoa.
Robert W. (Guest)
on 2009-05-29 17:21
Jeff S. wrote:

> take a look at Cocoa.

Which, by the way, is probably the most brilliantly conceived
event-driven MVC framework I've ever had the pleasure of using. The very
fact that you play by it's rules by doing things "it's way" is much of
what makes it so.
Robert W. (Guest)
on 2009-05-29 17:24
Robert W. wrote:
> Jeff S. wrote:
>
>> take a look at Cocoa.
>
> Which, by the way, is probably the most brilliantly conceived
> event-driven MVC framework I've ever had the pleasure of using. The very
> fact that you play by it's rules by doing things "it's way" is much of
> what makes it so.

Correction: "its rules" and "its way." Sorry for the misuse of the
apostrophe.
Jeff S. (Guest)
on 2009-05-29 18:41
(Received via mailing list)
Robert W. wrote:
> Jeff S. wrote:
>
>> take a look at Cocoa.
>
> Which, by the way, is probably the most brilliantly conceived
> event-driven MVC framework I've ever had the pleasure of using. The very
> fact that you play by it's rules by doing things "it's way" is much of
> what makes it so.

Mostly agreed.  It's very much like Rails, or C++ template
metaprogramming, in the sense that convention is leveraged to define
program structure.  Restrictions aren't necessarily a bad thing.  The
one aspect of Cocoa development that does really bother me is that it's
only really meant to be done in XCode, with which I am not thrilled.
Jim (Guest)
on 2009-05-29 21:03
(Received via mailing list)
On May 29, 10:40 am, Jeff S. <removed_email_address@domain.invalid> wrote:

> program structure.  Restrictions aren't necessarily a bad thing.  The
> one aspect of Cocoa development that does really bother me is that it's
> only really meant to be done in XCode, with which I am not thrilled.

You can do Cocoa development in any editor you wish to use.  I edit
code in TextMate, and only use Xcode to manage the project overall,
open the xibs in Interface Builder, etc.  It would be easily possible
for anyone else to build an IDE for developing with Cocoa.  The
problem is that Xcode doesn't suck too bad, and it's free, so it would
be difficult to sell another IDE to support the development costs.
Several years ago, Codewarrior supported Cocoa development.  As Xcode
was improved more and more, less and less people bought and upgraded
CW and therefore it eventually went away, unable to compete with
Apple's free offering.

Cocoa also doesn't lock you into following strict MVC.  In fact, it's
even easier than Rails to merge model logic into the controller.  It's
also even easier than Rails to end up with what should be view code in
the controller.  In fact, simple apps may end up almost entirely
contained within a single controller if you're not careful.

Jim
Robert W. (Guest)
on 2009-05-29 22:20
Jeff S. wrote:
> Robert W. wrote:
> Mostly agreed.  It's very much like Rails, or C++ template

This seems to me to be a gross oversimplification. While there may be
some similarities, in that they both implement the basic MVC design
pattern, Cocoa development involves design patterns that are rarely seen
in Rails, or any other web framework. Patterns such as chain of
responsibility, decorator/delegation, command, composite/view hierarchy,
key value code/key value observing.

My only real point here is that any similarities with Rails falls away
very quickly when you get into the inner workings of the Cocoa
framework.

> metaprogramming, in the sense that convention is leveraged to define
> program structure.  Restrictions aren't necessarily a bad thing.  The
> one aspect of Cocoa development that does really bother me is that it's
> only really meant to be done in XCode, with which I am not thrilled.

I do admit that Xcode's text editor could use some work. However, I'd
rather use Xcode's integrated editor over many of the other IDEs I've
used like Eclipse, NetBeans, JDeveloper, etc.

However, as Jim stated, you don't have to use it. You can use whatever
editor you want.

The fact is though, that there is much more focus placed on features for
dealing with the complexities of desktop application development, which
don't apply to web based frameworks like Rails. All you really need to
develop a Rails application is a text editor and a command line. Xcode
is, by necessity, much more that a simple text editor.
This topic is locked and can not be replied to.