I reviewed the AnnoJ calls and realised that part of the problem is that it uses the reserved Rails param 'action' to specify what it wants to happen, i.e. range or lookup for example.
Rails strips the action parameter and injects its own that reflect that actual Rails action that is being called in the controller.
This PR adds some Rack middleware that intercepts the request and injects a annoj_action param that reflects the original request by AnnoJ. As such we can clean up the features_controller code significantly as there's no need for custom param parsing, i.e.:
case params[:annoj_action]
when "range"
@response = range(params['assembly'], params['left'], params['right'], params[:id], params['bases'], params['pixels'])
when "lookup"
@response = lookup(params["query"], params[:id])
end
render :json => @response, :layout => false
I reviewed the AnnoJ calls and realised that part of the problem is that it uses the reserved Rails param 'action' to specify what it wants to happen, i.e.
range
orlookup
for example.Rails strips the action parameter and injects its own that reflect that actual Rails action that is being called in the controller.
This PR adds some Rack middleware that intercepts the request and injects a
annoj_action
param that reflects the original request by AnnoJ. As such we can clean up the features_controller code significantly as there's no need for custom param parsing, i.e.:Much cleaner.