Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
Yet Another Web Frameworkby philcrow (Priest) |
on May 10, 2006 at 20:17 UTC ( [id://548551]=perlmeditation: print w/replies, xml ) | Need Help?? |
SUMMARYWhile the world may need a new web framework about as badly as it needs a new conflict in the Middle East, we feel the urge to share ours. Gantry is the third generation of a web framework, which has been running many of our internal and external sites for years, but which is now making its debut as an open source project (under the same license as Perl). Check it out at http://www.usegantry.org. Gantry features:
Why the Name? A gantry is a scaffold for building and servicing rockets. Rails may be nice, but rockets are faster and have more destinational flexibility. Another more practical meaning for gantry in our context is the structure which holds signs or signals over a road or railroad. This is a permanent structure often outlasting the signs initially placed on it. Gantry principles:
Don't think of Gantry as a scaffold or falsework. Think of it as a structural support which will outlive your app. Gantry was developed at Sunflower Broadband (a cable/internet service/phone provider in Lawrence, KS).
EXAMPLEHere is the required world greeter to show the simplest Gantry app.
First, we need the operative code (which should be stored in HiWorld.pm):
See Gantry::Docs::QuickStart for additional discussion, including other ways to deploy an app (like actual CGI or our favorite mod_perl). Then move on to Gantry::Docs::Tutorial.
Then we need to deploy the app. We have several choices. The first and easiest choice is a stand alone test server. It might look like this: You can execute this, giving it an alternate port number if you don't want 8080. Don't let the appearance of CGI in the above fool you. This is a persistent web server which is quite fast. It does use the Gantry CGI engine internally, but it doesn't spawn any processes.
LONG FORMWhat we want:Our business relies on delivering apps to our staff and to our customers. Gantry is designed to meet the needs of a company like ours. In particular, we have these hot button issues:
Configuration
We have lots of applications. While we traditionally configured them via PerlSetVars in our httpd.conf, that system breaks down. First, we sometimes deploy the same application on different servers (say to deliver it to customers and to customer support staff). We want those deployments of the same application to share configuration. Second, we sometimes deploy multiple instances of the same application (say to deliver the same product to two divisions of the company). We often deploy these in the same apache instance. We want them to be able to share their common configuration while allowing them to have differences (like database connection information). Third, we almost always have some batch processing (think cron jobs) associated with our apps. We want them to use the same configuration as the web app.
So, the boss designed Gantry::Conf to solve all of the problems we were having with our old configuration scheme. See Configuration Flexibility or Gantry::Conf::Tutorial for details, but allow me to summarize. With a single file on each box, you can describe all the app instances which run on that box. When describing each instance, you may specify multiple flat files of conf info. In addition, you may specify any url lwp understands to retrieve conf from foreign machines (yes you need a security plan). Finally, you may also put config variables directly into the one-stop conf file to be shared by multiple app instances. Simply calling one method, with your instance name, returns your conf, no matter where it came from. And the best part is: You don't have to use Gantry to use Gantry::Conf. Straightforward Dispatching
We want a scheme so simple that a sysadmin, fresh from a roaring party, can cover for us while we are out of town. This means he must be able to take a broken url reported by some user and quickly find the code connected to it. To this end Gantry uses a simple dispatching scheme with few tricks.
While no dispatching scheme capable of supporting complex apps is trivial, ours is pretty straightforward. Even our Python loving admin understands it. Flexibility
Some people want a framework which makes all choices for them. If you are one of those people, Gantry is not for you. We don't want to force a single way of doing any given thing into the framework. We want to make it easy to use the tools that spring to mind for the task at hand, regardless of whose mind contains the spring.
For example, one of our developers taught us to like the idea of postpending method arguments onto the url. We then shift them in to lexical variables. You might prefer to use a query string. Take your pick, Gantry supports both with easy syntax. As another example, if you have standard CRUD work to do, you can use Gantry::Plugins::AutoCRUD. This makes a lot of assumptions, but does all the work (except defining the form and its validation). If you need more control, there is Gantry::Plugins::CRUD. It's so flexible that it doesn't even care if you use a database. Yet it still removes the tedium of form validation. Code Generation
We are demanding. We want a lot from our tools including our generators. Further, we have a philosophy (at least I do) about web delivered apps. Most of them are centered around the data they manage. Hence, building a new one is primarily an exercise in data modeling. Fred Brooks said this well in The Mythical Man-Month:
Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.This led me to develop bigtop: a language for describing data models. We already have SQL to specify the names, relationships, and format of data. But, for me, this is not enough. I want a single place to define the columns in a table in full detail. This includes not only the name and SQL type, but what its label should be for the user, how wide the input box should be on the input form, whether the field is required, what constraints should be applied during validation, etc. Bigtop allows me to describe all this and a lot more. Further, when my data model changes, as it always seems to, bigtop can safely regenerate the app, with the changes but without overwriting custom code I've written. The main drawback to bigtop is learning its syntax, which while simple in structure is quite rich in keywords. This led to the development of tentmaker, a web delivered editor for bigtop files. It comes with a built-in skeleton to get you started. I'll have more to say about bigtop in a later meditation. Phil
Back to
Meditations
|
|