What is the equivalent for write_attribute for associations in Rails?

I'd like to override the setter for an association, but
write_attribute() isn't working - probably because that method only
works for database columns.

I have tried super(), but that doesn't work either (didn't think it
would... but it was worth a guess).

How do I override the setter? Here is what I am trying to do:

      def parent=(value)
        # this line needs to be changed
        write_attribute(:parent, value)

        if value.subject.start_with?('Re:')
          self.subject = "#{value.subject}"
        else
          self.subject = "Re: #{value.subject}"
        end

        self.receivers << value.sender
      end

Do I just just call the belongs_to relationship to a different name
like _parent or something?

I found one way to achieve this, but I'm disturbed by it:

  alias_method :old_parent=, :parent=

  def parent=(value)
    self.old_parent = value

    if value.subject.start_with?('Re:')
      self.subject = "#{value.subject}"
    else
      self.subject = "Re: #{value.subject}"
    end

    self.receivers << value.sender
  end

One thing I don't necessarily like about Rails is that whenever you
want to do something that is out of the norm just a bit - but not
unreasonable by any means - the "how" is very different than what your
intuition would come up with.

It's not a problem when you know the exceptions, but when you're
learning, this sort of irregularity and inconsistency on how to do
things makes it harder to learn - not easier.

Java might be initially harder to learn, but it's way more consistent.
Your intuition can take you a lot further once you think in Java. This
is not true once you think in Rails. Rails is about memorization of
methods to call and memorization on how to do things. In java, you can
reason it out a lot more.

I'm just disappointed. This is a reoccurring pattern for me - I want
do something that is just "a little more complex" than the framework
examples... and the "how" is inconsistent and takes 30 minutes or
maybe even hours to locate and find the answer for it.

I realize I'm just learning Rails, but I have dozens of gotchas and
inconsistencies as I go through the framework and use it. This is not
accounting for weird gem errors, rake version problems, etc. If I only
kept track of a list of all the problems that probably shouldn't have
been problems to start with to illustrate what I am saying :frowning:

I use this method on occasion. If you're going to do your:
  if value.subject.start_with?('Re:')
...it's worth checking that "value.respond_to?(:subject)" or that
"value.is_a?(Parent)" first.

Hi All,
I tried to deploy rails app in apache server ,i did the following things,didnt get the app run,can any one help me pls
gem install passenger
passenger-install-apache2-module

My rails app location:
/var/www/rails
cd /etc/apche2/sites-available
touch m-lo-lo.com(my virtualhost file)
<VirtualHost 127.0.0.0:81>
#ServerAdmin webmaster@myapp.com
ServerName m-lo-lo.com
DocumentRoot “/root/var/www/rails/public/”
<Directory “/root/var/www/rails/public/”>
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all

RailsEnv production
PassengerMaxPoolSize 25
LogLevel warn
ErrorLog /var/log/apache2/rails/error.log
CustomLog /var/log/apache2/rails/access.log combined

**To create symbolic link for virtual host file in “sites-enabled” directory **
ln -s /etc/apche2/sites-available/m-lo-lo.com /etc/apche2/sites-enabled/m-lo-lo.com

sudo vi /etc/hosts file

#192.168.21.129 ubuntu # Added by NetworkManager
#127.0.0.1 localhost.localdomain localhost
127.0.0.1 m-lo-lo.com p233
::1 ubuntu localhost6.localdomain6 localhost6
127.0.1.1 ubuntu

The following lines are desirable for IPv6 capable hosts

::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
vi port.conf
Listen 8081

# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
Listen 443


Listen 443

I created a file "passenger.load "in mod-available directory:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.7
PassengerRuby /usr/bin/ruby1.8

a2ensite m-lo-lo.com
Site m-lo-lo.com enabled

/etc/init.d/apache2 reload
/etc/init.d/apache2 restart

mkdir /var/log/apache2/rails/
touch access.log
touch error.log

cd /var/www/rails
touch tmp/restart.txt

