|
gregben has asked for the wisdom of the Perl Monks concerning the following question:
I need/want to write a text-mode screen-oriented database UI application using as few perl modules as possible, and at the highest possible abstraction level, using modules that are well documented, widely used, and actively supported.
Asking for too much, aren't I?
I've been looking at Curses::Application and see there's going to be a bit of a learning curve (I've only written command-line stuff for decades).
Specifically, what I'm trying to do is write an application that presents the user with a data entry/query form (we use Putty/SSH) that will have static areas with field labels
and field boxes the user fills in, etc. Basically the same visual functionality as Oracle Forms (from back in the text-only days).
Of course I can use ncurses and write hundreds (thousands?) of lines of code to make it work, but the less code the better.
Why? Well, I need to adhere to the KISS principle, and SSH makes remote access easy without running a huge LAMP stack, web framework mess.
Why ask this here at perlmonks? Well, I want to use perl because perl is what I've been using (along with Oraperl) since 1992 to write reports and do all sorts of things with Oracle, and instead of trying to use Python or Ruby I want to stick with perl.
Thank you. |
Re: text mode screen-oriented application development
by mr_mischief (Monsignor) on Sep 07, 2007 at 19:08 UTC
|
Well, there's Curses, formats, heredocs, Text::Template,Term::Clui, PerlVision, Curses::UI, Term::TUI, Term::Menus, Term::ANSIMenu, Term::ANSIScreen, Term::Slang, Term::Cap, Term::Screen, Term::UI, Term::Newt, Term::ReadKey Term::Interact, Text::Flow, Text::Bind, Text::Repository, Text::Graphics, Text::T9, Text::ASCIITable::Wrap, and Text::MicroMason that all can deal with output, input, or both for text-based UIs. Of course that's not a complete list.
Of those, Term::SLang, Term::UI, PerlVision, Term::ANSIScreen, and Curses::UI seem to be fairly close to the overall functionality it seems you want.
Term::ReadKey and Term::Readline might be handy for taking the input. Text::T9 might be handy in certain circumstances.
Text::MicroMason, Text::Bind, Text::Repository could all be used to keep track of your forms if they are static screens.
Some of the flowing, wrapping, and capabilities checking modules could help you adjust to the dynamic terminal width you can have under PuTTY or another terminal emulator.
As for widely used, well documented, and well-supported, that's trickier. http://search.cpan.org has a rating system and update dates, and you can search online for any of those with Google or another search engine.
| [reply] |
Re: text mode screen-oriented application development
by Withigo (Friar) on Sep 07, 2007 at 21:18 UTC
|
I did something like this using the Curses & Curses::UI.
It ended up being a formbidable monstrosity
spanning several thousand lines(the saving grace being the maxim about "planning to build a second one--you will anyways"). And the initial justification was the same--avoid the overhead of a LAMP stack, avoid adding layers of web-related complexity, avoid locking into a certain gui lib, and ensure portability is as wide as possible. Debugging little quirks in Curses::UI which required custom overrides with Curses code was an especially painful. So I wouldn't recommend
text mode for anything but the most linear application.
Just think of it this way--go the Curses route and spend a month on your app. Or use a barebones web stack such as one of the very simple pure Perl HTTP servers(HTTP:Server::Simple), and some basic CGI and you can have the whole app done in an afternoon. Then just use Putty to establish the port forwarding to reach the web server.
It'll look better from a user perspective, the code will be more scalable and you'll save a lot of time. | [reply] |
Re: text mode screen-oriented application development
by andyford (Curate) on Sep 07, 2007 at 19:23 UTC
|
I would reconsider your rejection of a web app.
Your LAMP stack won't be too bad since I assume that your database is already in place or at least it's no different whether you use curses or web. If your app is simple enough, all you have to do is add a vanilla Apache instance and off you go. The CGI part is probably easier than doing curses and you can get a lot more free help with CGI.
Second, this sounds like you'll not have a huge userbase. Even if it's large, I'll bet it's well-defined numerically at least. I mean you probably know how many people are gonna use it, so you can evaluate pretty easily how much power you need for your web server and growth will be controlled since someone can presumably tell you "Hey we hired 10 more data entry folks" and you can add servers. In other words, the scaling headaches of typical web apps are probably not in your problem space.
Third, think of your career!
| [reply] |
|
|
And for text-mode access, use lynx or links. It's not especially hard to design a form that's perfectly usable in a text-based browser.
| [reply] |
|
|
I had the same thought, including menolly's thought of using links or lynx. This ignores one important fact, though. Session management and screen transitions are entirely different under CGI than under a text-mode, curses-like application. You're talking about multiple stateless HTTP connections vs. one self-contained application that repeatedly updates its own terminal.
The infrastructure may be no big deal, but the differences in working in a stateful vs. a stateless progamming model can be. There are plenty of workarounds to HTTP transport being stateless, including cookies and session ID hashes. Having a workaround isn't the same as keeping it all in one process, with a connection and variables that stay intact when the screen changes.
I don't mind working with HTTP's shortcomings, because most of my work ends up being delivered over the web. It's just part of life. However, when I have the chance to work with a local application and to simplify connection, session, and state retention management, I'm slow to give those up.
| [reply] |
Re: text mode screen-oriented application development
by swampyankee (Parson) on Sep 07, 2007 at 17:50 UTC
|
I've not used Curses::Application, so I can't comment on its ease of use or lack thereof, but I suspect that there is going to be a significant learning curve with any kind of GUI. That said, you could try Perl/Tk (which I've used for a broadly similar task), although I won't try to compare the learning curve, or use an HTML-based interface, and use CGI.
emc
Information about American English usage here and here.
Any New York City or Connecticut area jobs? I'm currently unemployed.
| [reply] |
|
|
