http://qs321.pair.com?node_id=637742


in reply to text mode screen-oriented application development

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!

non-Perl: Andy Ford

  • Comment on Re: text mode screen-oriented application development

Replies are listed 'Best First'.
Re^2: text mode screen-oriented application development
by menolly (Hermit) on Sep 07, 2007 at 22:47 UTC
    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]
Re^2: text mode screen-oriented application development
by mr_mischief (Monsignor) on Sep 09, 2007 at 22:50 UTC
    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]

In Section Seekers of Perl Wisdom