I am redesigning a php app in RoR. I am brand new to both Ruby and Rails. There is a front end to the app with the typical MVC kind of interactions between end users and a database. There is also backend processing that happens independent of any user interaction. My question is, does the RoR framework make any sense for this backend processing seeing as there wouldn''t really be any "views"? I don''t want to code in two languages unnecessarily but I also don''t want to force something into a mold for which it is not designed. Does RoR for backend processing make sense? If not, what does? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi Kenneth, On Tue, Mar 1, 2011 at 5:48 PM, Kenneth Vogt <kenneth.vogt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I am redesigning a php app in RoR. I am brand new to both Ruby and > Rails. There is a front end to the app with the typical MVC kind of > interactions between end users and a database. There is also backend > processing that happens independent of any user interaction. My > question is, does the RoR framework make any sense for this backend > processing seeing as there wouldn''t really be any "views"? I don''t > want to code in two languages unnecessarily but I also don''t want to > force something into a mold for which it is not designed. Does RoR for > backend processing make sense? If not, what does?My short answer is yes. My current app provides two sorts of what I think you mean when you say ''backend processing.'' script/runner gives us access to the Rails app outside the ''interactive user'' model. In the first case there a user requests a report. That request is queued via the Background job plugin. When the Background job runs, it -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Oops. Continuing... On Tue, Mar 1, 2011 at 6:08 PM, Bill Walton <bwalton.im-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi Kenneth, > > On Tue, Mar 1, 2011 at 5:48 PM, Kenneth Vogt <kenneth.vogt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> I am redesigning a php app in RoR. I am brand new to both Ruby and >> Rails. There is a front end to the app with the typical MVC kind of >> interactions between end users and a database. There is also backend >> processing that happens independent of any user interaction. My >> question is, does the RoR framework make any sense for this backend >> processing seeing as there wouldn''t really be any "views"? I don''t >> want to code in two languages unnecessarily but I also don''t want to >> force something into a mold for which it is not designed. Does RoR for >> backend processing make sense? If not, what does? > > My short answer is yes. My current app provides two sorts of what I > think you mean when you say ''backend processing.'' script/runner gives > us access to the Rails app outside the ''interactive user'' model. >In the first case there a user requests a report. That request is queued via the Background job plugin. When the Background job runs, it creates the report and then emails it to the requester. In the second case, we have cron jobs that also call script/runner to do nightly database maintenance; removing accounts that have been canceled, etc. If you''ve got a specific case you''re wondering how you''d handle, feel free to ask about it. HTH, Bill -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mar 1, 6:15 pm, Bill Walton <bwalton...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Oops. Continuing... > > On Tue, Mar 1, 2011 at 6:08 PM, Bill Walton <bwalton...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hi Kenneth, > > > On Tue, Mar 1, 2011 at 5:48 PM, Kenneth Vogt <kenneth.v...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> I am redesigning a php app in RoR. I am brand new to both Ruby and > >> Rails. There is a front end to the app with the typical MVC kind of > >> interactions between end users and a database. There is also backend > >> processing that happens independent of any user interaction. My > >> question is, does the RoR framework make any sense for this backend > >> processing seeing as there wouldn''t really be any "views"? I don''t > >> want to code in two languages unnecessarily but I also don''t want to > >> force something into a mold for which it is not designed. Does RoR for > >> backend processing make sense? If not, what does? > > > My short answer is yes. My current app provides two sorts of what I > > think you mean when you say ''backend processing.'' script/runner gives > > us access to the Rails app outside the ''interactive user'' model. > > In the first case there a user requests a report. That request is > queued via the Background job plugin. When the Background job runs, > it creates the report and then emails it to the requester.There are several background processing gems available the two that seem to be the most popular are Delayed Job(DJ) and Resque. My company uses DJ and have been very pleased with how it works and have had just a single problem with it but only because we allowed unvalidated input to get passed to the worker (our failure, clearly). I would strongly discourage use of Background Job because it is no longer being actively developed (last updated ~2 years ago) and has problems w/ Rails 3 IIRC.> In the second case, we have cron jobs that also call script/runner to > do nightly database maintenance; removing accounts that have been > canceled, etc.To ease your life writing your cron file I would recommend Whenever, you write a schedule in ruby and when you run the generator supplied w/ the gem it installs the schedule into the current user''s crontab, we have this linked to our deploy process so when we deploy a new crontab gets written ensuring it gets update. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.