From damian@uk.ac.rl.inf Tue Oct 31 17:33:18 1989
Received: from rl.inf by abacu.strath.ac.uk; Tue, 31 Oct 89 17:33:12 GMT
Received: from pyr-a by inf.rl.ac.uk; Tue, 31 Oct 89 17:03:14 GMT
Date: Tue, 31 Oct 89 17:02:30 GMT
From: damian@uk.ac.rl.inf
Message-Id: <8910311702.AA21681@pyr-a>
To: james@uk.ac.strath.abacu
Subject: env vars & dups
Cc: joe@uk.ac.strath.abacu
Status: R

1) Firstly, I suspect that your ReplEnv routine will leave out the
first '/' after the env variable and anything before the first '$'.
Secondly, it won't cope with "{..}" syntax or nested variables.
(Sorry about the nitpicking, just thought you'd be interested - as
it isn't important in the IFE, it doesn't really need fixing.)

2) I don't see the point of allowing shell variables to be referenced
in the startup scripts.  I agree the BB, etc should accept absolute or
relative to $IFE_HOME pathnames - but what extra does allowing other
options in a general & public version of the startup script.  I assume
the bb_clients file will stay in $IFE_HOME/lib/startup/ and be accessed
by everyone - personalization being done by providing an alternative
IFE_HOME and lib structure.  Putting anything other than $IFE_HOME in,
eg bb_clients, forces ALL other users to have values for that variable
in their environment.  This would be a major inconvenience to me as my
environemnt is already overcrowded - I cant run ECSTASY from my normal
login because it needs so much environment space (when added to my
normal environment it overflows) and deleting variables doesn't reclaim
the space used.
Again, it isn't that important, so let the changes stand.  However, you
need to be careful that you're not forcing others to carry around a lot
of garbage just to overcome issues specific to your setup - you can
personalize the ife just as well as anyone else and there is no reason
why you have to run the "distribution" version as your standard version.



Field duplication

The duplication handler should go in the dialog handler.  The forms
package should handle fields simply and not be concerned about how
the application (in this case the DH) relates these fields.

The protocol has to be able to specify several things
1) the creation of a duplicate field(s) - eg
	create a duplicatable field				ESSENTIAL
	create a field from scratch - ie not on a proforma	NICE
	create (n) duplicate(s) of 1st field			ESSENTIAL
	create another (n) duplicate(s) of 1st field
		to appear after the last (nth) field		ESSENTIAL
	create (n) duplicate(s) of ith field
		to appear after the last (nth) field		NICE
	create (n) duplicate(s) of ith field
		to appear after the last (ith) field		MAYBE NOT
			(NICE => in the next release :-) )

2) address any of the duplicate fields uniquely and treat it identically
to any other field - eg
	get the contents, etc of the ith field			ESSENTIAL
	hide/show the ith field individually			ESSENTIAL
	be told that the user has put xyz into the ith field	ESSENTIAL

Your forms package protocol seems to merge the creation and the display
of the fields - thinking of "Duplicate" as a display command gives the
behaviour of creating a field if necessary to perform a display command
This is a powerful concept, but has to be handled with care (and must
be retrofitted to all fields for consistency) - I don't think it is
desirable to start something like this now (next release?).  Perhaps
you could split the functionality of Duplicate into 2 (or more) cmds.
Also, there is no way of having a hole in the list - ie a turned off
field where later fields are on - probably needed.


The protocol used in the existing Prolog is that duplicatable fields
are indicated by having a trailing $ in their name.  These fields
ALWAYS have at least one argument, of which the 1st gives the field
number in the list of similiarly names fields - eg

	coord_x$(_N, _Coord):-		%% the '_N'th coord_x field.

I would like the BB protocol to maintain this, storing the data as

	coord_x$	0	24.3
	coord_x$	1	0.0
	coord_x$	2	0.0
	coord_x$	3	24.3
	.... etc
	
Thus the dialog handler should convert from this protocol to whatever
commands are necessary for the forms package - eg conver to coord_x[n]
form.  I would also like to be able to treat duplicatable fields as
normal when creating them - eg
	to create the 4th field (and others up to this?) either
		duplicate	coord_x$	3
	or
		new_query	coord_x$	3
	to show 4rd field
		ask_user	coord_x$	3	

Some code along these lines already exists in ExpandFormMsg in ife_dh.c
but would need modification. Could you do this - or can you give me the
form package commands necessary to create & access duplicated fields.

Damian

        Damian Mac Randal                Snail Mail: Informatics Dept,
                                                     Rutherford Appleton Lab,
INTERNET: damian%inf.rl.ac.uk@nfsnet-relay.ac.uk     Chilton,    Didcot,
  BITNET: damian%inf.rl.ac.uk@ukacrl.bitnet          Oxon.  OX11 0QX,    U.K.
    UUCP: damian%inf.rl.ac.uk@ukc.uucp        Phone: +44 235 445403
   JANET: damian@uk.ac.rl.inf                   Fax: 445831  Telex: 83159

