How do I determine the "source" action for conditionally rendering error actions and validation messages?

rubyonrails-talk
#1

I have a model called Stock.rb. I created an additional action, called
dispense, in the controller so that I could render two different views
based on the type of data entry being done. The "new" action is used
for "adding stock" and the "dispense" action is used for "dispensing
stock."

They are very similar, but use different form partials to remove
fields that could potentially cause confusion. Both actions use the
"create" action when submitted.

Stock.rb contains
validates_presence_of :medicine_id, :route_id

stocks_controller.rb contains

  def create
    @stock = Stock.new(params[:stock])
    @routes = Route.find(:all, :capitalize, :order => :name)
    @medicines = Medicine.find(:all, :capitalize, :order => :name)
    if @stock.save
      flash[:notice] = "Success | Sucesso | Éxito | Réussi"
      redirect_to(:back)
    else
      flash[:error] = "You must select a medicine and a route."
      redirect_to(:back)
      #render :action => 'new'
    end
  end

Each of the form partials contains
<%= f.error_messages %>
so that validation errors are shown at the top of the form if the user
fails to select a medicine or a route.

The problem I'm having is that the validation error messages are only
shown when using render.
render :action => 'new' shows the error messages, but if the user
comes to this from the "dispense" action, they are returned to the
form for the "new" action, which is used for a different purpose.

I changed the code to redirect_to(:back), which returns the user to
the proper form, but doesn't show the validation error message -- only
the flash[:error] message that I inserted.

How do I either:
1) Detect which action/view/template sent the user to the create
action, so that I can conditionally return them to the proper action
using render?

or

2) Use redirect_to(:back) and still show the validation errors?

#2

I have a model called Stock.rb. I created an additional action, called
dispense, in the controller so that I could render two different views
based on the type of data entry being done. The "new" action is used
for "adding stock" and the "dispense" action is used for "dispensing
stock."

They are very similar, but use different form partials to remove
fields that could potentially cause confusion. Both actions use the
"create" action when submitted.

Not answering your question directly, but you might considered an
alternative approach, which is to use the 'new' action for both adding
and dispensing, with a parameter in the url to indicate which is
required (or possibly you can already tell which action is required by
examining the existing parameters). You say the two actions are very
similar so this might make for less code and would solve the problem
you are having with the render I think.

Colin

#3

The RESTful way is to have a "dispense_stock" controller - which has
its own methods.

The cheaty (smelly) way is to put a hidden field in the form or an
extra querystring parameter with with the value "new" or "dispense",
and check the params hash for the value.

#4

Whether this is smelly or not really depends on how similar the two
actions are. As I understand it they both create a new record in the
same table, so it _could_ be virtually (or even completely) odour free
to use the same action and determine the details of what to do based
on parameters (it may not even be necessary to add a new parameter, it
may be implicitly clear from existing parameters). On the other hand
I agree that route could cause an offensive effluvia to exuded. It
all depends on the detail.

Colin

#5

Don't get me wrong - I wasn't saying *don't* use a hidden param - I
was suggesting it as a perfectly acceptable option... it's just that I
know the REST police will jump on you if you're not careful.
To be honest, in lots of situations, the quick, easy (dirty?) way is
best *because* it's quick and easy.

And you're right; it may be perfectly possible to design the form to
use the same, restful action, and please everybody :slight_smile:

#6

Both of your comments were helpful and led to me to consider how I
could check the form elements to determine where to send them upon
validation failure. It ain't restful and probably smells quite
unpleasant, but it seems to work. I'll keep an eye on it and improve
the structure once I've straightened up some other issues. Thanks!