Thanks,
Loganathan.s

One thing I don't necessarily like about Rails is that whenever you
want to do something that is out of the norm just a bit - but not
unreasonable by any means - the "how" is very different than what your
intuition would come up with.

It's not a problem when you know the exceptions, but when you're
learning, this sort of irregularity and inconsistency on how to do
things makes it harder to learn - not easier.

Java might be initially harder to learn, but it's way more consistent.
Your intuition can take you a lot further once you think in Java. This
is not true once you think in Rails. Rails is about memorization of
methods to call and memorization on how to do things. In java, you can
reason it out a lot more.

I'm slightly confused by you making comparisons between a language and
a framework - I'm sure there are a wide variety of java web frameworks
that all do things differently. I can't say I've ever found rails to
be a tedious memorisation exercise. It just sounds like you don't
understand enough about rails to let your intuition guide you.
You might find that association callbacks are a good fit for your
original problem (and callbacks of that sort are used fairly
extensively in rails)

Fred.

One thing I don’t necessarily like about Rails is that whenever you

want to do something that is out of the norm just a bit - but not

unreasonable by any means - the “how” is very different than what your

intuition would come up with.

It’s not a problem when you know the exceptions, but when you’re

learning, this sort of irregularity and inconsistency on how to do

things makes it harder to learn - not easier.

Java might be initially harder to learn, but it’s way more consistent.

Your intuition can take you a lot further once you think in Java. This

is not true once you think in Rails. Rails is about memorization of

methods to call and memorization on how to do things. In java, you can

reason it out a lot more.

I’m slightly confused by you making comparisons between a language and

a framework - I’m sure there are a wide variety of java web frameworks

that all do things differently. I can’t say I’ve ever found rails to

be a tedious memorisation exercise. It just sounds like you don’t

understand enough about rails to let your intuition guide you.

You might find that association callbacks are a good fit for your

original problem (and callbacks of that sort are used fairly

extensively in rails)

Fred.

I’m just disappointed. This is a reoccurring pattern for me - I want

do something that is just “a little more complex” than the framework

examples… and the “how” is inconsistent and takes 30 minutes or

maybe even hours to locate and find the answer for it.

I realize I’m just learning Rails, but I have dozens of gotchas and

inconsistencies as I go through the framework and use it. This is not

accounting for weird gem errors, rake version problems, etc. If I only

kept track of a list of all the problems that probably shouldn’t have

been problems to start with to illustrate what I am saying :frowning:

I am also wondering if there is a better way to achieve what you want – I dont completely understand what you are trying to do above other than manage ‘Re’ or no ‘Re’ in the subject (I am assuming you are doing a messaging or email-like system). If there is any way to do something and
not ‘fight’ rails, in my experience it is almost always better…
to Frederic’s point, to not fight rails (and ruby) you must understand it. That is easier said than done, I often find simple ways to do what I
had tried to do before in a more complex/hacking manner. For that reason it may be better to step back and state your primary goal, not the proposed fix/aproach… then you might have some more constructive response from the list.

I'm slightly confused by you making comparisons between a language and
a framework - I'm sure there are a wide variety of java web frameworks
that all do things differently. I can't say I've ever found rails to
be a tedious memorisation exercise. It just sounds like you don't
understand enough about rails to let your intuition guide you.
You might find that association callbacks are a good fit for your
original problem (and callbacks of that sort are used fairly
extensively in rails)

Fred.

Hi Fred,

I am learning Rails, as I learn to think more like Rails, my
application starts to become cleaner and make more sense. I am always
refactoring and improving the quality of my code as I learn new
things. So don't misunderstand me - I am learning and I realize that.
I think in my case, being extremely good at Java, it probably makes my
job HARDER and not easier. But I'm not totally brainless either - my
Rails app looks and feels different from prior Java apps.

I'm also not comparing a framework to a language. I think Ruby allows
for these problem to happen, and the design of Rails exploits it in a
bad way.

For example, form_for() is very troubling beast. I am just point this
one out among countless other examples - it's just one arbitrary
example from a bag of many.

