Hi, I'm a bit new to Rails (although, not as new to Ruby), and I'm pretty excited about it. Slightly before this, however, I thought I'd implement an internal app that we could use at my company. I'm sending this mail to ask if Rails would be best suited for this. We run a hosting business, with some 50 clients. Each client has can have one or more sites, which each has: - an Apache VHost - various email config files - MySQL databases - htaccess usernames - DNS entries - backup entries ...and so on. There are a lot more. I've tired of keeping these in sync, so I thought to myself, I'll write a Ruby script to pull all the info from a database, change some of it, or calculate some more info as require, and write all of it to a whole bunch of different files in different places. Then, I realized, it'd be nice if there were a web frontend to all this, and, the information somewhat naturally fits an MVC architecture. I decided to look into using Rails. So, my actual questions (kudos, you've read this far!) are: Question 1: How can I use dynamic scaffolding for all these models? Do I need a separate controller for each one? I'm fine with the interface generated by the dynamic scaffold, and i want to focus on the functionality and beckend before I focus on the interface. Question 2: What is the correct, Rails way of generating all those files? They are in many different places. Perhaps, I can define a view type (I.E., in addition to HTML, XML, and JS), and then write a helper script to pipe the contents of a bunch of into files? Or, is there a better way? Is Rails even the best tool for something like this? Answers, or advice of any kind, is appreciated! -Benjamin Kudria
on 2007-06-13 04:00
on 2007-06-13 07:14
> - DNS entries > the information somewhat naturally fits an MVC architecture. I decided to > look into using Rails. > > So, my actual questions (kudos, you've read this far!) are: > > Question 1: > How can I use dynamic scaffolding for all these models? Do I need a separate > controller for each one? I'm fine with the interface generated by the > dynamic scaffold, and i want to focus on the functionality and beckend before > I focus on the interface. You probably could, but I suspect you'll find that you might not want to. A lot of that information can be bundled into one page (or not) but I suspect the UI will be complicated enough that you will want to manage it yourself. > Question 2: > What is the correct, Rails way of generating all those files? They are in > many different places. Perhaps, I can define a view type (I.E., in addition > to HTML, XML, and JS), and then write a helper script to pipe the contents of > a bunch of into files? Or, is there a better way? Capistrano might come in extremely handy here depending on how many different servers you have available and what needs to go where. I think my approach would be to have a variety of after_save hooks that would generate a local copy of the files that a third party script could then push out to the servers as needed (ie. capistrano). Or, if it's a tremendous amount of data, perhaps have a "rebuild files" link per client that generates the files for that particular client which you can then deploy. In either case you should be able to use standard rails view templates just save the results where you want them as opposed to a .html file (ie. use render_string or whatever it's called these days). Alternatively, you could look at converting your services (web/mail/dns/etc) to look at the database directly for the information. I looked into this awhile ago and servers like apache, dovecot (pop/imap), postfix (smtp), proftpd, and powerdns can all be configured to use a database to find the information they need. Yes, it's a central point of failure, but it removes the need to deploy files :) > Is Rails even the best tool for something like this? Absolutely. Just start thinking in terms of: an customer has many domains a domain has many dns entries a domain has many email accounts etc.... and work that out first... that's the fun part :) Good luck! -philip
on 2007-06-13 07:30
I can only echo Philip's response - Rails looks like a good way to go for this app. I regularly create Rails apps without a database, and frequently without using ActiveRecord. The DB integration in Rails is nice, but it's by no means a requirement for your Rails app to use a DB. As Philip said, your app seems to break down nicely into a "has many/belongs to" structure, so maybe it would be useful to manage all your data in a database - however, even if not, you could still use Rails to create a Web front end to a collection of Ruby ssh/sftp-type functionality, and I think you'll find it at least as easy to do this in Ruby as any other framework. Once you've got your app built, you then leverage all the non-development Rails-y goodness - Capistrano in particular makes life very easy. Good luck Dave M.