david@geac.UUCP (David Haynes) (08/28/87)
Does anyone know of a product which provides forms/menuing facilities in a unix environment? I know that some of the various database vendors do sell forms systems with their products, but I am looking for something which we could get in source form in order to add some of our concepts to. Minimal requirements would be: Source is available. (UNIX & C) The system works on most ASCII asynchronous terminals There is a clear division between the presentation and application interfaces. It is not tied to a particular (database) program. We have been looking for such a thing and so far have only found one which meets even these minimal requirements. It problem is that it does not currently run on UNIX. (They are porting it however). If you know of any packages we should be investigating, please send email to either myself or Sigrid Grimm (geac!sigrid). Many thanks to those who respond. -david- -- David Haynes [ mnetor, yetti, utgpu] ! geac ! david Geac Computers International Inc. Wise words in mouths of fools 350 Steelcase Road,Markham, Ontario, do oft themselves belie. CANADA, L3R 1B3 +1 416 475 0525 x 3420
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (08/29/87)
> Does anyone know of a product which provides forms/menuing > facilities in a unix environment? ... > Minimal requirements would be: > > Source is available. (UNIX & C) > The system works on most ASCII asynchronous terminals > There is a clear division between the presentation and > application interfaces. > It is not tied to a particular (database) program. Back when I was at Picture Elements Ltd (now defunct) I briefly used a forms building package on a 4.1bsd VAX. It was freeware (but the term was not in use at the time) and only depended upon curses to work on text terminals. We had the source code for it. It's been a long time, but if I remember correctly, this package had a description language for building the forms and for specifying the behavior of the fields, plus some rudimentary type/range data checking. I'm sorry to say I don't remember what it was called, but if any PEL alumni are reading this, maybe one of you recalls its name and who wrote it, or where it came from. Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
ries@trwrb.UUCP (Marc Ries) (08/31/87)
In article <16191@teknowledge-vaxc.ARPA> mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: >> Does anyone know of a product which provides forms/menuing >> facilities in a unix environment? >... >> Minimal requirements would be: [...] >I'm sorry to say I don't remember what it was called, but if any PEL alumni >are reading this, maybe one of you recalls its name and who wrote it, or where >it came from. > I believe you mean the: FORMS Subroutine Package (c) 1982 Mathew Diaz John Hopkins University -- Marc A. Ries sdcrdcf!---\ ihnp4!------\----- trwrb! --- ries
gilbert@hci.hw.ac.uk (Gilbert Cockton) (09/14/87)
In article <1275@geac.UUCP> david@geac.UUCP (David Haynes) writes: > >Minimal requirements would be: > > There is a clear division between the presentation and > application interfaces. Sure you want this? Field validation by definition is application-dependent. Perhaps what you want is a good two-way interface between the forms manager and the back-end database. Most UI software only handles the UI->back-end mappings, making good semantic feedback impossible. P.S. - a clear division needs bridging - what's your bridge going to be? If you want to talk to someone, you need to know something about them. Strict separability only matters for prototyping, customisation and multiple UIs. Otherwise the cost of separability is not balanced by any major gains. -- Gilbert Cockton, Scottish HCI Centre, Ben Line Building, Edinburgh, EH1 1TN JANET: gilbert@uk.ac.hw.hci ARPA: gilbert%hci.hw.ac.uk@cs.ucl.ac.uk UUCP: ..{backbone}!mcvax!ukc!hwcs!hci!gilbert
gordon@hci.hw.ac.uk (Gordon Howell) (09/16/87)
Posting-Front-End: GNU Emacs 18.41.4 of Fri Sep 4 1987 on glenlivet (berkeley-unix) In article <120@glenlivet.hci.hw.ac.uk> gilbert@hci.hw.ac.uk (Gilbert Cockton) writes: In article <1275@geac.UUCP> david@geac.UUCP (David Haynes) writes: > >Minimal requirements would be: > > There is a clear division between the presentation and > application interfaces. Sure you want this? Field validation by definition is application-dependent. Perhaps what you want is a good two-way interface between the forms manager and the back-end database. Most UI software only handles the UI->back-end mappings, making good semantic feedback impossible. Certainly field validation is application-dependent, but I would suggest that there is a limited set of field validation operations that are ever used in practice. Simply implementing these as part of your forms description; and providing a call-back mechanism for oddball validation requirements might solve your objection as well as provide complete separability. P.S. - a clear division needs bridging - what's your bridge going to be? If you want to talk to someone, you need to know something about them. Strict separability only matters for prototyping, customisation and multiple UIs. Otherwise the cost of separability is not balanced by any major gains. Except the possible gain of being able to match company X's DBMS to company Y's forms package. Then the problem devolves :-) into a data flow standardization question... (Or we can all argue the definition of "strict separability" which is the same problem in different clothes.) I agree that right now I'd prefer *working* tools; but I think our goal should be to provide UI software architectures that allow us to pick the best tool for our application ("best" being defined by useability, cost, politics or however individual organizations like to pick 'em...) Is this architecture possible? I'm banking on it... [I use the term "forms", but understand that this can really be any db interaction technique...] -- Gordon Howell gordon@hci.hw.ac.uk Scottish Centre for Human Computer Interaction Edinburgh, Scotland
daveb@geac.UUCP (Brown) (09/17/87)
In article <120@glenlivet.hci.hw.ac.uk> gilbert@hci.hw.ac.uk (Gilbert Cockton) writes: >In article <1275@geac.UUCP> david@geac.UUCP (David Haynes) writes: >>Minimal requirements would be: >> There is a clear division between the presentation and >> application interfaces. >Sure you want this? Field validation by definition is >application-dependent.... There are two points being discussed here: 1) forms-manager to back end interface 2) seperation of form and content I'd be willing to bet David was talking about 2 (although I haven't shouted over the wall to find out :-). -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
mjr@well.UUCP (09/18/87)
In article <120@glenlivet.hci.hw.ac.uk> gilbert@hci.hw.ac.uk (Gilbert Cockton) writes: > > Field validation by definition is >application-dependent... No it isn't! In a fully functional RDBMS environment, field validation is the function (ultimately) of the data dictionary! The application developer need only check the return values from an insert/update/delete and determine which fields faild to pass muster. I am doing that now in a large project using Cincom's Supra DBMS. This DBMS passes back three levels of error messages. The first tells you if everything went ok or not. The second tells you what the worst failure was (if any), and the third enables the programmer to determine exactly which field(s) failed their validity checks. This is the way it should be done...