Free bigtop software for linux

Bigtop is a web application data language processor.

SYNOPSIS

See Bigtop::Docs::TentTut or Bigtop::Docs::Tutorial for how to create a Bigtop file. Bigtop::Docs::TOC is a guide to all of the documentation modules.
The real synopsis:

vi your_app.bigtop (or use tentmaker see Bigtop::Docs::TentTut)
bigtop --create your_app.bigtop all

Modify your bigtop file and try again:

bigtop docs/your_app.bigtop all

Bigtop is a language for describing the data of a web application. Usually this data will be stored in a relational database. Once you have a description of your data, you can generate a web application from it. This includes all the pieces you need like: the sql statements ready for feeding to your database command line tool, the httpd.conf you need to Include in the httpd.conf on your system, the modules that will handle the web requests, the models that make the database tables look like classes, etc.

If you need to alter the data model in the future, you can change your original description to match the new reality, then regenerate the application without fear of losing hand written code (though you may have to modify some of it to reflect the new reality).

FUNCTIONS

This module is really a place holder, but it does provide some developer routines (which are not exported):

write_file
use Bigtop;
Bigtop::write_file( $file_name, $file_content, $no_overwrite )

This attempts to write $file_content to $file_name and dies on failures of open or close. Further, if you pass a true no_overwrite flag, it will check to see if the file exists and refuse to overwrite it. In that case, the user gets a warning that the file has been skipped because it already exists. If you dont want the user to see the warning, turn off the Bigtop warning. To avoid fatal errors on write failures, wrap in an eval. Putting these together, we come to my typcial usage:

eval {
no warnings qw( Bigtop );
Bigtop::write_file( $some_output_file, $content, no_overwrite );
}
warn $@ if $@;
make_module_path

(Note that make_module_path uses File::Spec, so even though Unix directory syntax is shown below, the function should work in other places.)

use Bigtop;
Bigtop::make_module_path( $build_dir, $module_name );

This attempts to make all the directories from $build_dir to the home of the module. It assumes that lib comes immediately after $build_dir.

For example, a call like:

Bigtop::make_module_path(
/home/username/App-Name, App::Name::Subname
);
Attempts to make these directories:
/home/username/App-Name/lib
/home/username/App-Name/lib/App
/home/username/App-Name/lib/App/Name
/home/username/App-Name/lib/App/Name/Subname

It doesnt report failures. Making directories can fail because the directories already exist (in which case you probably dont care) or because they could not be written (in which case youll notice soon enough, when you try to write to them).

Bigtop::TentMaker is a Gantry App to Help You Code Bigtop Files.

SYNOPSIS

Start the tentmaker:

tentmaker [ --port=8192 ] [ file ]

Point your browser to the address it prints. Consult the POD for the tentmaker script for other command line options.

Bigtop is a language for describing web applications. The Bigtop language is fairly complete, in that it lets you describe complex apps, but that means it is not so small. This module (and the tentmaker script which drives it) helps you get the syntax right using your browser.

Unless you need to work on tentmaker internals, you probably want to read the POD for the tentmaker script instead of the rest of this documentation. You might also want to look at Bigtop::Docs::TentTut and/or Bigtop::Docs::TentRef.

Bigtop::Docs::TentRef is a Perl module for tentmaker reference (best viewed in html).

Intro

If you havent used tentmaker before, you probably want to start with its tutorial: Bigtop::Docs::TentTut. If you dont know what bigtop is, read Bigtop::Docs::About.

Unlike the tutorial, this document assumes you have started looking around tentmaker, but are wondering what all it can do. Here we will walk through it in detail. Consider this an encyclopedia of tentmaker (and dont complain too loudly if it is verbose and pedantic).

After a short section on the various ways to start tentmaker, we will turn to the tabs it offers and what they allow you to control. There you will find many screen shots to aid the discussion. If you cant see them with your current pod viewer, look them up here:

http://www.usegantry.org/images/tenttut or in the docs directory of the Bigtop distribution.

Bigtop::Docs::Cookbook is a Perl module for Bigtop syntax by example.

