Paradigms for CGI application development?

[Scott Penrose]

On Thursday, Nov 7, 2002, at 07:34 Australia/Melbourne, David Dick 
wrote:
> i would have thought that the correct way of looking at it is not 
> trying to emulate a GUI environment at all.  The problem essentially 
> (unless i have missed something :)) is that we want a confirmation 
> step and we want to be assured that the transfer only happens _once_.

Essentially I would agree with you. But the request was made (I think 
by Michael Stillwell) that it would be nice to use a GUI design 
metaphor. So I was just supplying a way that could b achieved.

> This can be achieved with a minimum of fuss with the following steps.
>
> provide a confirmation screen that has the details of the transfer 
> with a confirmation URL something like
>
> /transfer?State=Confirm&TransferId=[% transfer_id %]&LastUpdated=[% 
> last_updated %]&LastUpdatedBy=[% last_updated_by %]&

Yes of course, this is the way it would normally be done.

The conversation was just exploring the idea of using the GUI as a 
paradigm for development of CGI.
I think it was an interesting thought, but I think that it is probably 
not suitable. The only reason to probably do it is to allow users to 
write 'macros' to a web application.

eg: Say a user wanted to write really simple code like.

	X = getAccountNumber();
	if (X && getConfirm('Add $25 to your account?")) {
		addMoney(X, 25.00);
	}

It is certainly simple :-)

> where the transfer_id is the UID for the Transfer Object and the 
> last_updated and last_updated_by fields are a representation of who 
> and when last modified this transfer object.
>
> assuming that the business has no processes at all... no names, no 
> pack drill :), multiple people can all get to this same step and 
> attempt to confirm the transfer at the same time.
>
> therefore the transfer script (when it gets a State=Confirm etc, etc) 
> must
>
> 1) Obtain a write lock on the transfer object (SELECT....FROM transfer 
> WHERE transfer_id = $transferId FOR UPDATE)
> 2) Compare (SELECT last_updated_by, last_updated FROM transfer WHERE 
> transfer_id = $transferId) with the LastUpdated and LastUpdatedBy 
> values obtained via  $cgi->param().
> 3) If they are the same, then no-one has modified the object since we 
> last looked at it.  If they are not the same, error out with a message 
> telling the user that the object has
> been modified since they last saw it.
> 4) If no-one has modified the object since we last looked at it, 
> confirm the transfer (UPDATE transfer SET status = 'Confirmed', 
> last_updated = $currentTime, last_updated_by = $currentUser)
> 5) Release the write lock on the transfer (COMMIT)
>
> so long as these steps are followed, there will not be a drama with 
> multiple successful confirmations.

Yes :-) Well thought out and definitely the current way it should be 
done.

Thanks David

Scott
-- 
Scott Penrose
VP in charge of Pancakes
http://linux.dd.com.au/
scottp at dd.com.au

Dismaimer: If you receive this email in error - please eat it 
immediately to prevent it from falling into the wrong hands.