fp screen display

[Fairlight]

The honourable and venerable Jay Ashworth spoke thus:
> On Mon, Feb 06, 2006 at 09:38:22AM -0800, Richard Hane wrote:
> >    Curiosity  and question....  why  not program  your  input  and review
> >    screens  as  html  pages?   Certainly this would support most size and
> >    character font / style / size questions.
> > 
> >    There  may  be  reasons why not and I am not suggesting it's the final
> >    answer but is that not a temp work around.
> 
> The primary reason why not is that it's *insanely* complicated to do.

It's -not- that hard.  And, assuming perl is installed, I have a $20
program one can license which takes your HTML page and converts it into a
CALLable PRC table.  Design it in anything you like, any HTML editor at
all, and just run it through this.  If you need to make something dynamic,
just edit the appropriate places.

Cuts down on a good 80-95% of the time compared to trying to do all your
HTML (with JS, no less) in fP code itself.

> And, um, requires buying extensions that also cost money, in addition
> to time.

fPcgi or OneGate or something else, yeah.  You know which -I- recommend.  :)

That's quite a bit pricier than the HTML converter, but at least with
OneGate it's a one-time fee, and upgrades are free.  The same hasn't been
true of fPcgi.  $995 for OneGate.  Now, if you wanted to segregate the
data server from a public web server through a firewall, I have a special
bridge that goes between two OneGate's.  You get dual-layer security
(application-level firewalling on each server, forged requests blocked on
public server and not taking up user count, etc.), and your public machine
basically acts just like the private machine as far as any requests made
of onegate to access filePro.  That's pricier still, but more secure as it
keeps your fP data files off the public web server.  Another real benefit
is that you can have one internal server available for the data, but your
main content for a site that's not wholly fP-based can all be based on some
generic hosting service somewhere that would -never- let you use filePro
on the system, but you transparently serve the data as if you were.  That
setup costs more, but can be worth it if you need the functionality.

But I'd dispute "*insanely*" difficult, certainly.  It's -way- easier than
many routines I've seen to do dummy-field-based header/detail.  In the end,
at least with OneGate, you're getting values from a lookup, and you're
writing files to disk.  Neither is difficult.

> Oh, wait.  Maybe *that*'s why we don't have scrollable screens.  :-)

You know, scrollable fields I can see.  You know, a la dcabe type entry
scrolling.  But a scrollable screen to me sounds no more useful than having
two screens and moving between them.  In either event you can't see all the
data at once.

All -I- think they really need to do is honour ROWS and LINES (moreover,
the tty settings that correlate), and enforce a rule where *clerk and
dscreen won't work on a screen whose raster is larger than the available
real estate.  It's really that simple.

mark->