Let's say you put a controller into a namespace, you must go from:

    form_for(@company)

to:

    form_for([:my_namespace, @company])

Intuition may have suggested this:

    form_for(@company, :namespace => :my_namespace)

The changing of the argument from an object to an array is non-
intuitive. I admit it's nice and easy, but it's only valuable if you
*KNOW* it. One cannot "guess" this. I don't see how.

There are all sorts of problems like this. For example if you have a
@user, but it's actually a subclass, form_for() will use the model's
name, not the instance variable's name. This is NOT intuitive. When I
first starting to use rails, I would scratch my head wondering why
it's trying to send params[:admin] and not params[:user] even though
the form variable was @user.

Again, the solution is this:

    form_for(@user, :as => :user)

This kind of thing is not intuitive. Who in their right mind would
ever search for "as" in google in order to achieve this goal? Not me.
It took me 4-5 hours to find the answer to this problem. I am not
kidding. I searched everywhere, asked questions on Stackoverflow,
asked questions here... I didn't get the answer until Carlos simply
told me.

Contrast this with Java, and it "just works". Your model data to be
sent to the view is named whatever you name it - it doesn't get
renamed "magically". It really just works. Sure, it's a bit more
typing, but it works like you expect it to - there's no guessing. It's
very easy to reason about. This means you move onto the next
requirement much quicker without ever scratching your head as to WHY
it's not working.

If you must rename it something else in Spring for example, you have
intellisense in your IDE which will tell you to set the "value" or
"type" for your actions in your controller. This sort of thing can be
changed in 5 seconds with no prior knowledge of HOW to do it. What I'm
saying is that you can "guess" the "how" - and there's a really good
chance that your guess will be right. At least mine usually is.

Most of Rails makes sense, especially if you do the simple things -
the things where you find TONS of examples for online. It's the
"weird" and somewhat "uncommon" things that really bite me all the
time. In Java, I have traditionally found myself intuitively guessing
the answers and having my intuition be correct. This has almost never
happened when using Ruby/Rails :frowning:

But intuition is the result of experience. How much Ruby and Rails experience do you have?

Find an old Lisp hacker who has written code in Lisp for the last 30 years and I'm pretty sure they will find nothing about Java intuitive. If you don't think that's true, just see the problem that some lisp guys have with concepts like class paths when trying to get started with Clojure. And don't even get me started on why I have to tell the compiler a bunch of type information it could quite easily infer (see Scala for a good example of a strongly typed language with low ceremony and good type inference).

I'm still getting up to speed in Ruby and Rails and continually find things that don't seem intuitive to me - despite a decent grounding in dynamic languages like Groovy and Python and a programming career encompassing a lot of languages. But I don't immediately assume that to be an issue with Ruby or Rails, but rather a limitation of my intuition due to the lack of experience with the idioms of Ruby and Rails. (Side note - get a copy of Eloquent Ruby - it'll help a lot. Also read The Rails 3 Way, Crafting Rails Applications, the Rspec book and everything else you can get your hands on about Rails and try to pair and attend hackfests to get a feel for how Rails developers write code)

