On Tuesday 27 December 2005 02:05 pm, J. Ryan Sobol wrote:
> On Dec 27, 2005, at 1:01 PM, Steve Litt wrote:
> > I have a big problem with a few sentences in the preceding URL. Or
> > at least as
> > I understand them. They seem to be advocating getting rid of config
> > files and
> > putting all logic in code, at least my reading of the following
> > quotes:
> >
> > ============================================
> > "A full Rails application probably has less total code than the XML
> > you'd need
> > to configure the same application in other frameworks."
> >
> > "Rails strives to honor the Pragmatic Programmer's DRY Principle by
> > avoiding
> > the extra work of configuration files and code annotations. You can
> > develop
> > in real-time: make a change, and watch it work immediately.
> >
> > Forget XML. Everything in Rails, from templates to control flow to
> > business
> > logic, is written in Ruby, the language of choice for programmers
> > who like to
> > get the job done well (and leave work on time for a change)."
> > ============================================
> >
> > Putting all your logic in code is nothing new. That's how it was
> > done in the
> > 60's. By the 80's programmers created configuration files so that a
> > customer
> > request for increasing the customer number field from 5 to 6 digits
> > wouldn't
> > require recoding -- the user could change the config file. It
> > requires a lot
> > more coding, but it makes for a much more resiliant application.
> >
> > Anyone can write a "simple" app if he or she puts all the logic in
> > code, and
> > that programmer will be called every time a change is needed in
> > that code,
> > even if the change is trivial.
> >
> > To me, the art of programming is anticipating likely changes and
> > needs, and
> > putting facilities for those changes and needs in config files, so
> > that the
> > change can be made with a simple tech support call instead of a
> > code change.
> >
> > I believe in data centered programming.
> >
> > Once again, perhaps I misunderstood the intent of the web page, but
> > if they're
> > advocating moving logic from data to code, that's some advice I
> > will not
> > follow.
> >
> > SteveT
> >
> > Steve Litt
> > http://www.troubleshooters.com
> > slitt / troubleshooters.com
>
> I've actually used Rails in a few side projects and I have a
> different interpretation of those statements.  Rails packages the
> most common components of web development and automatically creates
> sensible defaults, which *can* be changed if necessary, in
> configuration files.  This is probably the biggest difference between
> Rails and many other web development frameworks / technologies.
>
> For example, instead of the developer maintaining configuration files
> that define existing attributes in database tables, which tend to be
> volatile due to customer requests, Rails just queries the table
> during runtime and asks it what attributes it has.  In another
> example, instead of the developer maintaining a configuration file
> that defines the location of my application's templates files, Rails
> creates the directories and manages the same information internally.
> The default behavior in both these examples can be over-ridden, but
> there's seldom a reason to do so in the majority of cases.
>
> Rails establishes a groovy synergy between these and other web
> development components that makes developing these kinds of
> applications easier.  I highly recommend you try if you do any
> serious web development.
>
> ~ ryan ~

Thanks Ryan,

Between you and James Edward Gray now I want to learn RAILS to see for myself 
whether I like it.

Everyone -- what's your opinion of the book I just dissed :-) 
(http://pragmaticprogrammer.com/titles/rails/index.html). Is it a good RAILS 
guide?

Are there other good RAILS guides? Are there any excellent web resources for 
RAILS?

Thanks

SteveT

Steve Litt
http://www.troubleshooters.com
slitt / troubleshooters.com