This document is meant to be like the Perl Cookbook with short wishes you might long for, together with syntax to type in your bigtop file and what that produces. In addition, many sections start with a simple question about what gets built by the backend in question.

This document assumes you will be editing your bigtop file with a text editor (it was written before tentmaker). You may also choose to maintain your bigtop file with tentmaker. Generally, the advice here governs what values you put in the boxes at the far right side of the Backends tab in tentmaker. Some of the other advice must be applied on the App Body tab. See Bigtop::Docs::TentTut to get started with tentmaker or Bigtop::Docs::TentRef for full details on using it.

For quick syntax reference consult Bigtop::Docs::Keywords for more complete information consult Bigtop::Docs::Syntax or Bigtop::Keywords from which tentmaker draws its on-screen information.

Bigtop::Backend::Init::Std is a Bigtop backend which works sort of like h2xs.

SYNOPSIS

If your bigtop file looks like this:
config {
build_dir `/home/yourname`;
app_dir `appsubdir`;
Init Std {}
}
app App::Name {
}

when you type

bigtop --create your.bigtop Init

or

bigtop --create your.bigtop all

this module will generate the build directory as

/home/yourname/appsubdir

Then it will make subdirectories: t, lib, and docs. Then it will make files: Changes, MANIFEST, MANIFEST.SKIP, README, and Build.PL. Finally, it will copy your.bigtop into the docs dir of under appsubdir.

As with any backend, you can include no_gen 1; in its config block:

config {
Init Std { no_gen 1; }
}

Then, no files will be generated. But, you can also exclude indiviual files it would build. Simply list the file name as a keyword and give the value no_gen:

config {
Init Std {
MANIFEST no_gen;
Changes no_gen;
}
}

If you are in create mode and your config does not include app_dir, one will be formed from the app name, in the manner of h2xs. So, in the above example it would be

/home/yourname/App-Name

Outside of create mode, the current directory is used for building, if it looks like a plausible build directory (it has a Build.PL, etc). In that case, having a base_dir and/or app_dir in your config will result in warning(s) that they are being ignored.

Gantry is a robust Perl-based Web application framework for Apache/mod_perl, CGI, and Fast-CGI.
Object-oriented design allows for a pragmatic, modular approach to URL dispatching. Gantry project supports MVC and initiates rapid development, offering an organized coding scheme for Web applications.
Main features:
- Plugin architecture
- Supports mod_perl 1.3 and 2.0
- Supports CGI and Fast-CGI
- Supports Template Toolkit and the ability to plugin other templating systems
- Inherited framework code for a standard CRUD application.
- Calendaring support
- Cookie management
- Form generation and validation
- User authentication: user, group and page-based
- Class::DBI integration
- Database and SQL utilities
- AJAX Support
- TinyMCE Support
- Code generation with BigTop

Bigtop::Docs::Tutorial is a simple case study of building a web app with bigtop.
Note on What to Read
This document explains how to build an app of moderate complexity by typing in a bigtop file. Since it was written, tentmaker has come along. It is a browser delivered editor for bigtop files, see Bigtop::Docs::TentTut for details.
If you need a simpler example than the one shown here, consider the one table address book example in Gantry::Docs::Tutorial.
Driving Idea
Many (not all) applications are mostly data managers. That is, they are really intermediaries between users and various tables in a database. A bigtop file is meant to be a single place to describe all (or practically all) facits of the data in an application. This includes at least:
The name and special features of each controller.
- The name of each table in the database.
- A description of each column (field) in each table in the database. This includes at least:
its name and SQL type
- the label the user sees for it when it appears on the screen
- what type of html form element the user uses to enter or update it
- how the data is validated and filtered on its way into and out of the database (filtering not yet supported)
- which table the field refers to if it is a foreign key
- etc.
All of these things, and more, are described in a Bigtop file. That file can be given to bigtop to build the application. Once it is built, it can be safely rebuilt so that only the generated bits are changed (this is accomplished by maintaining a clean separation between generated and hand edited files, and by config options in the bigtop file).
Notice that nothing in the above has committed you or me to any particular web application framework, data modeling scheme, templating system, or web server. Bigtop is neutral (think big tent), at least for Perl apps delivered via the web.