I'm searching for something of which I don't really know the name of.
From time to time, I have to develop a small tool for a small group of users which is basically a web frontend to one or two database tables. It's very basic and something which one could do in a spreadsheet (without the problem that only one user can have the file open at a time and something like Sharepoint is not available) or for what one would have chosen MS Access in the 90s. Google Docs would also be possible, but we'd like to keep our data in-house. (I for myself just use phpMyAdmin for that, but it's not suitable for not tech-savvy end-users.)
So I'm looking for a tool which generates/provides a forms-based Web interface for simple models or database schemes that I create. First, is there a common name for such a thing? And second, does anyone have recommendations (preferably open source and/or free)? The closest thing I've come to is the scaffold generator in Ruby on Rails, but it's very basic and not optimal since it's only designed for generating prototype could which one should edit later, and last time I have looked at it, it was not possible to differently updating your model, i. e. regenerate code for model changes but preserving the manual changes of your code.
Thank you.
You're looking for Web UI Framework. Look into http://agiletoolkit.org/
Related
I am wondering if there is a standard pre-built web application for Rails which has all the basic functionalities like user login, user profiles, profile image uploader, comments, search, maybe payments and a set of other usual web application features all bundled and ready to use and extend.
I like how Twitter bootstrap comes with a set of pre-built interface functionalities and styles, which you can start using and modify later. I am looking for something similar that can allow me to quickly set up a working application and go from there.
Does such a framework exist?
There are numerous examples out there.
However, there are two things you should really do:
Read the license to make sure you can use it they way you are thinking of using it.
Ensure you understand the design decisions and choices the original authors made. You will end up in a world of maintenance pain if you just copy cargo-cult style without understanding the tradeoffs others have made with their design decisions.
Any one of the links listed has enough to get you started. They may not have all of the features you listed but together they probably have all of your bases covered. You will have to put in some effort to get all those features working together though.
The RailsApps project is great because they all have tutorials that walk through the basic setup. They are also all built using the Rails Composer tool, which lets you pick and choose certain options for your app.
My friend has setting up a database for a Ragnarok Online server, and he wants me to code the relative website, which is going to use some of that data (and obviously, i'll have to add tables for the news system, website accounts, etc). Since i'm learning RoR i was going to do it that way.
I have a few "best practice" questions related to this :
Should I create a different database for the website, since it's going to have its particular data alongside the game data ? (i already have a few clues to link multiple databases with Rails, but that seems too much of a hassle for what it is).
If not, do i have to create Model/Controller for each of the tables composing the database, despite the fact that i'm not going to use 90% of it ? Or just the ones that i need ?
An example of this problem : the game database has its own "user" table, but i have to have another "user" table for the website, and do some Joins between those two. So, what's the best practice here ?
Uhm, best practice is not making your own user table. This will cause you much pain. Best practice? Use an API. Expose the game's database in some way to your website, and fetch that info with external requests in your web application.
The reason why making a second user table is a hassle:
1) You'll constantly have to update it, pulling data from the original
to keep it up-to-date.
And I mean furthermore, you're gonna have to create a CRON job or something pulling data from that original table to keep it up to date. Yuck. Also what if that CRON job makes a mistake? (It will)
2) It's almost inevitable that there will be inconsistencies if two
separate tables are maintained. Are you sure your web application is
really fail-proof?
Update:
What you're gonna need is essentially a second Rails application that acts as a REST API for that database. For a good idea of what REST is, I'd read through this to get you started: http://tomayko.com/writings/rest-to-my-wife
Once you have a good understanding of that, start making your app, and test if it's working by using tools like cURL to send requests to your API.
Once you have that done, I'd take a look into the Ruby rest-client gem like Nobita mentioned. This is what you're going to use from your web application to request information from your API application.
Just let me note, I think this would be a terrible first Rails project, unless you're already really well versed in other web development tools, preferably MVC frameworks.
a friend of mine wants to create a simple inventory database that can be deployed on the web.
He has had a lot of experience with Database tools like Paradox. Moreover he has experience with writing Macros and programs with Basic, and even a bit of C++ experience. He uses Windows and Mac OS X, though mostly Windows.
If the requirement of having a web application wasn't there I would recommend MS Access.
Currently I see these options:
A) Ruby on Rails
Pros:
easy to start out (even on Windows?!)
at least from a programmers point of view perfect to create simple CRUD applications
can be deployed at virtually every popular Cloud hoster
I could easily assist if there were problems
Cons
ActiveRecord is from my point of view too technical
Designing forms requires ability to fiddle around with CSS and HTML
B) VB.Net
Pros
he has experience with simliar programming languages
easy to create forms and possible to deploy CRUD apps on the web
Cons
can be deployed only at few hosters (only Azure?)
simple problems can be quite difficult to solve in VisualBasic
C) Cold Fusion, ...?!
Pros/Cons
I have no idea
I am happy to hear about your suggestions.
Thanks, Philip
I have yet to use it, but the http://www.force.com/ platform (which salesforce.com is built upon I guess) is supposed to make it easy to develop data driven apps for more like business analyst roles. There is a cost to host it, but one app isn't that much on a monthly basis and the 30 day free trial would let you figure out if it worked for you or not.
If you are looking for database application frameworks for people who are not software developers, you might look at LightSwitch. It is designed for that particular demographic.
As much as I like Ruby on Rails AND the .Net platform for database-driven apps, they are both designed for developers to use. Going to something designed for your task might just be what your friend needs.
http://www.microsoft.com/visualstudio/en-us/lightswitch
Check out the examples on agiletoolkit, the php framework with jquery and php form examples. It's php with some jquery but to get a basic application up and running against a database, you dont need to know much php at all.
The five lines are the code shown on the left of the image are all thts needed to create a CRUD based on a database table with both a form and a grid with specified columns. It will open a jquery dialog for ADD and EDIT and uses AJAX to update the form.
It also has built in functionality to add one click sorting on the column headings, pagination so you dont get an endless grid on one page but get << < 1 2 3 .. N > >> style links to page through the results set and a search box to filter the results to a specified subset.
Note the colours are added by CSS and can be removed.
The second negative point for Rails ("Designing forms requires ability to fiddle around with CSS and HTML") could be easily mitigated with the use of a gem that generates forms (like formtastic or simple_form).
Apart from Rails I would suggest Monk which is a lighter-than-rails ruby-based web framework. Its components are loosely held together and there are many skeletons (web app templates) to choose from.
Pros
multiple skeletons to choose from
very light/minimal (a new developer will not get lost in the myriad of files and folders that Rails is)
as easy to deploy as Rails (is rack based)
Cons
does not seem to be as well-maintained as Rails
most Ruby stuff don't play well in Windows (AFAIK)
PS: on the second positive bullet of rails (and ruby) I would like to add Heroku which is a GREAT service for getting-started projects.
Building CRUD Apps using ZK Studio is very easy.
CRUD Apps can be built in 5 to 6 steps. Check it out.
Rails is the most innovative and easy approach to creating crud apps ever.
There are plugins like active_scaffold and hobo that allow you to create CRUD apps without having to write almost any code.
I am trying to build a CMS I can use to host multiple sites. I know I'm going to end up reinventing the wheel a million times with this project, so I'm thinking about extending an existing open source Ruby on Rails CMS to meet my needs.
One of those needs is to be able to run multiple sites, while using only one code-base. That way, when there's an update I want to make, I can update it in one place, and the change is reflected on all of the sites. I think that this will be able to scale by running multiple instances of the application.
I think that I can use the domain/subdomain to determine which data to display. For example, someone goes to subdomain1.mysite.com and the application looks in the database for the content for subdomain1.
The problem I see is with most pre-built CMS solutions, they are only designed to host one site, including the one I want to use. So the database is structured to work with one site. However, I had the idea that I could overcome this by "creating a new database" for each site, then specifying which database to connect to based on the domain/subdomain as I mentioned above.
I'm thinking of hosting this on Heroku, so I'm wondering what my options for this might be. I'm not very familiar with Amazon S3, or Amazon SimpleDB, but I feel like there's some sort of "cloud database" that would make this solution a lot more realistic, than creating a new MySQL database for each site.
What do you think? Am I thinking about this the wrong way? What advice do you have to offer in this area?
I've worked on a Rails app like this, and the way it was done there was named-based virtual hosts, with db entries for each site running. Each record was scoped to a site if necessary (blog posts, etc.) while users would have access to all sites running out of that db. Administrator permissions could be global or scoped to one or more sites.
You're absolutely correct when you say you'll reinvent the wheel a million times during the project. Plugins will likely require hacking on top of the CMS itself.
In my situation, it ended up being a waste of almost a million dollars of company money to build that codebase to run multiple sites while still being able to cater to the whims of each client site. It worked, but was not very maintainable due to the number of site-specific hacks that subsequently entered the codebase. You may be able to make it work if you don't have to worry about catering to specific client sites running on your platform.
In the end, you're going to need a layer of indirection to handle the different sites regardless of methodology. We ended up putting it in the database itself. If you go with the different-db-for-each-site method you mentioned, you'll put that layer in your code instead. I'm not sure which one is the better method.
I hope you're able to pull this off. I failed.
Also, as I learned today, Heroku offers postgres instead of mysql for rails apps.
There's James Stewart's Theme Support Plugin for Rails 2.3, and lucasefe's themes_for_rails gem for Rails 3+.
I just started using the 2.3 version and it's working well so far.
I was wondering if somebody has some insight on this issue.
A little background:
We've been using Rails to migrate from an old dBase and Visual Basic based system
to build internal company IntrAnet that does things like label printing,
invetory control, shipping, etc - basically an ERP
The Dilemma
Right now we need to replace an old customer-facing website that was done in Java, that
would connect to our internal system for our clients to use. We want to be able to pull information like inventory, order placement, account statements from our internal system and expose it to site live. The reason is that we take orders on the website, through fax & phone and sometimes we have walk-ins. So sometimes (very rarely thou) even a short delay in inventory update on our old Java site causes us to put an order on backorder, because we sell the same item to 2 customers within half an hour. It's usually fixed within one day but we want to avoid this in the future.
Actual Question
Does anyone have any suggestion on how to accomplish this in a better
way?
Here are three options that I see:
a) Build a separate Rails app on a web server, that will connect to the same DB that our internal app connects to.
+++ Pluses:Live data - same thing that our internal apps see, i.e. orders are created in real time, inventory is depleted right away
--- Minuses: Potential security risk, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
b) Build a separate Rails app on a web server, that will connect to a different DB from our internal app.
+++ Pluses: Less security exposure.
--- Minuses:Extra effort to sync web DB and internal DB (or using a web service like REST-API), extra code to handle inventory depletion and order # creation, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
c) Expose internal app to the web
+++ Pluses: all the problems from above eliminated. This is much "DRY"er method.
--- Minuses: A lot more security headaches. More complicated login systems - one for web & one for internal users using LDAP.
So any thoughts? Anyone had similar problem to solve? Please keep in mind that our company has limited resources - namely one developer that is dedicated to this. So this has to be one of those "right" and "smart" solutions, not "throw money/people/resources at this" solutions.
Thank you.
I would probably create separate controllers for the public site and use ActiveResource to pull data from you internal application. Take a look at
http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html
http://api.rubyonrails.org/classes/ActiveResource/Base.html
Edit - fixed link and added api link
I would go for a. You should be able to create the controllers so that they are re-usable.
Internal users are as likely to duplicate data as external users.
It's likely that a public UI and an internal, for-the-staff, UI will need to be different. The data needs to be consistent so I would put quite a bit of effort into ensuring that there is exactly one, definitive database. So: one database two UIs?
Have a "service" layer that both UIs can use. If this was Java I would be pretty confident of getting the services done quickly. I wonder how easy it is in Ruby/Rails.
The best outcome would be that your existing Customer Java UI can be adapted to use the Rails service layer.
Assuming you trust your programmers to not accidentally expose things in the wrong place, the 'right' solution seems to me to have a single application, but two different sets of controllers and views, one for internal use, and one for public-facing. This will give you djna's idea of one database, two UIs.
As you say having two separate databases is going to involve a lot of duplication, as well as the problem of replication.
It doesn't make sense to me to have two totally separate apps using the same database; the ActiveRecord part of a Rails app is an abstraction of the database in Ruby code, therefore having two abstractions for a single database seems a bit wrong.
You can also then have common business rules in your models, to avoid code duplication across the two versions of the site.
If you don't completely trust your programmers, then Mike's ActiveResource approach is pretty good - it would make it a lot harder to expose things by accident (although ActiveResource is a lot less flexible and feature rich than ActiveRecord)
What version of Rails are you using? Since version 2.3 Rails Engines is included, this allows to share common code (models/views/controllers) in a Rails plugin.
See the Railscast for a short introduction.
I use it too. I have developed three applications for different clients, but with all the shared code in a plugin.