Get to know some excellent Ruby devs at RubyConf (you just missed RailsConf last week in Baltimore if you weren't there - it was a blast), regional conferences and local meetups. Ask them some questions including why they use the language. I moved to Ruby and Rails because many great developers I know from other language communities told me they found it to be more productive and fun. My experience (despite the occasional frustration) bears that out. Also, build a deep network of Ruby devs so when you *have* an issue you can IM someone and figure it out in 5 minutes. Software engineering is fundamentally a social endeavor.

Or you can always go back to Java. The Play framework isn't bad and Spring Roo does an awesome job of using best practices in code generation and providing a command line experience that even Rails should envy. Spring gives you DI and AOP which are useful. Groovy is an awesome language with AST transforms that provide an amazing set of metaprogramming capabilities, and while it isn't quite as mature as Rails, I've successfully built a number of projects using Grails and it's an excellent tool for developing Java centric apps on the JVM (although if you just need to deploy to war files, you should also look at running Rails using JRuby).

Best Wishes,
Peter

I'm also not comparing a framework to a language. I think Ruby allows
for these problem to happen, and the design of Rails exploits it in a
bad way.

Well you do keep comparing Rails to Java. I'm sure equivalent
interfaces could be implemented in Java. You'd end up overloading
methods more explicitly than with ruby but if your goal is to guess
what other overloaded forms exist without looking at the docs I don't
think that would help.

For example, form_for() is very troubling beast. I am just point this
one out among countless other examples - it's just one arbitrary
example from a bag of many.

Let's say you put a controller into a namespace, you must go from:

form\_for\(@company\)

to:

form\_for\(\[:my\_namespace, @company\]\)

Intuition may have suggested this:

form\_for\(@company, :namespace =&gt; :my\_namespace\)

The changing of the argument from an object to an array is non-
intuitive. I admit it's nice and easy, but it's only valuable if you
*KNOW* it. One cannot "guess" this. I don't see how.

It's perhaps easier to understand when you know how form_for works -
like link_to, redirect_to etc and countless other bits of rails that
create urls from objects, it funnels everything though polymorphic_url

There are all sorts of problems like this. For example if you have a
@user, but it's actually a subclass, form_for() will use the model's
name, not the instance variable's name. This is NOT intuitive. When I

Well to me it would be extremely unintuitive if a method could know
the name of the instance variable that happened to contain one of the
arguments it was called with.

first starting to use rails, I would scratch my head wondering why
it's trying to send params[:admin] and not params[:user] even though
the form variable was @user.

Again, the solution is this:

form\_for\(@user, :as =&gt; :user\)

This kind of thing is not intuitive. Who in their right mind would
ever search for "as" in google in order to achieve this goal? Not me.
It took me 4-5 hours to find the answer to this problem. I am not
kidding. I searched everywhere, asked questions on Stackoverflow,
asked questions here... I didn't get the answer until Carlos simply
told me.

It's in the documentation for form_for - it's where I would have
started.

Fred

At the risk of hijacking the thread, I'd be happy to know of any
better ways that can be suggested to achieve this. For example, I've
got this method (okay, it's a get rather than set, but it's the same
idea):

  alias_method :ar_creator, :creator
  def creator
     ar_creator || Person.find_by_sql("select 'unknown' as firstname,
'noter' as lastname, '' as othernames").first
  end

I *could* check for the existence of "creator" [1] in views and other
places, but it sometimes strikes me as easier to just ensure I'm
providing a valid associated object from the model if one does not
exist.

[1] I do use guards most of the time, but on occasion, the amount of
checks for "if Model.associated_object" seems not very DRY

Find an old Lisp hacker who has written code in Lisp for the last 30 years and I'm pretty sure they will find nothing about Java intuitive. If you don't think that's true, just see the problem that some lisp guys have with concepts like class paths when trying to get started with Clojure. And don't even get me started on why I have to tell the compiler a bunch of type information it could quite easily infer (see Scala for a good example of a strongly typed language with low ceremony and good type inference).

I agree with this. Java is not perfect, but the language is simple.
Yes, you have to redefine types multiple times (and I'm aware that
Scala fixes this... I love Scala), but at least it's consistent. You
never have to ask: "should I or shouldn't I add the type?" The answer
is: "you always add the type"

I know that sounds silly, but you'd be amazed at how simple things
become. You never have to worry about passing in an object compared to
passing in an array where the first argument is a symbol and the
second argument is an object.

As for classpaths - I hear you. Classpaths were designed really
stupidly, and to compound the problem, the rules are different on your
local machine on Windows from deploying on Tomcat under Linux (trust
me, I know).

Classpath loading didn't have to be this way, but is - and Sun (now
Oracle I guess) has a history of supporting every broken standard,
api, and design decision to the bitter end :frowning:

I'm still getting up to speed in Ruby and Rails and continually find things that don't seem intuitive to me - despite a decent grounding in dynamic languages like Groovy and Python and a programming career encompassing a lot of languages. But I don't immediately assume that to be an issue with Ruby or Rails, but rather a limitation of my intuition due to the lack of experience with the idioms of Ruby and Rails. (Side note - get a copy of Eloquent Ruby - it'll help a lot. Also read The Rails 3 Way, Crafting Rails Applications, the Rspec book and everything else you can get your hands on about Rails and try to pair and attend hackfests to get a feel for how Rails developers write code)

