Conditional RJS for :create action

I need to create Replies to Comments using RJS. The interface has
determined two different ways of creating replies. One could be seen as
a 'inline reply' approach (once posted, the reply pops in to view, in
place of the form, and both fade away), and the other approach is when
all existing replies are listed underneath the comment and a posted
reply simply pops in to view without replacing the form or fading away.

I'm not good with rjs or js, so to get this working with my own hands I
had to resort to using two different :create actions in the replies
controller (the usual :create action was just left in place, and I
created an :inline_create action for the 'inline reply' approach,
therefore giving me an inline_create.js.rjs). I imagine this is bad on
the DRY front, but it's also caused some problems because I have two
different types of Reply (one for a different type of Comment model - I
cut out polymorphism because it wasn't suitable for this app - believe
me). Here's where I believe the problem is;

This seems to work;
comment.resources :replies, :collection => { :inline_create => :post }

And this doesn't;
direct_comment.resources :replies, :controller =>
"direct_comment_replies", :collection => { :inline_create => :post }

With the later route, I just can't seem to post to the action. I believe
I've tried everything that works with the former route, but the later
just doesn't want to work (I can even post to the standard create action
in the direct_comment_replies controller, but as soon as I pre-fix it
with inline_create, I just can't post to the custom action).

I was happy to accept the non-DRY additional :inline_create action
approach if it simply worked across these two Comment.replies features,
but it appears that this custom action doesn't work when the resource
name (:replies) doesn't match the controller name
(direct_comment_replies). Does anyone have any ideas on how I either, a)
create an rjs template conditional (so I can remove the :inline_create
actions entirely) or, b) how I can get the second route to work?

No thoughts on this one? I haven't got any closing to fixing this yet, I
imagine the best solution is custom js that knows how to act depending
on what is in the view - I just don't know js!

Nate Leavitt wrote:

Neil Cauldwell wrote:

No thoughts on this one? I haven't got any closing to fixing this yet, I
imagine the best solution is custom js that knows how to act depending
on what is in the view - I just don't know js!

Ok.. not sure if i really get what you're asking for, but the first
thing I noticed is that you can setup your controller to respond to
different types of requests. At the bottom you need to have something
similar to:

respond_to do |format|

so if the request comes in as a normal post it will render your erb
file, but if the request is an ajax request then it will render the rjs
template named after your controller action.

Thanks Nate. I'm good with the differences between format.html &
format.js (I made the app work without ajax first, now I'm sprinking
ajax where appropriate), what I want to do is to be able to conditionals
on the format.js template.

My interface is quite complex, so I can't use a single rjs template to
handle what needs to happen when a user posts a Reply from different
areas of the interface. Having different forms and actions helps because
I get separate rjs templates and don't need to use conditionals in the
RJS or js - I just post to a different URL to get a different response.
However, this approach seems to have broken in one controller because
the controller just doesn't respond, and funnily enough it's one where
the controller name doesn't match the resource name. I think custom js
may be the only solution for this.

Andrew Edwards wrote:

Hi Neil,

Did you ever get anywhere with this? I've got the same issue, in my
case a create action with multiple possible render options depending
on the page. I've just posted a question about it and then found your

At present I've just got to create actions (create and checkout_create
- it's for addresses which can also be created during a checkout)



On 6 Aug, 22:41, Neil Cauldwell <>

I've kept the separate controller actions for now - it just works.
Although, it'll probably be cleaned-up at some point based on tips in
these posts;

If you can perform RJS based on the presence of a DOM ID or class, you
can keep things in one RJS file. However, it can get messy either way.
If you stick with two controller actions, and you're happy it works,
make a 'shared create' method which contains the code which actually
creates the address, that way you only have one piece of code for saving
the records to the database. That was the only part that really got to