Whenever I use simple_form_for(), it has some really strange behaviour
for subclasses. For example, it defaults to “my_subclasses_path”
rather than “my_base_classes_path”. This can be corrected with a :url
=> some_path, but I am experiencing other frustrating problems.
In my case, I have a User object, but also many subclasses like Admin,
Director, etc. For some forms, I want to use a @user instance variable
and I want the resulting params hash to look like “params[:user]”
Unfortunately, if the @user instance is of the subclass “Admin”, it
will be sent as “params[:admin]” instead of params[:user]. This is not
what I want 
I find this above problem to be REALLY odd because the HTML form
source code actually says “user[first_name]” and NOT
“admin[first_name]” - but simple_form seems to want to make it
params[:admin] anyway when it sends the post request.
I really wish there was an option in simple_form so we could say:
base_class => 'User'
That would handle all of these things.
How can fix my problem so that simple_form exposes the subclass as
params[:user]?
Oh, and maybe my problem is not simple_form, but maybe it’s Rails. I
am not sure. I just know what I see 
It’s also really weird that when I change it to consume
params[:my_user_subclass] while the server is running, and then I
resubmit the form, it tries to go to params[:user] again. But if I
bail out of the form, and try again, it will correctly send to
params[:my_user_subclass]
This is very frustrating behaviour that I cannot even predict what the
server will actually do. It seems to change when it is first loaded
and then after an error occurs.
On 23 May 2011 15:05, egervari [email protected] wrote:
It’s also really weird that when I change it to consume
params[:my_user_subclass] while the server is running, and then I
resubmit the form, it tries to go to params[:user] again. But if I
bail out of the form, and try again, it will correctly send to
params[:my_user_subclass]
Are you sure you refreshed the page after changing the view (if that
is what you did) before re-submitting the form. How the data will be
submitted (which params keys will be used) is entirely determined by
the html on the page.
Colin
On 23 May 2011 15:51, egervari [email protected] wrote:
Even further, the changes I am making are in the POST action, not the
GET action - that stayed the same the whole time.
So are you saying that you changed the code in the POST action and
this changed the way the params were posted to that action (as seen
in the log file)? That seems rather odd as when the data are posted
it has not yet got to your modified action.
Colin
Are you sure you refreshed the page after changing the view (if that
is what you did) before re-submitting the form. How the data will be
submitted (which params keys will be used) is entirely determined by
the html on the page.
Colin
Yes, I am positive that I refreshed the page (not new to web
programming ;P)
Even further, the changes I am making are in the POST action, not the
GET action - that stayed the same the whole time.
Ultimately it really comes down to this:
If you do Admin.new, it will send params[:admin]. If you do User.new,
it will send params[:user].
I really just want to force it to do params[:user] no matter what
So are you saying that you changed the code in the POST action and
this changed the way the params were posted to that action (as seen
in the log file)? That seems rather odd as when the data are posted
it has not yet got to your modified action.
Yes! That is why this is so odd… because it is odd 
It’s like the params hash changes after you re-submit.
The only correction I can surmise is to use a concrete GET/POST action
for each user type This works though. Not what I want… and it
obviously a smell… but it works.
I wish it were easier to do the base class thing so it worked for
users of all sub classes without this much headache. In Java, you can
explicitly say, “I want this to be user” in an annotation - and
that’s it. It will use User for everything if you tell it to.
Does anyone have a solution to this? I have tried everything I can
think of.
Just imagine how awful this is for user’s profiles for example… you
would need to have a different edit/update action for each User
subclass just to get around this issue.
There has to be a solution.
I have added the question on Stack Overflow:
Feel free to answer it there. There’s also a lot more code and
information about my problem.
I really hope we can solve this. Designing your application using
common OO concepts like inheritance/polymorphism should be allowed,
expected and encouraged by Rails. I really hope Rails has not decided
to forgo inheritance to make their framework simpler.
On Mon, May 23, 2011 at 4:46 PM, egervari [email protected]
wrote:
to forgo inheritance to make their framework simpler.
Hi, have you tested you application without the use of simple_form?
Also,
have you generated a ticket with
the gem author on github?
-Conrad
I don’t use simple form, but I am successfully using something like
this:
= form_for @user :as => :user do |f|
This will make sure that all fields are in the form are something like
user[first_name], even when @user is really an Admin or any other
descendant
of User.
Hope this helps,
–
Ylan.