I admit that sometimes I am at fault. I tried sub-classing Users, and
while this might remove some duplication and put things in the right
place... it's not the correct way to do it with Rails. The amount of
"Pushback" I get from doing this at all stages (routes, controllers,
etc.) is not worth the hassle.

Still, I think the two problems I highlighted don't have much to do
with "common idioms". The common idiot in rails is to use parameter
hashes, yet [:admin, @user] is far from that. The word ":as" has a
ambiguous meaning too when it's applied to subclasses... which is
(probably) the only time you'd ever want or need to use it.

Get to know some excellent Ruby devs at RubyConf (you just missed RailsConf last week in Baltimore if you weren't there - it was a blast), regional conferences and local meetups. Ask them some questions including why they use the language. I moved to Ruby and Rails because many great developers I know from other language communities told me they found it to be more productive and fun. My experience (despite the occasional frustration) bears that out. Also, build a deep network of Ruby devs so when you *have* an issue you can IM someone and figure it out in 5 minutes. Software engineering is fundamentally a social endeavor.

My network stinks. I'm pretty much doing this all by myself. I have no
problem with that - I work better on my own for the most part. This is
an individual project by me and myself and I.

Or you can always go back to Java. The Play framework isn't bad and Spring Roo does an awesome job of using best practices in code generation and providing a command line experience that even Rails should envy. Spring gives you DI and AOP which are useful. Groovy is an awesome language with AST transforms that provide an amazing set of metaprogramming capabilities, and while it isn't quite as mature as Rails, I've successfully built a number of projects using Grails and it's an excellent tool for developing Java centric apps on the JVM (although if you just need to deploy to war files, you should also look at running Rails using JRuby).

I thought about going back to Java, but that means scrapping 2 weeks
of work. I'm trying to look at it objectively - would I make up the 2
weeks in the long-run by going back to Java world? Or would I still be
a productivity gain if I stick with Rails?

Knowing what I know now... I *should* have stayed with Java if I want
to finish in ~1.5 to 2 months. I didn't realize I'd run into so many
problems. It's not like I am actually learning web development
concepts... I am just being slowed down by trying to learn the *how*
with respect to ruby/rails.

The app I am building isn't simple, so almost all of the test examples
and code examples look pretty, but they are not very applicable to me
unless it's the simplest case. Ruby/Rails definitely has the features
to do what I want, but there's an obvious time-sink or lag or learning-
curve (whatever you want to call it) that I need to overcome in order
to be as productive or even more productive than I was using Java/
Spring/hibernate.

One of the reasons I find Ruby/Rails appealing is that there is
clearly more innovation going on. While Java/Spring can do most of
what Rails can do, it's harder to do it. I think in 5 years, there's a
good chance Java is going to be so far behind. That is why I switched.
I can see a sinking ship when it's happening.

Scala also hasn't really taken off like "everyone said it would". Ruby
seems to be that language instead. And I can understand why too - it's
being pushed far too much into academia and not into real world
problem solving/applications. Ruby understands this, Scala doesn't.

So that's where I am :confused:

I agree completely. So much.

There are many great things about Rails but I've lost so much time
trying to accomplish slightly off pattern things, the sort of things a
real project needs.

I believe that this is what holds Rails back. The initial learning
curve is shallow and exciting but can become very steep.

I wish I had learned more about ruby in the beginning.

Just curious -- in which parallel universe is Rails being "held back"?