Topic: Best place to handle non-web data processing activities?

I am working on a rails application and so far form submission, views etc. are working out OK.

My question is: what is the best 'Rails Way' to handle non web related administrative tasks?

The administrator occasionally needs to run processes which make pre-planned edits to text files, run SQL inserts and updates and other data processing activities as part of administrating the application.

An example is: when a new pay period is being created, an administrator loads a text file which defines a custom calendar for the pay period, runs a process which modifies it based on the existence (if any) of holidays in that period, then saves the result into another table.

What is the best way to create non-web administrative processes and make them available to the admin through a Rails web page?

Thanks for any help.  --Fred

Re: Best place to handle non-web data processing activities?

If the administrator will be doing administrative tasks via a rails web page,  then it really isn't non web related,  it's just 'not for normal user consumption'.

I assume you have an authentication system of some kind.  I also assume you've got an admin attribute of some kind?  So when the admin logs in,  you can determine that fact and present different links, etc.  that link to the admin functions.   For example, I use devise for authentication,  I have a boolean attribute in my user table called admin.  Peppered throughout my code are checks for admin status.  In my main application layout file for example, I'd have something like this:

<% if current_user.try(:admin?) %>
  <%= link_to '> Add User' , new_user_path %>
  <%= link_to '> Edit Users' , users_path %>
<% end %>

Then in various controllers, I have to still check for admin status,  so I'd have:
app/controllers/users_controller.rb

def new
  if current_user.try?(:admin)
     ...
  else
    flash.error = "Nice try,  but NO!"
    redirect_to("/")
  end
end
Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.

Re: Best place to handle non-web data processing activities?

Thanks for your reply.  I understand restricting access to the admin page to admin users, my question is: where do I put the actual processing code (text processing, SQL commands) and How do I invoke it from the admin page?

Re: Best place to handle non-web data processing activities?

You could just create an admin_controller,  nothing wrong with having a controller that isn't directly tied to a model.  Or you could put all the admin stuff in the lib directory.  If this code you're developing can be developed outside of the rails infrastructure,  i.e. pure ruby,  and you can develop it just by editing ruby files and testing it like

ruby mystuff.rb

Then that's probably a good candidate for the lib directory.  Typically you'd create a module, i.e.

module MyStuff
   def  editsometext
   end

   def dosomeweirdSQL
   end
end

Then in your mainstream code, you'd

include MyStuff

You have to make sure that the rails knows about the lib directory,  in application.rb:

config.autoload_paths += %W(#{config.root}/lib)

Another alternative is in helpers.  Typically helpers are used to keep view code clean and concise,  i.e if you have a particular MVC that has really complex logic in the various views needed to generate your HTML,  you'd create a helper method,  do all the complex stuff there,  and have a simple call in your view code.  But helpers are another method of sharing code.  Nothing prevents you from putting your code in a helper.

So, lot's of options,  just depends on exactly what you are doing.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.

Re: Best place to handle non-web data processing activities?

Thanks for your advice, this gives me something to chew on.  Some of the processing will be pure Ruby,  candidate for an .rb file, some will want to read from one or more of the models. 

You've given me a good leg up on where to distribute the work.

Thanks again for some of your always good advice.  --Fred

Re: Best place to handle non-web data processing activities?

Clarification:  your code doesn't HAVE to be standalone,  independent of the rails infrastructure, to be a good candidate for the lib directory.  If you just need some code that you can call anywhere,  the lib directory is a good way to go. 

You should also be aware of config/initializers.  A good place to put any initialization code your stuff may need.   I haven't investigate the boot sequence of rails since the 2.2 days,  and I think it's changed a bunch,  so before you go too far,  you'd have to verify that the autoload_paths are set before the initializers are run,  so you can include YourStuff in your initializers.   I'm pretty sure that's the case,  but I'd run a simple test to verify.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.

Re: Best place to handle non-web data processing activities?

One last suggestion,  you could always just put your code in your application_controller.rb,  seeing as every controller typically inherits from it,  anything you define in there is available to all your controllers.  It's kind of a brute force approach,  you may not want the code in every controller.  That probably should of been my first suggestion.  It's simple,  but potentially inefficient.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.