[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Curses RAD executables
From: |
Steve Litt |
Subject: |
Curses RAD executables |
Date: |
Sun, 9 May 2004 11:28:07 -0400 |
User-agent: |
KMail/1.5.3 |
Hi all,
As you know, I'd like to create a RAD environment with three Curses
executables:
rad_menu
rad_form
rad_picklist
Each of these three executables would be written in C, licensed GPL. Each is
completely data driven, such that every aspect of the form, picklist or menu,
both data and metadata, is defined in data passed via stdin or a file. These
executables are linked with business data and business logic via a glue
language such as Perl, Python, or even Bash, C or C++. Look at the
advantages:
1. Executables are more modular than any other type of linkage.
2. Portable on any Nix box
3. Fast development
3.5 Ability to write front ends to create the data for these executables
4. Ability to fully utilize Unix pipes and redirects in the application
5. The data driving the executables can be ANY license without compromising
the GPL of the executables themselves.
The big challenge is creating a persistent Curses across all executables and
scripts. Here's my plan:
I'll have a function called rad_dump() that dumps every window as a file, and
saves those files as a stack implemented as a doubly linked list. It also
saves various other data. Then the next executable calls a rad_recall() that
restores the exact environment of the preceding executable. The rad_dump()
uses the Curses putwin() to store each window, pushing its filename on the
stack. The rad_recall() function uses the Curses getwin() to get the windows
back.
Unless I've overlooked something, this creates the equivalent of a persistent
Curses across various executables. And it doesn't just save an 80x25 screen
-- it saves all windows as windows so that windows created in one executable
can be destroyed in the next, revealing the underlying window. In this way I
believe that these glued together executables will look to the user basically
as a single executable.
The executables described above are the interface to the user. I anticipate
the interface to the data being the psql executable (or mysql if you swing
that way). The business logic will be written by the programmer, in Perl,
python, etc. Forms and their contained fields will have some business logic
in the form of validation routines and fields calling picklists.
Comments are appreciated.
SteveT
- Curses RAD executables,
Steve Litt <=
- Message not available
- Message not available